In the JDK 17.0.3 release (and other releases, i.e. 11.0.16, 13.0.12, 15.0.8)), the backport of "JDK-8273655 content-types.properties files are missing some common types" breaks VFS in the following way:

Even though this exception states that it occurs in org.reflections.Reflections, the issue is that VFS now returns the incorrect implementation in VirtualFileURLConnection#getContent():

class VirtualFileURLConnection extends AbstractURLConnection {
//...
    public Object getContent() throws IOException {
        if (getContentType() != null) {
            return super.getContent();
        }
        return file;
    }

Since the JDK backport (i.e. in 17.0.3 and other releases), the content type is now set to "application/java-archive" instead of null, which pushes the getContent() method info returning a VirtualJarInputStream rather than the expected VirtualFile. A debugger did point out that the virtualFile was properly set.

Stack trace:

2022-04-25 03:30:25,225 WARN [org.reflections.Reflections] (Batch Thread - 1) could not create Dir using jboss_vfs from url vfs:/content/iridium-util.ear/iridium-data-update.jar/. skipping.: java.lang.ClassCastException: class org.jboss.vfs.VirtualJarInputStream cannot be cast to class org.jboss.vfs.VirtualFile (org.jboss.vfs.VirtualJarInputStream and org.jboss.vfs.VirtualFile are in unnamed module of loader 'org.jboss.vfs@3.2.15.Final' @6b57696f)
	at deployment.iridium-util.ear//org.reflections.vfs.JbossDir.createDir(JbossDir.java:19)