Ok, thanks for the feedback everyone, with it all being thus far being positive and including everyone that acted as the release-manager for the previous several years, I'll continue to proceed down this path.
On Fri, 17 Oct 2025 at 18:32, 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
