On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore <wetm...@openjdk.org> wrote:
>> The JceSecurityManager is currently a subclass of >> java.security.SecurityManager. Now that JEP 411 has been integrated, this >> class should be updated to no longer subclass SecurityManager. >> >> The only reason for using SecurityManager to easily get the Class Context >> (call stack), but we can achieve the same effect by using the JDK 9 API >> java.lang.StackWalkeer. None of the other SecurityManager API are used. >> >> I have run mach5 tier1/tier2 plus --test >> jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto >> with all green. > > Bradford Wetmore has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains eight commits: > > - Address codereview comments > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Replace missing annotation > - Merge branch 'master' into JDK-8267485 > - Updated copyright date. > - 8267485: Remove the dependency on SecurityManager in > JceSecurityManager.java src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 111: > 109: Option.RETAIN_CLASS_REFERENCE) > 110: .walk((s) -> > s.collect(Collectors.toList()))); > 111: Note: StackWalker is a stateless capability object. It's not the walk() method that requires a permission, but the creation of the StackWalker itself (hence my suggestion to create it in the constructor, or in a static initializer). If you walk the stack from within a doPrivileged call then the doPrivileged frame will appear in the returned `List<StackFrame>`; this may (or may not) be OK - depending on the logic that processes the stack. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150
