Following on from part 1 on this topic, JEP 411 has recently been updated with a "Future Work" section, amongst other changes. From the Apache NetBeans perspective, this is a welcome shift in the wording of this JEP. It is great that the owner and reviewers of JEP 411 recognize the special needs of complex, multi protection domain applications, such as IDEs. Such applications inherently run "less trusted" code, such as 3rd party JavaBean libraries in design time, and the ability to prevent such libraries to "System::exit" (at least) voluntarily is essential for preventing an IDE from unexpectedly closing.

From the Apache NetBeans point of view, however, it is still very concerning to note the sudden incompatible change in SecurityManager behavior and the rapid pace it is proposed to be implemented. Deprecating SecurityManager now and giving time to the overall Java ecosystem to adapt to such a change is acceptable, however, changing the JVM’s behavior incompatibly by requiring additional command line switches is disturbing.

In particular, no existing version of Apache NetBeans is going to launch with the JEP 411 changes. Unless one starts the JDK with a special property, it is not going to be possible to use the SecurityManager. Specifically, NETBEANS-5689 will prevent the IDE from starting. Should a user provide the proposed "-Djava.security.manager=allow" property, then the launch fails as well due to interaction with the Equinox framework, as shown in link;NETBEANS-5703.

Let’s face it, there is no known workaround. Apache NetBeans will not launch on JDK 17, i.e., the next LTS of Java.

Ideally JEP 411 would actually do what it says and deprecate only, rather than incompatibly changing the JVM’s behavior. The Java community should be given the next few years to adjust to the change and release updated versions of libraries (like Equinox) that are ready for the deprecation. Then applications should be updated (like NetBeans) to use such libraries. Only then should the incompatible mode be turned on, if at all.

Should the authors of JEP 411 take their shift in understanding the special need of IDEs & other complex multi protection domain applications seriously, they would prevent all sudden incompatibilities related to JEP 411 when deprecating SecurityManager.