JDK-8189750 : Remove deprecated pre-1.2 SecurityManager methods and fields
  • Type: CSR
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P2
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 10
  • Submitted: 2017-10-20
  • Updated: 2017-11-28
  • Resolved: 2017-11-28
Related Reports
CSR :  
JDK-8186535 - Remove deprecated pre-1.2 SecurityManager methods and fields
Description
Summary
-------
Remove the deprecated pre-JDK 1.2 `java.lang.SecurityManager` methods and fields that have been marked for removal in Java SE 9.

Problem
-------

These methods and fields are only for use in `SecurityManager` implementations prior to JDK 1.2. It is no longer necessary to retain support for pre-JDK 1.2 `SecurityManager` implementations. Removing these methods will clean up the `SecurityManager` class and eliminate the potential for them to be used incorrectly or insecurely. 

Solution
--------

Remove the following deprecated java.lang.SecurityManager methods and fields that have been marked with forRemoval=true in JDK 9: the `inCheck` field, and the `classDepth`, `classLoaderDepth`, `currentClassLoader`, `currentLoadedClass`, `getInCheck`, `inClass`, and `inClassLoader` methods. 

Also, change the `checkMemberAccess` method to throw `SecurityException` if the caller has not been granted `AllPermission` as this method is error-prone and users should instead invoke `checkPermission` directly. The `checkMemberAccess` method was deprecated in JDK 8 and marked for removal in 9, but we feel it is too early to remove it. Changing the behavior as noted eliminates the risk that it will be used incorrectly (and unsafely).

Specification
-------------

See 8186535-webrev.zip attachment.
Comments
Moving to approved.
28-11-2017
Updated specdiff attached.
28-11-2017
Sean - can you update the specdiffs that are attached to the CSR? You've updated the webrev but not the specdiffs.
23-11-2017
Sean - can you update the specdiffs that are attached to the CSR? You've updated the webrev but not the specdiffs.
23-11-2017
I have evaluated usages from a large number of Maven projects. There are 13 projects that include custom SecurityManagers which override these methods. Most of these overrides are simple: they either delegate to the installed SM or pass/fail by default. Some of the SMs are for testing. None of the projects reference the overridden methods, so they should be able to remove the overrides with minimal side-effects. There are also a couple of projects that still call checkSystemClipboardAccess but that can be easily replaced with checkPermission(AWTPermission("accessClipboard")). So, overall, I believe the risk is fairly low.
01-11-2017
Moving to Provisional Do you a any sense of how many projects would be impacted by removing these APIs? Any uses found in various code searching tools?
26-10-2017