Remove SecurityManager / AccessController related code?

[iloveeclipse]

Context is: https://openjdk.java.net/jeps/411 and #385

Deprecation warnings we see in JDK 17 on API that is marked for removal (probably with JDK 21 - next LTS) :

• java.security.AccessController

• java.lang.SecurityManager

• java.lang.System.getSecurityManager()

• Query for platform

• Query for PDE

• Query for JDT

• Query for equinox

We should address that somehow.

My proposal would be: refactor all the Eclipse code that uses AccessController / SecurityManager and just remove everything (that can be removed) that references that API.

However I see there are open questions that need some answers / discussion.

• Any technical issues with the proposal?
• How many users (0.05%? 0.5%? 5%?) really make use of that API and need an Eclipse supporting it at all?
• Do we need announce that now, so we can remove it in 4.29?
• PMC discussion / decision needed?
• Anything else?

[akurtakov]

There is nothing for PMC to discuss for now . Only reason I see for that is if API will have to be removed/changed with shorter than the normal 2 years period. If there is such case please send to the PMC list with details.

[merks]

@sratz Has suggested that we ought to keep these until they are actually deleted. But certainly we should investigate now any impact on APIs.. I believe with Ant there are concerns that an Ant script could exit the IDE, but I don't know if a newer version of Ant has addressed that...

[tjwatson]

Equinox framework cannot delete these and stay compliant with the OSGi R8 specification. I think we need to wait and see what the real plan is for removing these APIs entirely from the JVM before proactively reacting. For example, I anticipate they will leave AccessController in for a very long time with no-op for stuff like doPriv calls.

[iloveeclipse]

Equinox framework cannot delete these and stay compliant with the OSGi R8 specification

@tjwatson: Does OSGI plan to update specs in context of https://openjdk.java.net/jeps/411 ?

[tjwatson]

Yes, I think it will mean simply removing the permission admin service sections:

https://docs.osgi.org/specification/osgi.core/8.0.0/service.condpermadmin.html
https://docs.osgi.org/specification/osgi.core/8.0.0/service.permissionadmin.html

The more challenging thing is what to do with all the permission classes (e.g. org.osgi.framework.BundlePermission). But so far the JEP states they are not removing the Permission API nor its subclasses. But we would want to avoid removing classes entirely from OSGi packages to avoid having to do a semantic major version bump.

WRT doPriv the JEP states:

For example, we may revise AccessController::doPrivileged simply to run the given action, or revise System::getSecurityManager always to return null. This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to work without change or even recompilation. We expect to remove the APIs once the compatibility risk of doing so declines to an acceptable level.

So I suspect there to be much pushback to removing doPrivileged entirely until "the compatibility risk of doing so declines to an acceptable level." But I don't expect that pushback on compatibility risk to decline until Java 8 truly ends (in 2026).

[tjwatson]

I for one look forward to the day I can rip out the implementation of condpermadmin and permissionadmin. These are some of the least used, yet most complicated things to implement in the core framework.