netbeans.apache.org/src/content/blogs/entry/jep-411-deprecate-the-security1.adoc - netbeans-website - Git at Google

 //
 //     Licensed to the Apache Software Foundation (ASF) under one
 //     or more contributor license agreements.  See the NOTICE file
 //     distributed with this work for additional information
 //     regarding copyright ownership.  The ASF licenses this file
 //     to you under the Apache License, Version 2.0 (the
 //     "License"); you may not use this file except in compliance
 //     with the License.  You may obtain a copy of the License at
 //
 //       http://www.apache.org/licenses/LICENSE-2.0
 //
 //     Unless required by applicable law or agreed to in writing,
 //     software distributed under the License is distributed on an
 //     "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 //     KIND, either express or implied.  See the License for the
 //     specific language governing permissions and limitations
 //     under the License.
 //

 = JEP 411: Deprecate the Security Manager for Removal (Part 2)
 :author: Geertjan Wielenga
 :revdate: 2021-05-24
 :jbake-type: post
 :jbake-tags: blogentry
 :jbake-status: published
 :keywords: Apache NetBeans blog index
 :description: Apache NetBeans blog index
 :toc: left
 :toc-title:
 :syntax: true


 Following on from xref:jep-411-deprecate-the-security.adoc[part 1 on this topic], link:https://openjdk.java.net/jeps/411[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, link:https://issues.apache.org/jira/browse/NETBEANS-5689[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;https://issues.apache.org/jira/browse/NETBEANS-5703[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.
	//
	// Licensed to the Apache Software Foundation (ASF) under one
	// or more contributor license agreements. See the NOTICE file
	// distributed with this work for additional information
	// regarding copyright ownership. The ASF licenses this file
	// to you under the Apache License, Version 2.0 (the
	// "License"); you may not use this file except in compliance
	// with the License. You may obtain a copy of the License at
	//
	// http://www.apache.org/licenses/LICENSE-2.0
	//
	// Unless required by applicable law or agreed to in writing,
	// software distributed under the License is distributed on an
	// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	// KIND, either express or implied. See the License for the
	// specific language governing permissions and limitations
	// under the License.
	//

	= JEP 411: Deprecate the Security Manager for Removal (Part 2)
	:author: Geertjan Wielenga
	:revdate: 2021-05-24
	:jbake-type: post
	:jbake-tags: blogentry
	:jbake-status: published
	:keywords: Apache NetBeans blog index
	:description: Apache NetBeans blog index
	:toc: left
	:toc-title:
	:syntax: true



	Following on from xref:jep-411-deprecate-the-security.adoc[part 1 on this topic], link:https://openjdk.java.net/jeps/411[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, link:https://issues.apache.org/jira/browse/NETBEANS-5689[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;https://issues.apache.org/jira/browse/NETBEANS-5703[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.