Remove SecurityManager usage and references

[jim-krueger]

The SecurityManager has been deprecated in JDK 11 (I believe) and removed in JDK 18+. The JAkarta Rest APIs should be cleaned to removed all usage and references going forward.

For sure these API's a affected and possibly more:

• jakarta/ws/rs/sse/FactoryFinder.java
• jakarta/ws/rs/ext/RuntimeDelegate.java
• jakarta/ws/rs/ext/FactoryFinder.java
• jakarta/ws/rs/client/FactoryFinder.java
• jakarta/ws/rs/client/ClientBuilder.java

[jamezp]

FWIW it has not yet been removed, but you have to explicitly enable it. It was deprecated in 17 with https://openjdk.org/jeps/411. It does however still work if you explicitly enable it.

AFAIK there is not an explicit version set for it to be removed in.

That said, it's been removed from the Jakarta EE 11 Platform specification jakartaee/platform#551.

All that said, addressing this in 5.0 makes sense to me.

[jim-krueger]

Thanks for the clarification James.

[ivargrimstad]

As pointed out by Guru in https://www.eclipse.org/lists/rest-dev/msg00314.html, there may be need to address this in a service release prior to 5.0 depending on your timeline. For reference, the Security Manger is proposed to be permanently disabled in Java SE 24.

JEP 486: Permanently Disable the Security Manager
https://openjdk.org/jeps/486

[tjwatson]

JEP 486 says:

Retain the Security Manager API in this release, so that maintainers of existing code that depends upon it have time to migrate away.

What breaks in 4.x API if the references to the Security Manager are not removed? Looks like all references in the API of rest does are optional behavior only if there is a SecurityManager enabled. JEP 486 only prevents a SecurityManger from being enabled, it does not remove the actual SecurityManager class and its other related APIs.

Seems like a fine thing to do for a 5.0 release.

[jamezp]

I replied to the email, but I agree that I see no reason to do a service release for this. This seems fine for 5.0, but I see no reason to remove it for 4.0.

[jim-krueger]

This would not be possible anyway. As Emily Jiang states in the email chain:
Not a service release. Service release is not allowed to do any api changes. Only the removal of TCKs is allowed. Thanks Emily

[jansupol]

+1 for 5.0

[tjwatson]

Not a service release. Service release is not allowed to do any api changes. Only the removal of TCKs is allowed. Thanks Emily

I agree this isn't needed for a point release of 4.x, but I consider it a bug fix vs. an actual API change since all the changes would be internal to the body of the methods and would not change the API signatures. But the "bug fix" isn't fixing any actual problem because the security manager APIs will remain in the next Java release. It is not until we get another JEP that pushes for the final removal of all the security manager APIs that this becomes a problem. At that point it would be a required bug fix so that the API JARs for 4.x could be used on the version of java that finally removes the security manager APIs.

[mkarg]

Following JEP 14's tip-and-tail model, I am +1 for removing all references to SecurityManager in 5.0 but not earlier releases.

[arjantijms]

Just wondering, consider the opposite situation:

Some people from the team did a service release and actually removed the security manager references (it's almost trivial to do so)

Would y'all actually want to revert that then, and do yet another service release to bring the security manager back?