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

iloveeclipse · 2023-09-21T11:36:20Z

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.

The text was updated successfully, but these errors were encountered:

laeubi · 2023-09-21T11:39:59Z

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 · 2023-09-21T11:41:06Z

What has changed since last discussion here?

Java 21 (next LTS) was released

laeubi · 2023-09-21T11:42:55Z

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

iloveeclipse · 2023-09-21T11:47:59Z

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 · 2023-09-21T11:59:01Z

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 · 2023-09-21T12:06:33Z

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 · 2023-09-21T12:12:35Z

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 · 2023-09-21T12:12:59Z

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 · 2023-09-21T12:14:59Z

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 · 2023-09-21T12:49:40Z

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 · 2023-09-21T12:54:49Z

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

iloveeclipse · 2023-09-21T13:04:47Z

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 · 2023-09-21T13:14:36Z

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.

merks · 2023-09-21T13:30:39Z

Google turned up wrong answer. You can't trust anything anymore. 😱

Yes, as @tjwatson suggests, this has been working for quite some time. I believe in ant 1.10.13 they defined such a class to make it work with older JVMs, but that's removed in 1.10.14 (and that caused problems BND problems).

Let's hold off any decisions until we see how 1.0.14 works. Maybe they didn't something super smart?

iloveeclipse · 2023-09-21T13:35:38Z

Google turned up wrong answer

Depends on the point of view :-) If AI's final goal is the death of mankind, the first step is to give seemingly right answers leading to crashes. Next time it will be not an IDE but some missile launch engineer copy/pasting AI's proposal :-(

merks · 2023-09-23T11:28:18Z

The next I-Build will be based on ant 1.10.14.

This page still suggestion Temurin 21 should arrive this month:

https://adoptium.net/support/

iloveeclipse · 2023-09-25T08:07:59Z

The next I-Build will be based on ant 1.10.14.

I see same errors reported with I20230924-0600 (without -Djava.security.manager=allow option set):

eclipse.buildId=4.30.0.I20230924-0600
java.version=21
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Command-line arguments:  -os linux -ws gtk -arch x86_64

org.eclipse.ant.core
Error
Mon Sep 25 10:04:51 CEST 2023
Setting Security Manager is not supported

Eclipse says it is using 1.10.14.v20230922-1200 version of org.apache.ant.
What exactly the 1.10.14 and should have fixed?

akurtakov · 2023-09-25T08:15:30Z

From ant 1.10.14 whatsnew file:

When using Java 18 or higher, Ant will no longer use Java SecurityManager
   because it has been deprecated for removal and by default is disallowed
   to be set at runtime https://openjdk.org/jeps/411.
   This will mean that the "<permissions>" type is no longer functional when
   using Java 18 or higher.
   Furthermore, when using Java 18 or higher, if the build executes
   tasks that call "java.lang.System.exit()" and if those tasks aren't
   running in a forked VM of their own, then such tasks will now kill
   the entire Ant build process. It is recommended that such tasks be
   updated to launch in a forked JVM so that the System.exit() call
   will not impact the JVM in which Ant process runs.

iloveeclipse · 2023-09-25T08:16:36Z

OK, so "Setting Security Manager is not supported" error is not reported by actual ant code, it is our own error?

akurtakov · 2023-09-25T08:20:30Z

Yes, it is

eclipse.platform/ant/org.eclipse.ant.core/src_ant/org/eclipse/ant/internal/core/ant/InternalAntMessages.java

Line 68 in efe0dce

public static String InternalAntRunner_SecurityManagerError;

SarikaSinha · 2023-09-25T10:10:42Z

Yes, we need to update out Ant code. As Ant is not supporting the setting of SecurityManager any more.

The change with Ant 1.10.14 is that Ant is not adding any "allow" class any more.
The use of a "allow" class as a workaround to older versions of JDK
considering this value as a classname for -Djava.security.manager system
property.

laeubi · 2023-10-20T15:44:49Z

I just wanted to add that I came across a very neat solution (described by @bmarwell) for this (@tjwatson maybe this would be an option for Equinox / OSGi as well):

You encapsulates the access to SM into an own class, lets call this SecurityMangerAccessor
You have one implementation of this that uses the SecurityManger as is
create a Multi-Release-Jar and have a second version that is only a NO-OP and does not access SecurityManger at all and place that compiled class in /META-INF/versions/21/....

As a result, your jar will use the SM when running on JVM < 21 and will not use it when running on JVM >= 21 🥇

bmarwell · 2023-10-20T16:15:00Z

Oh hey @tjwatson again 👋🏻😅

Here's the needed setup:
groovy/GMavenPlus#287

Alternative: parse the output of a static initialiser block of the system property "java.version".

bmarwell · 2023-10-21T17:04:20Z

FYI, Setting outputDirectory will probably become valid:

apache/maven-compiler-plugin#202

tjwatson · 2023-10-23T20:14:50Z

Thanks @bmarwell.

As a result, your jar will use the SM when running on JVM < 21 and will not use it when running on JVM >= 21

The framework has no need for this and I would not be for this existing in the framework. What is the stacktrace of what is setting the security manager? If it is coming from Ant then I doubt we would convince Ant to make calls to some org.eclipse API to work around it. If it is coming from the framework itself then it is a bug we must fix in the framework, but I doubt that would involve some complicated MR JAR solution.

bmarwell · 2023-10-23T20:35:38Z

If it is coming from the framework itself then it is a bug we must fix in the framework, but I doubt that would involve some complicated MR JAR solution.

Ha, I thought it is already clear where the message originated.
Anyway, as Security Manager is deprecated for removal, you cannot load nor import it starting with Java 21/24 or so?. At the same time you must load it for 8-21, for backwards compatibility.

The other option, if you find a perfectly valid MR Jar complicated, is a static initialiser loading one of two classes (one which does the SM logic, one which doesn't)

However, you will instead need to parse the Java version for this. Not sure MR Jar is more complicated than parsing Java versions, but YMMV.

As this might need a backport, you probably cannot use Java 11's Runtime.getVersion().

iloveeclipse · 2023-10-24T11:43:38Z

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

This looks for me as the best proposal so far. I've played a bit with current platform & I don't see any issues with this preference on Java 21 / latest ant.

Example project with the ant build file/launch config that runs System.exit() from ant running from IDE:
system_exit_from_ant.zip

The output looks like:


Buildfile: /data/runtime-Java_21/A/build.xml

build:
        [java] Callling System.exit() now!
        [java] org.eclipse.ant.core.AntSecurityException
        [java] 	at org.eclipse.ant.internal.core.AntSecurityManager.checkExit(AntSecurityManager.java:62)
        [java] 	at java.base/java.lang.Runtime.exit(Runtime.java:186)
        [java] 	at java.base/java.lang.System.exit(System.java:1916)
        [java] 	at A.main(A.java:4)
        [java] 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        [java] 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        [java] 	at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:220)
        [java] 	at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:155)
        [java] 	at org.apache.tools.ant.taskdefs.Java.run(Java.java:892)
        [java] 	at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:232)
        [java] 	at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:136)
        [java] 	at org.apache.tools.ant.taskdefs.Java.execute(Java.java:109)
        [java] 	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299)
        [java] 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        [java] 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        [java] 	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
        [java] 	at org.apache.tools.ant.Task.perform(Task.java:350)
        [java] 	at org.apache.tools.ant.Target.execute(Target.java:449)
        [java] 	at org.apache.tools.ant.Target.performTasks(Target.java:470)
        [java] 	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
        [java] 	at org.apache.tools.ant.Project.executeTarget(Project.java:1374)
        [java] 	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        [java] 	at org.eclipse.ant.internal.core.ant.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:34)
        [java] 	at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
        [java] 	at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:716)
        [java] 	at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:532)
        [java] 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        [java] 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        [java] 	at org.eclipse.ant.core.AntRunner.run(AntRunner.java:369)
        [java] 	at org.eclipse.ant.internal.launching.launchConfigurations.AntLaunchDelegate.lambda$0(AntLaunchDelegate.java:279)
        [java] 	at java.base/java.lang.Thread.run(Thread.java:1583)
        [java] Java Result: -1
BUILD SUCCESSFUL
Total time: 3 seconds

I would propose a PR adding this system property in platform SDK product and open an issue on https://github.com/eclipse-packaging/packages/issues to add -Djava.security.manager=allow by default to epp packages. This would avoid silly error logs for those running on Java 21+.

FYI: we set security manager in two places, to run ant / resolve ant build files, see https://github.com/search?q=%28org%3Aeclipse-platform+setSecurityManager%29+&type=code

This avoids "Setting Security Manager is not supported" errors logged if running ant related tooling on Java 21. Fixes eclipse-platform/eclipse.platform#709

iloveeclipse · 2023-10-24T11:57:40Z

I've created eclipse-packaging/packages#71 for epp.

iloveeclipse · 2023-10-24T12:02:59Z

For the completeness: there is a Java bug asking to provide a replacement API that would disallow System.exit() being called from the code, but as far as I can see no intents to provide that: https://bugs.openjdk.org/browse/JDK-8199704.

tjwatson · 2023-10-24T13:08:28Z

I've created eclipse-packaging/packages#71 for epp.

Isn't there an eclipse.ini seeded from the platform that gets fed into EPP where we can set this such that it applies to every EPP automatically as well as the packages the Eclipse project itself publishes?

iloveeclipse · 2023-10-24T13:13:18Z

No idea.

merks · 2023-10-24T13:17:36Z

No, each EPP product specifies such things itself. E.g.,

https://github.com/eclipse-packaging/packages/blob/8b88a53ec2a07b81eb8ada028bd235f4197c310b/packages/org.eclipse.epp.package.committers.product/epp.product#L29

This avoids "Setting Security Manager is not supported" errors logged if running ant related tooling on Java 21. Fixes eclipse-platform/eclipse.platform#709

jonahgraham · 2023-10-24T18:32:42Z

I've created eclipse-packaging/packages#71 for epp.

Isn't there an eclipse.ini seeded from the platform that gets fed into EPP where we can set this such that it applies to every EPP automatically as well as the packages the Eclipse project itself publishes?

There used to be, but EPP no longer uses Platform's product as starting point due to limitations in the p2 model that meant we had duplicate entries for -Dosgi.requiredJavaVersion= with EPP providing =17 and Platform providing =11 and both ending up in the ini file.

HannesWell · 2023-10-24T20:09:42Z

I've created eclipse-packaging/packages#71 for epp.

Isn't there an eclipse.ini seeded from the platform that gets fed into EPP where we can set this such that it applies to every EPP automatically as well as the packages the Eclipse project itself publishes?

There used to be, but EPP no longer uses Platform's product as starting point due to limitations in the p2 model that meant we had duplicate entries for -Dosgi.requiredJavaVersion= with EPP providing =17 and Platform providing =11 and both ending up in the ini file.

I don't think =11 for platform is right since most platform bundles require 17 anyway.
I wonder if it is even necessary to declare osgi.requiredJavaVersion at all since Java-17 is implied by the highest bundles EE requirements?
I assume osgi.requiredJavaVersionis only usefull if one wants an even higher Java version (like 21 for now)? Or is there a deeper meaning of osgi.requiredJavaVersion?

jonahgraham · 2023-10-24T20:22:22Z

I don't think =11 for platform is right since most platform bundles require 17 anyway.

Sorry - I was imprecise with the wording. I was trying to provide historical context from when Platform did used to provide =11.

I wonder if it is even necessary to declare osgi.requiredJavaVersion at all since Java-17 is implied by the highest bundles EE requirements?
I assume osgi.requiredJavaVersionis only usefull if one wants an even higher Java version (like 21 for now)? Or is there a deeper meaning of osgi.requiredJavaVersion?

IIUC requiredJavaVersion will raise an error if JVM is < than requiredJavaVersion. If not specified, the bundles with BREE > than JVM will simply not be used. Therefore I think we need requiredJavaVersion to be the minimum version so we don't surprise users.

merks · 2023-10-24T20:27:23Z

Yes it is supposed to cause an explicit failure on startup even before bundles fail to start.

See #709

The security manager is needed if ant is installed (either pre-installed or added by the user). This change synchronizes all the EPP packages with the change made to Eclipse Platform/SDK products in eclipse-platform/eclipse.platform#709 This also addresses the "Synchronize any changes to platform.product into all the epp.product files." step from RELEASING.md Fixes eclipse-packaging#71 Part of eclipse-packaging#72

See eclipse-platform#709

iloveeclipse added the bug Something isn't working label Sep 21, 2023

iloveeclipse added this to the 4.30 milestone Sep 21, 2023

This was referenced Oct 24, 2023

Add -Djava.security.manager=allow to SDK & Platform products eclipse-platform/eclipse.platform.releng.aggregator#1469

Merged

Add -Djava.security.manager=allow to all packages that contain ant tooling eclipse-packaging/packages#71

Closed

iloveeclipse closed this as completed in eclipse-platform/eclipse.platform.releng.aggregator#1469 Oct 24, 2023

iloveeclipse self-assigned this Oct 25, 2023

iloveeclipse modified the milestones: 4.30, 4.30 M3 Oct 25, 2023

iloveeclipse mentioned this issue Oct 25, 2023

Add original exception to the error log #762

Merged

iloveeclipse added a commit that referenced this issue Oct 25, 2023

Add original exception to the error log

bf89859

See #709

Michael5601 pushed a commit to CodeLtDave/eclipse.platform that referenced this issue Feb 12, 2024

Add original exception to the error log

5639ae8

See eclipse-platform#709

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

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

Comments

iloveeclipse commented Sep 21, 2023

laeubi commented Sep 21, 2023

iloveeclipse commented Sep 21, 2023

laeubi commented Sep 21, 2023

iloveeclipse commented Sep 21, 2023

laeubi commented Sep 21, 2023

iloveeclipse commented Sep 21, 2023

akurtakov commented Sep 21, 2023

laeubi commented Sep 21, 2023

akurtakov commented Sep 21, 2023

tjwatson commented Sep 21, 2023

merks commented Sep 21, 2023

iloveeclipse commented Sep 21, 2023

tjwatson commented Sep 21, 2023

merks commented Sep 21, 2023

iloveeclipse commented Sep 21, 2023

merks commented Sep 23, 2023

iloveeclipse commented Sep 25, 2023

akurtakov commented Sep 25, 2023

iloveeclipse commented Sep 25, 2023

akurtakov commented Sep 25, 2023

SarikaSinha commented Sep 25, 2023

laeubi commented Oct 20, 2023

bmarwell commented Oct 20, 2023

bmarwell commented Oct 21, 2023

tjwatson commented Oct 23, 2023

bmarwell commented Oct 23, 2023 • edited

iloveeclipse commented Oct 24, 2023 • edited

iloveeclipse commented Oct 24, 2023

iloveeclipse commented Oct 24, 2023

tjwatson commented Oct 24, 2023

iloveeclipse commented Oct 24, 2023

merks commented Oct 24, 2023

jonahgraham commented Oct 24, 2023

HannesWell commented Oct 24, 2023

jonahgraham commented Oct 24, 2023

merks commented Oct 24, 2023

bmarwell commented Oct 23, 2023 •

edited

iloveeclipse commented Oct 24, 2023 •

edited