Thanks Alan,
I've been thinking that it may be preferable to have hooks that allowed
us to inject our own permission checks, rather than retaining existing
permission checks.
An implementation can override Guard::check without requiring a provider
mechanism.
The other advantage is the abil
Some thoughts on hooks:
* Utilize the Service Provider API, so as not to expose jdk
implementation code. META-INF/services/java.security.Guard
* Allow existing Permission classes to remain backward compatible,
declare them as services, so that SecurityManager can be degraded as
planne
cc'ing security-dev as that is the mailing list to use for this JEP.
This JEP is the first of several in a multi-release/multi-year effort.
It's way too early to give any guess as to when the APIs will be
removed. As the JEP says, future releases may degrade the SM APIs so
that System.getSM re
Forgot to cc.
Forwarded Message
Subject: Re: Low level hooks in JDK for instrumentation of permission
checks.
Date: Mon, 14 Jun 2021 15:13:15 +1000
From: Peter Firmstone
To: jdk-...@openjdk.java.net
Clarification, utilize java.security.Provider.
So this might use
