In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the broker side and also uses the same classes as the client for various stuff, so it has to be fully converted so you can use broker + client in the same application/test without resorting to containers etc. The 5.x javax broker and jakarta client simply cant be used in the same classloader.
5.x also uses Spring for various bits and a jakarta conversion means using Spring 6, which requires Java 17 as you noted (related aside: 17 wont be the current LTS as of next week, with Java 21 releasing...which has effectively been finalised for a month now since there was no RC2). So essentially it is not as simple to have 'javax modules' and 'jakarta modules' in the same tree for 5.x like it was for the Artemis codebase back in February 2021 when that was originally done. That made a lot of sense at the time since noone was really using them back then. Going forward, I do think having 2 versions is actually preferable, and thats what I choose to do elsewhere, and what I'd say most (but, not all) projects are doing at this later point. It does mean backporting things if supporting both, but also means a simpler build and a nicer testing situation etc, and slightly less user change (just updating the version, not knowing new -jakarta dep exists and also updating version). On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jbert...@apache.org> wrote: > > I don't have a deep familiarity with the internals here so some of the > fundamentals behind the changes aren't clear to me. > > Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How > tightly is "Classic" coupled with Spring? > > Is the coupling with Spring also why the code-base is being moved > whole-sale to Jakarta? It's been a little while now, but when Artemis > implemented Jakarta support back in early 2021 I don't recall any > disruption for current users and no major version change was needed. Both > Java EE and Jakarta EE implementations are based on the same code-base. Is > something like that not possible here? It would simplify maintenance a lot > since fixes/features wouldn't have to be back-ported. > > > Justin > > On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > > > First, I realize that this thread is likely to cause a fight based on past > > history and probably not go anywhere, but with the work being done > > with Jakarta for AMQ 5.x I think it's time to at least bring up the > > ActiveMQ 6.0 discussion. > > > > With all the breaking changes currently targeted for version 5.19.x, such > > as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty > > upgrades and now potentially major OSGi changes, it makes zero sense to me > > to have this next AMQ version as version 5.19.0 as it's completely > > incompatible with the previous version 5.18.x. Users are likely going to be > > in for a rude awakening when trying to upgrade and will be quite confused > > as to why so much is different. > > > > The Jakarta changes should really be a major version upgrade so that it's > > much more clear to users that it's very different from the previous > > version. Another major benefit of going with version 6.0 is that it frees > > up the previous javax releases to continue on with 5.19 or 5.20 because we > > will likely need to support the older javax releases for quite a while. > > > > Also, from my point of view it seems pretty clear that the original goal > > for Artemis to become AMQ 6.0.0 is never going to happen. Artemis has had > > its own branding and versioning for several years now and will likely > > continue that way and not change so I don't really see that as a reason to > > not bump AMQ 5.x to 6.x with all the major breaking changes. > > > > Anyways, I figure there won't be much agreement here but thought I should > > at least throw it out there before we go and release 5.19.x with such major > > breaking changes. > >
