RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager

[David M. Lloyd]

On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a bit of forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.
>
> OK

While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:


if (System.getSecurityManager() != null) {
    foo.checkAccess();
}


I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.

But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801484176