We can expect jamm changes to be mostly about supporting new JDK's given the trajectory of the past half decade or so. Given our intent to allow running on the latest LTS JDK across all GA branches, that means we can expect to need to backport jamm changes to all branches to support a new JDK.
To Aleksey's point, however, this is something we're used to. And with jamm the scale of the changes should be modest and the frequency of these changes low. I think having the code in-tree per-branch gives us an optimal balance of ease-of-use with our build ecosystem that we use daily at the expense of slightly more toil on modifying jamm very infrequently. On Thu, Jan 8, 2026, at 11:23 AM, Aleksey Yeshchenko wrote: > Sure, but that is true about absolute majority of C* codebase. Most of our > utility classes are the same in most branches, without changing that much. > It’s not a reason enough to pull everything into a submodule. > > At the end of the day I would rather deal with plain old C* repo branches, > then the combination of jamm repo branches, plus a submodule, plus pointers > to different jamm branches in C* branches. > > Forward merging and backward-porting code is something we are pretty good at. > >> On 7 Jan 2026, at 20:16, Doug Rohrer <[email protected]> wrote: >> >> The last part here is a really good point. Given it'll be something that we >> need in multiple branches, using a submodule may well be the better option. >> >> Copy/paste of changes across several Cassandra branches is, as we all know, >> pretty painful. >> >> Doug >> >>> On Jan 7, 2026, at 7:38 AM, Mick <[email protected]> wrote: >>> >>> >>> >>>> On 6 Jan 2026, at 18:12, Josh McKenzie <[email protected]> wrote: >>>> >>>>> While your solution is the easiest one, undeniably, of course, it >>>>> seems to disregard the existing user base. Some of them are other >>>>> Apache projects too. I think that we are beyond this and we want to >>>>> have it re-usable by other projects too. >>>> >>>> Right now we're a pure consumer of the lib. If we brought it in-tree and >>>> published artifacts from our source, we'd be becoming maintainers of the >>>> lib which is a Big Change. >>>> >>>> I don't think we're ready to sign up for that tbh and I'm weakly against >>>> it. >>>> >>>> So that leaves a) copying code in-tree, or b) submodule. >>> >>> >>> >>> Right, if we're not taking over jamm then we're not needing to maintain it >>> as a separate code repo. (I didn't realise this was the intention either.) >>> >>> Aside from that, a git submodule does have a benefit due to how we can >>> change the branch of it we use and how we need to do that we it comes time >>> to back-porting jdk support to earlier versions. I don't have an opinion >>> here, it's just another point of consideration.
