Just reading the javadoc, and later looking at the sources of the JDK to confirm.
E.g compare and contrast the old and new method text and implementation notes on each of these pages between themselves and then with each other. You'll see they often address when calling one of the methods is effectively much the same as calling the other: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/javax/security/auth/Subject.html https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/security/auth/Subject.html Also e.g look at the sources for your JDK installs. At this very second I'm running on a JDK 21 install and its implementation of Subject.current() is simply "return getSubject(AccessController.getContext());" If looking at a JDK25, its deprecated-for-removal Subject.doAs is implemented by calling the new Subject.callAs and adapting the exceptions to match the old API, e.g: https://github.com/openjdk/jdk25u/blob/816cfbfa06c622ec5189b7a127255436698e2297/src/java.base/share/classes/javax/security/auth/Subject.java#L371-L390 If looking at JDK21 its the opposite, its new Subject.callAs did the reverse and called the old deprecated-for-removal Subject.doAs method in its impl, e.g: https://github.com/openjdk/jdk21u/blob/master/src/java.base/share/classes/javax/security/auth/Subject.java#L375-L388 Robbie On Fri, 14 Nov 2025 at 15:49, Matt Pavlovich <[email protected]> wrote: > > Hi Robbie- > > This is great info — do you have a link or reference on how that works? My > understanding was the new JAAS API was using ScopedValue and the old one was > using ThreadLocal and therefore not interchangeable. > > Thanks! > Matt Pavlovich > > > On Nov 14, 2025, at 7:08 AM, Robbie Gemmell <[email protected]> > > wrote: > > > > Elaborated more on my other mail, the "I’m not a big fan of shims b/c > > they require third-party plugins to magically ‘know’ to use the shim > > instead of the JAAS API" isnt really the case. Third parties do not > > need to call the shim (should it exist), and can essentially call > > either old or new JAAS methods directly and interoperate, they dont > > need to know or align...but they'll have the same compatibility hoops > > to jump through in regards to which methods exist and are functional > > on the compilation and runtime JVMs they use/support. > > > > On Thu, 13 Nov 2025 at 22:35, Matt Pavlovich <[email protected]> wrote: > >> > >> Hi Jean-Louis- > >> > >> I did a test build today off the latest 6.2.0 and JDK 25 compiles all > >> classes and test classes. I’m updating Jenkins to kick off a build w/ JDK > >> 25. I think it may ‘just work’. > >> > >> If we need JDK 21 for JAAS, I think we can solve for it with MR jars > >> and/or only requiring JDK 21 for the activemq-jaas library. I’m not a big > >> fan of shims b/c they require third-party plugins to magically ‘know’ to > >> use the shim instead of the JAAS API. > >> > >> The main hold-up of JDK 21-minimum is the use of the broker in unit tests > >> and as an embedded broker in Spring Boot apps. > >> > >> Thanks! > >> Matt Pavlovich > >> > >>> On Nov 13, 2025, at 11:29 AM, Jean-Louis Monteiro > >>> <[email protected]> wrote: > >>> > >>> Hi Matt and all, > >>> > >>> I pulled Matt's branch to start building on Java 25. Jenkins is currently > >>> starting to build. > >>> > >>> I'd like to push some PR's to Matt's branch, but would like to open the > >>> discussion on moving main to Java 21. > >>> > >>> We are currently in Java 17 for compilation. But we will need an API from > >>> Java 18+ (Subject.current() for instance to workaround SecurityManager > >>> removal). I don't think it makes much sense to move from Java 17 to Java > >>> 18 > >>> and I do think we should move to Java 21 instead. We will need Virtual > >>> Threads at some point anyways and they are part of Java 21. > >>> > >>> I'd also like to yank Java 17 from jenkinsfile and keep only 21 and 25. > >>> > >>> I have everything ready and I'm building from there. > >>> Thoughts? > >>> > >>> > >>> > >>> -- > >>> Jean-Louis Monteiro > >>> http://twitter.com/jlouismonteiro > >>> http://www.tomitribe.com > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> For further information, visit: https://activemq.apache.org/contact > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > For further information, visit: https://activemq.apache.org/contact > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > For further information, visit: https://activemq.apache.org/contact > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
