+1 for going with requiring JDK 25 for the release and using a multi release jar as that is going to much simpler for sure.
Having to mess with all the reflection code is going to be a maintenance nightmare and much harder to keep from breaking and I think it's fine to require the release manager to use JDK 25 as it's only release time and not required for normal development, testing or runtime. On Fri, Oct 17, 2025 at 1:34 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 > > >
