Can this change be documented along with others planned in the new JEP
so these changes are easier to track?
There's no mention of this change in the bug id.
We've placed all future development on hold in software that depends on
Java's Authorization API, (apart from bug fixes), while we figure out
how to manage changes brought about by JEP411.
Thank you.
Peter.
On 8/03/2024 8:31 am, Peter Firmstone wrote:
Sent from my iPhone
On 8 Mar 2024, at 1:35 am, Sean Mullan <sean.mul...@oracle.com> wrote:
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 themselves.
--Sean
Should, when possible. Our software is deeply integrated with the deprecated
Authorization API, we've determined it's not possible. Our only choice is to
fork, so I'd definitely prefer the API to remain. Also if functionality can be
removed rather than degraded, that will make it easier to patch in replacement
functionality.
Thank you,
Peter.
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.
