Apache NetBeans

Saturday May 29, 2021

[ANNOUNCE] Apache NetBeans 12.4 released

The Apache NetBeans team is pleased to announce that Apache NetBeans 12.4 was released on May 19th 2021*. Apache NetBeans is a full IDE for Java SE, Java EE, PHP, JavaScript, HTML5 and more, including some support for Groovy and C/C++.

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:

https://cwiki.apache.org/confluence/display/NETBEANS/Release+Schedule

New & noteworthy features of the 12.4 release:

https://netbeans.apache.org/download/nb124/index.html

Downloads:

https://netbeans.apache.org/download/nb124/nb124.html

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

Friday May 28, 2021

Better JEP 411 News: Correct Deprecation of SecurityManager

See https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005616.html

"We have updated the JEP with a few changes to the "Issue Warnings" 
section [1], 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."

Monday May 24, 2021

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.

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation