On Wed, 20 Mar 2024 14:45:50 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the >> current subject differently. See the spec change in the `Subject.java` file >> for details. When the Security Manager APIs are finally removed in a future >> release, this new implementation will be only implementation for these >> methods. >> >> One major change in the new implementation is that `Subject.getSubject` >> always throws an `UnsupportedOperationException` since it has an >> `AccessControlContext` argument but the current subject is no longer >> associated with an `AccessControlContext` object. >> >> Now it's the time to migrate from the `getSubject` and `doAs` methods to >> `current` and `callAs`. If the user application is simply calling >> `getSubject(AccessController.getContext())`, then switching to `current()` >> would work. If the `AccessControlContext` argument is retrieved from an >> earlier `getContext()` call and the associated subject might be different >> from that of the current `AccessControlContext`, then instead of storing the >> previous `AccessControlContext` object and passing it into `getSubject` to >> get the "previous" subject, the application should store the `current()` >> return value directly. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > more allow and years There is no source code change to `java.management` anymore inside this PR. They will be resolved with new bugs at [JDK-8327618](https://bugs.openjdk.org/browse/JDK-8327618) and [JDK-8328263](https://bugs.openjdk.org/browse/JDK-8328263). There are test changes in these areas in this PR to force them running with SM allowed. Ideally, these changes can be reverted when the 2 new bugs are resolved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17472#issuecomment-2009779837
