[JDK-8342212] Adapt JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager.

[graalvmbot]

openjdk/jdk#21498 removes the SecurityManager, Policy, AccessController and other Security Manager API implementations

[dougxc]

This looks like the right fix for adapting to JDK-8338411.

[maxandersen]

Does this result in that native image/graalvm from java 25 cannot be used to build code that target Java 17 and Java 21 ?

If yes, that is quite unfortunate as for now its at least been possible to use nativeimage from newer versions to build projects targeting earlier jvm versions. If that is the case it becomes really important we somehow keep a working and updated Java 21 version of native image.

[dougxc]

Does this result in that native image/graalvm from java 25 cannot be used to build code that target Java 17 and Java 21 ?

If yes, that is quite unfortunate as for now its at least been possible to use nativeimage from newer versions to build projects targeting earlier jvm versions. If that is the case it becomes really important we somehow keep a working and updated Java 21 version of native image.

I would imagine the use of onlyWith addresses this concern.

[zakkak]

@dougxc the onlyWith is evaluated at GraalVM build time. That said in GraalVM for JDK 25 builds the JDK21OrEarlier boolean supplier will return false. As a result, compiling a Java 17 or Java 21 jar file to a native image with GraalVM for JDK 25 will no longer work (if it uses the removed APIs).

To keep backwards compatibility (while taking advantage of the latest advancements in GraalVM) one would need to build the latest GraalVM sources with JDK 21 (How would you call that? GraalVM 25.0 for JDK 21 I guess). This seems to work fine with labsjdk, but not with upstream OpenJDK builds (see graalvm#598)

[dougxc]

As a result, compiling a Java 17 or Java 21 jar file to a native image with GraalVM for JDK 25 will no longer work (if it uses the removed APIs).

If that's the case, then this must already be a problem given how many instances of onlyWith = JDK21OrEarlier.class I see in the code base. Is that right @olpaw ?

[olpaw]

As a result, compiling a Java 17 or Java 21 jar file to a native image with GraalVM for JDK 25 will no longer work

Why would that be the case?

You would still build your "Java 17 or Java 21 jar file" with an image-builder that runs on a JDK later than 21. Thus onlyWith = JDK21OrEarlier.class will be false in this context.

Only if you create a "GraalVM for JDK 21" version from master you would have a builder than runs on JDK 21 and then the onlyWith = JDK21OrEarlier.class would all be true. cc @zapster

[zapster]

As a result, compiling a Java 17 or Java 21 jar file to a native image with GraalVM for JDK 25 will no longer work

If OpenJDK 25 can run your JDK 17 or JDK 21 jars, then native image for JDK 25 will too. This is not about onlyWith but only about the OpenJDK being backwards compatible. If OpenJDK would make a breaking change, there is nothing native image could do about it.

[zakkak]

I think we have moved this discussion off tracks. I think I accidentally moved this discussion off tracks. Let me try and restate the "problem" which doesn't seem to be a GraalVM specific thing in the first place.

As @zapster says with https://bugs.openjdk.org/browse/JDK-8338412 backwards compatibility is being broken for applications relying on the Security Manager.

Till now we were able to get away with "build and test your application on JDK 17 and build the native image with JDK 21" which allowed us to push newer GraalVM versions to users without requiring them to bump their base JDK. Unfortunately(?), this now seems to come to an end and leaves us with the following options:

1. Force the users to drop incompatible, with the latest JDK, code
2. Start building GraalVM 24.2, 25.0, etc. with JDK 21 as well (which unfortunately is not working at the moment with upstream OpenJDK -- see GraalVM master fails to build with OpenJDK 21 after GR-49610 graalvm/mandrel#598)
3. Maintain GraalVM for JDK 21 for longer till we are sure no-one relies on the removed functionality

[wirthi]

@zakkak (off-topic on the Security Manger but still relevant I believe): note that is our intention to (only) support the latest version of Java in our master branch. Especially regarding your option 2: yes, right now we still have JDK21 support in master. There are different reasons for that, but ultimately, we want to get rid of this and always only support latest. Support for Java's LTS versions should only be available in our CPU branches, 23.1 for JDK21 and 23.0 for JDK17.

[zakkak]

Thank you for the clarification @wirthi.