I appreciate you sharing your thoughts on maintaining a Java 17 baseline. I understand the motivation behind using multi-release JARs or adopting a security shim, as has been done in Artemis.
I'm ok with the multi release jar as well :-) My intent was to open the discussion and get some guidance about the preference. I'm happy to pull some of the Artemis code into ActiveMQ to move forward. If all Apache projects start doing this, we'd rather extract it to a common place that is reusable across projects. That's another question. For now, I can try to move forward and we can figure out later if we can extract it. Thanks, Jean-Louis -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Thu, Nov 13, 2025 at 7:50 PM Christopher Shannon < [email protected]> wrote: > We can also just copy any stuff out of Artemis for the Classic broker, such > as the security shim if we need it, even if it's just part of it. > > My assumption is it will be less work for fixing Classic than it was for > Artemis but I haven't looked into it yet. > > On Thu, Nov 13, 2025 at 1:35 PM Justin Bertram <[email protected]> > wrote: > > > I can't say it better than Robbie did. I agree with him 100%. > > > > > > Justin > > > > On Thu, Nov 13, 2025 at 12:27 PM Robbie Gemmell < > [email protected]> > > wrote: > > > > > It is possible to support the new Subject API methods without lifting > > > the minimum version, e.g see related/equivalent changes made for doing > > > that in https://issues.apache.org/jira/browse/ARTEMIS-5711 to enable > > > Java 25 support whilst retaining behavior for existing users on e.g. > > > 17 or 21 (discussed on the list previously in > > > https://lists.apache.org/thread/7vspfpmfnfqd6fmvpjzm0kr59b5dm9j2 > > > around related requirement for using Java 25 during release) > > > > > > Though I'd love to upgrade, I'm not sure most users are really going > > > to be ready for a JDK21 minimum quite yet. Definitely feels more like > > > a change for a new release stream, only made with full expectation of > > > supporting the previous stream concurrently as many cant make the jump > > > yet. E.g. even the new Spring major versions still look to be sticking > > > with Java 17 minimum for now, and they aggressively moved to a Java17 > > > minimum a full 3 years ago now, which I think is telling. Moving to 21 > > > minimum would likely preclude them from upgrading to those new > > > releases for their in-tree bits, for both the current and new majors. > > > Most of the frameworks are still based at 17 so it kinda feels like we > > > still should for now. > > > > > > Robbie > > > > > > On Thu, 13 Nov 2025 at 17:29, 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 > > > > > > > > > > > >
