[ANNOUNCE] Apache NetBeans 12.4 released
Apache NetBeans 12.4 is a quarterly feature update. The LTS release of the current cycle is Apache NetBeans 12.0. The 12.4 release has not been as heavily tested as the LTS release. Our schedule is publicly available here:
New & noteworthy features of the 12.4 release:
Feel free to share the good news!
* We're a little late in announcing this because we were creating convenience binaries, e.g., installers, since announcing the result of the vote thread.
Thanks everyone, and best wishes,
Geertjan and Neil
Release Manager for Apache NetBeans 12.4
on behalf of Apache NetBeans PMC
Posted at 10:01AM May 29, 2021 by Geertjan in Technology | |
Better JEP 411 News: Correct Deprecation of SecurityManager
"We have updated the JEP with a few changes to the "Issue Warnings" section , summarized as follows: If the Java runtime is started without setting the system property 'java.security.manager' then a custom Security Manager can be installed dynamically by calling System::setSecurityManager, just as in Java 16. No UnsupportedOperationException will be thrown. This call will, however, issue a warning message explaining that the Security Manager is deprecated and will be removed in a future release. We plan to change the default value of the 'java.security.manager' system property to "disallow" in the next release, i.e., Java 18. That will cause System::setSecurityManager to throw an UnsupportedOperationException in Java 18. With these changes, the process of deprecating and eventually removing the Security Manager will be consistent with our treatment of past breaking changes such as, e.g., the strong encapsulation of internal APIs. Maintainers of libraries and applications will be given fair warning before any existing code is broken."
Posted at 09:53AM May 28, 2021 by Geertjan in General | |
JEP 411: Deprecate the Security Manager for Removal (Part 2)
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 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.
Posted at 12:36PM May 24, 2021 by Geertjan in General | |