ClassInfoException when running tests - Java 10 about jpf-core HOT 3 CLOSED

You can replace sun.boot.class.path with a list of all relevant jar files in System.getProperty("java.home") + java.io.File.separator + "lib"

There are many .jar files in that directory; the ones that are needed for bootstrapping the JVM in Java 8 are (on Mac OS X):

/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/resources.jar
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/rt.jar
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/sunrsasign.jar
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/jsse.jar
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/jce.jar
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/charsets.jar
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/jfr.jar
/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/classes

However, the list may be different for newer versions of Java, so it is probably best to look through all .jar files in java.home + "/lib".

from jpf-core.

We have to use java.lang.Classloader to load all internal resources, as the format of the internal storage of the base libraries is not defined and subject to change.

It seems the right way to do this is to go through the module layer:

Module m = ModuleLayer.boot().findModule("java.base"); // returns Option<Module>
m.get().getClassLoader().loadClass("java.lang.Object");
// to get URL for use in ClassFileMatch: m.get().getClassLoader().getSystemResource("java.lang.Object");
// to read bytecode: m.get().getResourceAsStream("java.lang.Object");

from jpf-core.

It seems we have to adapt JPF at various levels for this: JPF.java, to use the right classloader; JVMClassFileContainer, perhaps subclasses as JModClassFileContainer, which can delegate to Module.getResourceAsStream and such; and we have to make sure that the base classes are found and loaded without implementation-specific user configuration.

JModClassFileContainer would have to extend JVMClassFileContainer and override getMatch to find the resource (via Module.getResourceAsStream etc. as above).

The "right" classloader is probably the PlatformClassLoader, returned by ClassLoader.getPlatformClassLoader(): https://docs.oracle.com/javase/10/docs/api/java/lang/ClassLoader.html#builtinLoaders
Try changing line 227 in JPF.java to use the platform classloader instead of the class loader used to load JPF.java.

from jpf-core.