We have definitely done it in the past (and so have other projects as noted) but just because we have done it in the past doesn't mean it was a good idea, or should have been done. It goes against semver and it could be quite confusing for a users who may not realize the JDK requirement changed. So generally speaking, we should not be bumping the JDK outside of a major version.
That being said, as you noted, we don't really have too much choice here. Making sure Jetty is up to date and supported I think is the most important thing because there's always new CVEs and January 2025 is not much time. It's probably ok to bump the JDK at this point because ultimately I figure someone is going to complain either way...either we don't bump the JDK requirement and people complain about Jetty and CVEs or we do bump it and people complain about the JDK requirement. One thing we could do is only bump to JDK 17 for the server components and at least keep the client jars compatible with JDK 11. Technically you could just bump only the modules that are related to Jetty which might be some benefit for users that run Artemis embedded and don't even start the webconsole, but at the very least keeping the clients compatible with JDK 11 seems to make sense. This was the approach Kafka has taken with migrating where the server will require JDK 17 but the client will still support JDK 11. If we want to go ahead and bump the JDK now then for 2.39.0 I would think we could: 1. Document the change with a warning the best we can on the release page, email, etc so that users know of the change. 2. Only require JDK 17 for the server and keep the clients JDK 11 compatible. 3. Updating the start up/install scripts to detect if the JDK is too old to print a warning/error would be good. I haven't looked at the Artemis runs script so it might already do this. Then for a future 3.0.0 next year we could require JDK 17+ for everything, clean up deprecations (drop javax entirely, etc) On Wed, Dec 4, 2024 at 4:31 PM Justin Bertram <jbert...@apache.org> wrote: > > The biggest reason 5.x was not bumped was simply because of the whole > "Artemis will become version 6.0" thing that prevented the bump for a long > time. > > Looking back further in the history of Classic, the Java version was bumped > from 5 to 6 in 5.5.x. So there's precedent from several years before the > donation. > > > Is there any reason we can't bump Artemis to 3.0.0? > > I think moving to 3.0.0 would be ideal, but as you note there's lots of > other work that we'd want to do before that (e.g. dropping javax > completely, removing lots of deprecated stuff, etc.). Unfortunately I don't > think there's time for that before we run afoul of the Jetty EOL, and I'm > sure there's going to be folks complaining about that as soon as it > happens. > > I do think we'll see Artemis 3.0.0 relatively early in 2025, but not soon > enough to mitigate this issue. > > > Requiring JDK 17 and Jetty 12 upgrade seem like a good reason for a major > version bump... > > I see the Jetty 12 integration as more of an implementation detail. Users > really have no way of knowing that Artemis embeds Jetty. All the > configuration obfuscates the actual implementation. None of the > functionality or configuration is changing. Therefore, I don't see that as > a compelling reason for a major version bump. > > Typically I would consider the Java upgrade a reason for a major version > bump, but the precedents both in ActiveMQ and other projects (e.g. Camel) > indicate that's not a hard and fast rule. > > > Justin > > On Wed, Dec 4, 2024 at 3:05 PM Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > > > As you said there is a precedent for it but it's probably better for a > > major version. The biggest reason 5.x was not bumped was simply because > of > > the whole "Artemis will become version 6.0" thing that prevented the bump > > for a long time. > > > > Is there any reason we can't bump Artemis to 3.0.0? Requiring JDK 17 and > > Jetty 12 upgrade seem like a good reason for a major version bump and at > > the same time maybe could clean up any deprecated things hanging around. > > Maybe even drop the jms client entirely and just support jakarta, etc. > > > > It would be nice to see some of the outstanding spec issues resolved like > > https://issues.apache.org/jira/browse/ARTEMIS-1262 before bumping but I > > assume that issue in particular won't ever be fixed as there is not a > good > > way to avoid breaking old clients so I don't think it's a blocker to bump > > to 3.0.0. > > > > On Wed, Dec 4, 2024 at 1:04 PM Domenico Francesco Bruscino < > > bruscin...@gmail.com> wrote: > > > > > It makes sense to me because the main JDK 11 builds already ended the > > full > > > support and are in the extended support phase. > > > > > > On Wed, 4 Dec 2024 at 18:50, Justin Bertram <jbert...@apache.org> > wrote: > > > > > > > > What version of ActiveMQ Classic are you referring to making this > > > change > > > > in a minor version? v6.0.0 made the jump to JDK 17, but 5.x did not. > > > > > > > > To be clear, I wasn't referring specifically to the move to 17. I was > > > just > > > > saying, in general, the move to a new version of Java has been done > in > > > > minor releases by both Artemis and Classic. I already outlined where > > this > > > > was done by Artemis (i.e. in 2.20.0). For Classic this has been done > > > three > > > > times: > > > > > > > > - From 5.10.x to 5.11.x the JDK went from 6 to 7 > > > > - From 5.14.x to 5.15.x the JDK went from 7 to 8 > > > > - From 5.16.x to 5.17.x the JDK went from 8 to 11 > > > > > > > > My main point here is simply that this change has a precedent in > > > ActiveMQ. > > > > There are, of course, precedents in other projects as well (e.g. > > Camel). > > > > > > > > > > > > Justin > > > > > > > > On Wed, Dec 4, 2024 at 11:40 AM Matt Pavlovich <mattr...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > On Dec 4, 2024, at 11:17 AM, Justin Bertram <jbert...@apache.org > > > > > > wrote: > > > > > > > > > > > > At first I was hesitant to propose this move in a minor release, > > but > > > > > then I > > > > > > realized we've already done this in both Artemis and Classic. > > > > > > > > > > Hi Justin- > > > > > > > > > > What version of ActiveMQ Classic are you referring to making this > > > change > > > > > in a minor version? v6.0.0 made the jump to JDK 17, but 5.x did > not. > > > > > > > > > > -Matt > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > > > For further information, visit: > https://activemq.apache.org/contact > > > > > > > > > > > > > > > > > > > > > > > > >
