Hi,
As was discussed before, the removal of the Security Manager in Java SE will impact Jakarta EE. It's deprecated for removal in Java SE 17.
Currently Jakarta EE 10 will target Java SE 11, so will theoretically not be affected by this. However implementations for Jakarta EE 9.1 (like GlassFish) already run on JDK 17 today, and have to deal with aggressive warnings in the console about the security manager deprecation. It's therefore likely all Jakarta EE 10 implementations will come into contact with this sooner or later.
We don't exactly know when the security manager will actually be removed, but it's an impediment for EE implementations to run on whatever version that is, be it Java SE 18, or Java SE 19, etc. This even concerns the API artefacts, as security manager calls take place in these. As it stands, these API artefacts would not be consumable on the Java SE version where the security manager is actually removed.
It's therefore probably good to prepare for this already in EE 10. A good first step would be perhaps to add a statement of intent that Jakarta EE indeed plans to follow Java SE and in the future remove usage of the security manager. At the moment this is not exactly clear, and I noticed some teams have been cautious with taking action pending any official statement regarding this matter.
Thoughts?
Kind regards,
Arjan Tijms
