RFR: 8356645: Javac should utilize new ZIP file system read-only access mode [v3]

David Beaumont duke at openjdk.org
Thu Jun 19 10:03:34 UTC 2025


On Wed, 11 Jun 2025 06:01:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Also for compile on-the-fly, I usually use `InMemoryJavaCompiler` and `ByteCodeLoader` available with `/test/lib` library. `InMemoryJavaCompiler` conveniently returns a list of all class files, and its one-class-file version throws an exception if a compilation unit generates more than one class, which is not usually checked by manual invocations to javac task.
>
> For new tests, I would often prefer to use on-the-fly compilation (although javac has its own frameworks to do that, like the `ToolBox` used here).
> 
> For existing tests, I generally prefer to restrict changes to a minimum (although opinions may differ on that).
> 
> But here, I wonder: why is the test failing? I didn't see anything in the patch that would seem to be an obvious cause of a breakage of a test like this. So, I think it deserves a good look to find out what's the cause of the test failing, rather than just adjusting the test to pass.

When I revert to the original code, I get:


java.lang.NullPointerException: Cannot invoke "java.io.InputStream.readAllBytes()" because the return value of "java.lang.Class.getResourceAsStream(String)" is null
	at ClassRefDupInConstantPoolTest.main(ClassRefDupInConstantPoolTest.java:40)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)

JavaTest Message: Test threw exception: java.lang.NullPointerException: Cannot invoke "java.io.InputStream.readAllBytes()" because the return value of "java.lang.Class.getResourceAsStream(String)" is null
JavaTest Message: shutting down test


when running via IntelliJ, but it passes when running via make. So there's some fragility with the environment.

I probably didn't realize originally that this was conditionally failing, so just changed it on the assumption that it was failing everywhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2156617412


More information about the compiler-dev mailing list