Hopefully there’s a Long enough grace period between deprecating that in OpenJDK and being able to Substitute it in Jakarta EE?
It looks like being only a Candidate now does not mean anything as to which Java Version really applies or fully removes security Manager (remember when Valhalla became a candidate? ;-P) but once it gets accepted by a JDK it may cause removal within 2 or 3 Java versions down the line.
Having helped customers from Java 9 to 11 in a SOAP-centric Environment with digital signatures I know this can be tricky and the more time we have to offer something in Jakarta EE to migrate to, the better.
Werner
I 100% agree with your position on the warnings. Perhaps requesting some control over this noise might be worth a comment, in the JEP.
If we have use-cases specific to EE, we should consider how we'd like to address those as well. We can do that in a number of ways. I suspect, the first thing, will be to enumerate where the EE specifications specifically call this out and decide how we would like to address these use-cases.
Getting back to the JEP, I am sure the JDK team would like to hear if there are specific use-cases that should be preserved and/or re-written especially those that might be universal to Java programs. Again, obtaining that feedback is exactly what the JEP process is designed to solicit.
-- Ed
On 4/15/2021 4:30 PM, arjan tijms wrote:
Hi,
Indeed, this won't be anytime soon. Still, it's like all those warnings about illegal reflection that we've been ignoring for years. At some point though you can't longer ignore them and have to address the issue.
p.s. this thread from 2014 goes into some of the details why the Security Manager was never an optimal fit for server side code anyway:
The JEP only indicates that these APIs will begin the deprecation process. Yes, we will need to address this, but the functionality won't actually be removed, at the earliest, before the next following LTS release (probably in the 20's).
If anyone has feedback, feel free to provide it via the JEP -- that is explicitly what this kind of notification process is designed to solicit.
-- Ed
On 4/15/2021 1:37 PM, arjan tijms wrote:
Hi,
Jakarta EE is specifically mentioned:
"Jakarta EE has several requirements on the Security Manager. These must be either relaxed or removed in order for compliant applications to run on future Java releases after the Security Manager is degraded and then removed."
Now I've personally been arguing for not using/depending on the security manager in server side code for a long time. The idea of running potentially untrusted code on your own server always struck me as awkward and something you would not do anyway, even when running multiple applications on a single server instance was still somewhat of a thing.
The TCK and GlassFish use the security manager a lot, so that would have to be removed depending on the final outcome of JEP 411.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!GqivPVa7Brio!KRUFmjPeJ0n_GJjs6zgARB3Wzc1oJWADLIGbHn38hd92YjH_9Hg7etwr-0gjmRE$
