JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal

[Sean Mullan]

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.

--Sean

[1] https://openjdk.java.net/jeps/411#Issue-warnings

On 5/21/21 7:03 PM, mark.reinhold at oracle.com wrote:
> The following JEP is proposed to target JDK 17:
> 
>    411: Deprecate the Security Manager for Removal
>         https://openjdk.java.net/jeps/411
> 
>    Summary: Deprecate the Security Manager for removal in a future
>    release. The Security Manager dates from Java 1.0. It has not been the
>    primary means of securing client-side Java code for many years, and it
>    has rarely been used to secure server-side code. To move Java forward,
>    we intend to deprecate the Security Manager for removal in concert with
>    the legacy Applet API (JEP 398).
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Friday, 28 May, or if they’re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I’ll target this JEP to JDK 17.
> 
> - Mark
> 
> 
> [1] https://openjdk.java.net/census#jdk
> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>