Clojure code: NoSuchMethodException: jdk.internal.misc.SharedSecrets.setJavaUtilZipFileAccess

[awwx]

Clojure dynamically loads code at runtime:

gov.nasa.jpf.vm.NoUncaughtExceptionsProperty
java.lang.NoSuchMethodException: jdk.internal.misc.SharedSecrets.setJavaUtilZipFileAccess(Ljdk/internal/misc/JavaUtilZipFileAccess;)V
	at java.util.zip.ZipFile.<clinit>(ZipFile.java:1152)
	at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
	at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:125)
	at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:92)
	at clojure.lang.RT.lastModified(RT.java:416)

I see https://github.com/javapathfinder/jpf-core/blob/master/src/classes/modules/java.base/jdk/internal/misc/SharedSecrets.java and perhaps I could add setJavaUtilZipFileAccess there.

Before I get there though, I was wondering if it might be possible to execute a program to a certain point in the system VM and then switch to the JPF VM?

Clojure is only calling setJavaUtilZipFileAccess during initialization when it's loading Clojure program code. It's not called when the program is being tested.

I also noticed the comment in the JPF SharedSecrets implementation

All of this is hopefully going away when we drop Java 1.5 support, and is
to be replaced by some native peers providing the required native calls

If I will need setJavaUtilZipFileAccess support in JPF, would it be easier/better to try implementing the native peers instead?

[cyrille-artho]

This is complex and closely related to issue #483, which we hope to resolve in the coming months.