[Java 21] "Setting Security Manager is not supported" errors

[iloveeclipse]

After starting I20230921-0530 on Java 21 I see following errors reported in the log:

eclipse.buildId=4.30.0.I20230921-0530
java.version=21
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Command-line arguments:  -data /data/4x_platform_workspace -os linux -ws gtk -arch x86_64

org.eclipse.ant.core
Error
Thu Sep 21 13:33:52 CEST 2023
Setting Security Manager is not supported

We should do something on Java 21 to avoid that code being executed or at least mute the error if we can't avoid that.

[laeubi]

Platform is currently Java 17 so why is this a bug? What has changed since last discussion here? Any new decisions?

• Remove SecurityManager / AccessController related code? #394

[iloveeclipse]

What has changed since last discussion here?

Java 21 (next LTS) was released

[laeubi]

So Platform will upgrade to Java 21 for the 2023-12 release? That would be great 👍

[iloveeclipse]

So Platform will upgrade to Java 21 for the 2023-12 release? That would be great 👍

No, for sure not, but people / organisations will start Java 21 evaluation & migration and we should make sure that we don't ship software that report errors "by default".

E.g. in Advantest we monitor error log during test executions and report every unexpected warning/error as test fail. So switching our build to Java 21 would lead to test errors in all places where ant could be involved. Of course we can suppress that specific error in tests, but our customers, once we switch product to run on Java 21, will see the errors and report bugs.

That all shouldn't happen if we know where the problem is, so a generic (not client specific) solution is needed.

[laeubi]

No, for sure not, but people / organisations will start Java 21 evaluation & migration and we should make sure that we don't ship software that report errors "by default".

The default Eclipse Packages use Java 17 as a JVM so no errors are reported, this was discussed already here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=575210

so for me the question is what "bug" in Platform is here to solve?

This is the corresponding bug/issue at ANT: https://bz.apache.org/bugzilla/show_bug.cgi?id=65381
as far as I know @merks is already working on upgrading ant.

So from platform side Java 21+ Ant is currently not supported and Platform is targeting Java 17 right now and also ships with this JVM.

[iloveeclipse]

So from platform side

I see it from user side, and it is clearly a bug if software reports errors.
We can't avoid that users would start using Java 21 and have to deal with that.
If #701 solves the problem, even better.
If not, we should provide a solution.

[akurtakov]

Our code would have to be changed to version guard and not set SecurityManager if running on Java 21+.
The fact that EPP packages ship with Java 17 doesn't mean we shouldn't care about newer JVMs and from from Platform side we require minimum of Java 17 with no max version set. Please note that Platform doesn't ship a JVM (https://download.eclipse.org/eclipse/downloads/drops4/I20230921-0530/) and IMHO that's a good thing as it broadens the testing matrix and eases switches to newer JVM later.
P.S. As per https://www.eclipse.org/lists/eclipse.org-planning-council/msg03578.html Java 21 is fine for releases targeting 2024-06, plugins that are not part of simrel can require Java 21 even today.

[laeubi]

I see it from user side

I as a user don't see the error ...

If #701 solves the problem, even better.

Depends on how one defines "solve" ... you won't see the error anymore but Ant can now kill your eclipse, similar to this m2e issue:

• Eclipse IDE crash with "JVM terminated. Exit code=1" error when incorrectly using the exec-maven-plugin eclipse-m2e/m2e-core#1340

If not, we should provide a solution.

The solution is to use the JVM we recommend, test and ship to the user :-)

[akurtakov]

Please note that Eclipse platform is not only an IDE - it's an RCP platform used in very different environments, requirements and etc. thus there is no way that "one size fits all" works.

[tjwatson]

The solution is to use the JVM we recommend, test and ship to the user :-)

The Eclipse project does not ship the JVM (EPPs do). We should work (and test) on the latest Java LTS release.

[merks]

I wonder, does -Djava.security.manager=allowed still work?

[iloveeclipse]

I wonder, does -Djava.security.manager=allowed still work?

It depends how you define "works" :-)

With the argument above Eclipse crashes reporting on the shell this:

./eclipse 
WARNING: Using incubator modules: jdk.incubator.vector
Error occurred during initialization of VM
java.lang.InternalError: Could not create SecurityManager
        at java.lang.System.initPhase3(java.base@21/System.java:2301)
Caused by: java.lang.ClassNotFoundException: allowed
        at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@21/BuiltinClassLoader.java:641)
        at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@21/ClassLoaders.java:188)
        at java.lang.ClassLoader.loadClass(java.base@21/ClassLoader.java:526)
        at java.lang.Class.forName0(java.base@21/Native Method)
        at java.lang.Class.forName(java.base@21/Class.java:534)
        at java.lang.Class.forName(java.base@21/Class.java:513)
        at java.lang.System.initPhase3(java.base@21/System.java:2285)

But using allow like here -Djava.security.manager=allow helps to avoid errors :-)

Does this mean, we should add this argument to the eclipse ini as solution but only if we detect Java 21+ runtime? Or are there better alternatives?

[tjwatson]

Does this mean, we should add this argument to the eclipse ini as solution but only if we detect Java 21+ runtime? Or are there better alternatives?

Given we only support Java 17+ we could set that by default in eclipse.ini. That should work for Java 17 also.