On 3/7/24 7:35 AM, Peter Firmstone wrote:
Good Evening,
Just noticed the comment below, this is a breaking change.
Recalling earlier discussions on this list about the removal of the
existing Authorization API post JEP411, it was going to be assigned
another overarching JEP.
Yes that JEP is eventually coming in the near future.
Can we have the entire API destructed in one swift action? That is, all
API marked for removal under JEP411 should now throw
UnsupportedOperationException? Keeping the API around as unsupported
operation would also allow us to maintain a fork where the API remains
functional, without breaking compile time compatibility with Java, while
we figure out how to migrate our software over the longer term.
The next major step is to remove support for the Security Manager (SM)
from the JDK. However, the deprecated for removal APIs will not be
removed as part of that - they will be retained and removed at some
later time. Some APIs will be degraded to throw
UnsupportedOperationException but others (such as
AccessController.doPrivileged) will be degraded to behave as if an SM
had not been enabled.
JAAS is a special case in that it has dependencies on the deprecated SM
APIs for uses cases that don't always require the SM to be enabled.
Thus, as described in JEP 411, we introduced new replacement APIs
(Subject.callAs and Subject.current) in JDK 18 (4 releases ago).
Applications depending on JAAS for authentication or authorization cases
that do not require an SM should be migrating to these replacement APIs.
--Sean
Thank you for retaining Java's Authorization API in Java 21 LTS.
Regards,
Peter.
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.
