The below isnt entirely the case or fixed on the key area. Java 17 deprecated AccessController for removal, then Java 24 did actually permanently disable / remove the related SecurityManager implementation. The SM and related Subject APIs are all still there and functional in Java 25, with 1 key exception, just doing either no-op/pass-through/always-reject/etc as appropriate for there actually being no SM, which there can now never be. The APIs may be removed at any time now, from 26+, though havent been just yet. The exceptional case mentioned is the key one of Subject.getSubject(AccessControllContext) which references the SecurityManager API, and started to throw by default in Java 23 unless you set a system property, then was permanently broken in Java 24 to always throw if called.
Though there are 2 APIs for various things here in various Java versions, they have been kept interoperable and interchangeable, so you dont really have to 'be consistent'. You can call the old Subject.getSubject(AccessControllContext) on 17-22(/23 with prop) and get the same value you'd get from the new Java 18+ Subject.current() method regardless whether the Subject was made available via using old Subject.doAs / new Subject.callAs / other. On Java 24-25 you can't call Subject.getSubject() at all, but Subject.current() conversely still picks up the same value from the old Subject.doAs (where its impl changed to use binded values as thats all thats available now), which still remains even though it has also been deprecated for removal since 17. The older APIs may be removed at any time now, though havent been just yet, the only breaking change so far is ensuring you cant actually call Subject.getSubject on 24+ as it throws. So if you call Subject.getSubject, compatibility steps must be taken now for at least 24+ operation. If you then still call any of the other old SecurityManager[-adjacent] methods, other compatibility steps will need to be taken for some future as-yet-unkown JDK like 26+ where all those deprecated APIs get removed. Robbie On Thu, 13 Nov 2025 at 22:54, Matt Pavlovich <[email protected]> wrote: > > Jean-Louis- > > JDK 25 didn’t remove AccessControler.getContext(), only marked it for > deprecation— > > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/AccessController.html#getContext() > > From what I’ve ascertained there are two ‘modes’ of using JAAS API with JDK > 21+ > > 1. Use the legacy JAAS API (ThreadLocals w/ AccessController to fetch the > active Subject) > 2. Use the new JAAS API (ScopedValue w/ Subject.current() to fetch the active > Subject) > > As long as the broker and all modules are consistent, there should be no > issue. > > Thanks, > Matt > > > On Nov 13, 2025, at 4:37 PM, Jean-Louis Monteiro <[email protected]> > > wrote: > > > > Matt, > > > > I'll submit a PR to your branch if you are ok with it. > > No it won't work because we need at least Subject.current() from Java 18+ > > > > I have not checked all the code base yet, but I have also fixed some tests. > > > > > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com > > > > > > On Thu, Nov 13, 2025 at 11:35 PM 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
