ClassLoaders are getting a bit confused with the URLs being provided. By the looks, URLs that represent a directory are being expected to be passed back with a trailing backslash to denote that they are directories. It doesn't look like MemoryFileSystem is doing that implicitly though, which is leading the JDK classloader logic to consider the URLs being provided as being for a JAR rather than a file system tree.
java.lang.ClassNotFoundException: org.example.User
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
Fixes feedback in GH-142
Can confirm that with this, URL class loading is working for me perfectly (along with a work-around for #144 on my side)
This fixes the issue that I mentioned at the end of https://github.com/marschall/memoryfilesystem/issues/142#issuecomment-1537474690
ClassLoaders are getting a bit confused with the URLs being provided. By the looks, URLs that represent a directory are being expected to be passed back with a trailing backslash to denote that they are directories. It doesn't look like MemoryFileSystem is doing that implicitly though, which is leading the JDK classloader logic to consider the URLs being provided as being for a JAR rather than a file system tree.
Code that seems to be triggering the issue on the JDK side is at https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L471.
The result on the ClassLoader level appears to be
Fixes feedback in GH-142
Can confirm that with this, URL class loading is working for me perfectly (along with a work-around for #144 on my side)