+1 for multiple releases jar and minimum release version JDK25 Il sab 18 ott 2025, 05:44 Jean-Baptiste Onofré <[email protected]> ha scritto:
> +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 > > >
