ClassInfoException when running tests - Java 10

[gayanW]

Tests executes through JPF fails with ClassInfoException when running under Java 9/10.

Example: Running gov.nasa.jpf.test.basic.HarnessTest

[junit] gov.nasa.jpf.vm.ClassInfoException: class not found: java.io.Serializable
[junit]     at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:363)
[junit]     at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
[junit]     at gov.nasa.jpf.vm.SystemClassLoaderInfo.loadClass(SystemClassLoaderInfo.java:182)
[junit]     at gov.nasa.jpf.vm.ClassInfo.resolveReferencedClass(ClassInfo.java:2414)
[junit]     at gov.nasa.jpf.vm.ClassInfo.loadInterfaces(ClassInfo.java:2366)
[junit]     at gov.nasa.jpf.vm.ClassInfo.resolveClass(ClassInfo.java:2383)
[junit]     at gov.nasa.jpf.vm.ClassInfo.resolveAndLink(ClassInfo.java:548)
[junit]     at gov.nasa.jpf.jvm.JVMClassInfo.<init>(JVMClassInfo.java:624)
[junit]     at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:58)
[junit]     at gov.nasa.jpf.jvm.JVMClassFileContainer$JVMClassFileMatch.createClassInfo(JVMClassFileContainer.java:33)
[junit]     at gov.nasa.jpf.vm.ClassLoaderInfo.getResolvedClassInfo(ClassLoaderInfo.java:353)
[junit]     at gov.nasa.jpf.vm.SystemClassLoaderInfo.getResolvedClassInfo(SystemClassLoaderInfo.java:147)
[junit]     at gov.nasa.jpf.vm.VM.getStartupSystemClassInfos(VM.java:445)
[junit]     at gov.nasa.jpf.vm.VM.initializeMainThread(VM.java:564)
[junit]     at gov.nasa.jpf.vm.SingleProcessVM.initialize(SingleProcessVM.java:130)
[junit]     at gov.nasa.jpf.JPF.run(JPF.java:611)
[junit]     at gov.nasa.jpf.util.test.TestJPF.createAndRunJPF(TestJPF.java:675)
[junit]     at gov.nasa.jpf.util.test.TestJPF.unhandledException(TestJPF.java:849)
[junit]     at gov.nasa.jpf.util.test.TestJPF.verifyUnhandledException(TestJPF.java:903)
[junit]     at gov.nasa.jpf.test.basic.HarnessTest.verifyNullPointerException(HarnessTest.java:54)

ClassInfoException is thrown in here:

jpf-core/src/main/gov/nasa/jpf/vm/ClassLoaderInfo.java

Lines 316 to 372 in 18a0c42

	/**
	* obtain ClassInfo object for given class name
	*
	* if the requested class or any of its superclasses and interfaces
	* is not found this method will throw a ClassInfoException. Loading
	* of respective superclasses and interfaces happens recursively from here.
	*
	* Returned ClassInfo objects are not registered yet, i.e. still have to
	* be added to the ClassLoaderInfo's statics, and don't have associated java.lang.Class
	* objects until registerClass(ti) is called.
	*
	* Before any field or method access, the class also has to be initialized,
	* which can include overlayed execution of <clinit> declaredMethods, which is done
	* by calling initializeClass(ti,insn)
	*
	* this is for loading classes from the file system
	*/
	public ClassInfo getResolvedClassInfo (String className) throws ClassInfoException {
	String typeName = Types.getClassNameFromTypeName( className);
	ClassInfo ci = resolvedClasses.get( typeName);
	if (ci == null) {
	if (ClassInfo.isBuiltinClass( typeName)){
	ci = loadSystemClass( typeName);
	} else {
	ClassFileMatch match = getMatch( typeName);
	if (match != null){
	String url = match.getClassURL();
	ci = loadedClasses.get( url); // have we loaded the class from this source before
	if (ci != null){
	if (ci.getClassLoaderInfo() != this){ // might have been loaded by another classloader
	ci = ci.cloneFor(this);
	}
	} else {
	try {
	log.info("loading class ", typeName, " from ", url);
	ci = match.createClassInfo(this);
	} catch (ClassParseException cpx){
	throw new ClassInfoException( "error parsing class", this, "java.lang.NoClassDefFoundError", typeName, cpx);
	}
	loadedClasses.put( url, ci);
	}
	} else { // no match found
	throw new ClassInfoException("class not found: " + typeName, this, "java.lang.ClassNotFoundException", typeName);
	}
	}
	setAttributes(ci);
	resolvedClasses.put(typeName, ci);
	}
	return ci;
	}

Possible causes

As stated in the JDK 9 Release Notes the system property sun.boot.class.path has been removed. This makes JPF to fail resolve standard Java classes.

jpf-core/src/main/gov/nasa/jpf/vm/ClassInfo.java

Lines 1676 to 1680 in 18a0c42

	// finally, we load from the standard Java libraries
	v = System.getProperty("sun.boot.class.path");
	if (v != null) {
	buf.append(v);
	}

References
http://www.oracle.com/technetwork/java/javase/9-relnote-issues-3704069.html
https://stackoverflow.com/q/50451536/3647002

---

Implementation for the class URL generation would also need to be updated.

jpf-core/src/main/gov/nasa/jpf/jvm/JVMClassFileContainer.java

Lines 74 to 77 in a9bc908

	@Override
	public String getClassURL (String typeName){
	return getURL() + typeName.replace('.', '/') + ".class";
	}

In the earlier versions path to standard class would be like:

jar:file:/path/to/jjre/lib/rt.jar!/java/lang/Object.class

With the module system:

jrt:/java.base/java/lang/Object.class

[cyrille-artho]

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".

[cyrille-artho]

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");

[cyrille-artho]

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.