I actually started working on a branch this week to investigate exactly what needs to be changed to support the latest JDK. Your PR corresponds to what I found so that looks good.
I think the multi-release jar is good solution to this problem, much preferred to a reflection-based approach. I also think we should get this into 2.44.0 (i.e. the next release) since we have so many folks asking for it [1] [2]. I don't see any reason to wait given the semantic changes (or lack thereof). Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-4975 [2] https://issues.apache.org/jira/browse/ARTEMIS-5374 On Sat, Oct 18, 2025 at 12:33 PM Robbie Gemmell <[email protected]> wrote: > To be clear, the minimum version for users or developers won't change at > all, still just 17+. Only the JDK version the release build must be > performed with goes to 25 so it can actually enable the 25+ runtime > support. > > So personally I'd just be putting this in a 2.44.0 release (and aiming to > do it fairly soon as Java 25 support is overdue, lack of it is blocking > other projects already). > > On Sat, 18 Oct 2025, 04:44 Jean-Baptiste Onofré, <[email protected]> wrote: > > > +1 > > > > It makes sense to me. Maybe worth to target this in Artemis 2.50 ? > > As Artemis 2.43 is on JDK17+, if we set the minimum version to JDK25+, > > I think it would be a good "indicator" for our users. > > > > I'm in favor of multi-release-jars (and if possible avoid reflections > :)). > > > > Regards > > JB > > > > On Fri, Oct 17, 2025 at 7:32 PM Robbie Gemmell <[email protected] > > > > wrote: > > > > > > I'd like to propose that we require Artemis releases to be created > > > using JDK 25 going forward. Elaboration below, after some key points > > > first. > > > > > > The resulting releases would still only require Java 17+ to run, just > > > as they do today. > > > > > > It would also still be possible to build / develop / test on JDK 17+, > > > just as can be done today. > > > > > > However the release itself would have to be performed using JDK 25+, > > > which the pom would enforce (much as it currently still enforces use > > > of JDK 17 to do the release, for historic reasons that actually no > > > longer hold). > > > > > > The reasoning behind this suggestion is around fixing support for Java > > > 25+, while facilitating us to more nicely handle current breaking > > > changes around Subject class, and also avoid other future breakages > > > there, and similarly around the related removal of the SecurityManager > > > and its API in general in future, whilst still supporting its use on > > > earlier releases like Java 17 where we do have users that need it that > > > we wish to support. > > > > > > These things can be done in a variety of ways. One of the ways > > > involves a bunch of reflection, e.g [1] includes an example of this > > > [lifted from Kafka] with ~600 lines of reflection and indirection > > > classes [plus a bunch more for tests that were not also lifted]. > > > > > > Another approach is using multi-release-jars [2] to target different > > > APIs and using a new enough JDK that you can compile to both the old > > > APIs and the new APIs beginning from the version you wish to start > > > targeting them, JDK25 in this case. I have created a work-in-progress > > > example of this [3] that includes ~150 far simpler lines for the two > > > distinct class versions used to bridge the different API/behaviour > > > support. For the actual Artemis releases based on that approach, JDK > > > 25 would need to be used so that the release contained both the '17+ > > > base class' and the '25+ replacement class' that the respective 17+ > > > and 25+ users would need. Outside of creating the releases though, > > > folks could continue using e.g JDK 17 or 21 to build/develop/test > > > things, just as they do today, and Java 17 would still be the minimum > > > to run the release just as it is today. > > > > > > Thoughts on proceeding with approach in [3] and thus requiring JDK 25+ > > > to create future Artemis releases? > > > > > > Robbie > > > > > > [1] Reflection shim: > > https://github.com/apache/activemq-artemis/pull/5975/files > > > [2] Multi-release jars: https://openjdk.org/jeps/238 > > > [3] Multi-release jar shim: > > > https://github.com/apache/activemq-artemis/pull/5976/files > > > > > > --------------------------------------------------------------------- > > > 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 > > > > > > >
