I agree with: 1) Remove the Clojure dependency entirely 2) Move the minimum Java baseline to Java 21
The emergence of AI tools (Claude, Cursor, Gemini, etc) might give us an overall boost for the project. We will be able to navigate parts of the codebase that are inherently complex and can make the community as a whole participate more, since the cost of opening a PR will go down. I like to think we will be able to maintain Storm for a decent amount of time. On Sat, 28 Mar 2026 at 09:34, Richard Zowalla <[email protected]> wrote: > > Hi everyone, > > As we all know, Storm is effectively in maintenance mode with only a handful > of active committers keeping the lights on. That's not a criticism, it's the > reality. > > But it means we should be deliberate about reducing complexity wherever we > can, so the people who are here can focus on what matters: keeping Storm > stable, secure, and usable. > > With that in mind, I'd like to propose a Storm 3.0.0 major release with two > key changes: > > 1) Remove the Clojure dependency entirel > 2) Move the minimum Java baseline to Java 21 > > > 1. Removing Clojure > > Storm's core was rewritten in Java years ago, but we still carry ~5,000 lines > of Clojure integration tests, plus supporting modules and build tooling: > storm-clojure, storm-clojure-test, the custom Maven shade transformer, > clojure-maven-plugin, and transitive dependencies like Clojure 1.12.x, > carbonite, tools.logging, which would need adjustments / updates for Maven 4. > > The practical problem: nobody on the current committer roster maintains > Clojure fluency at the level needed to confidently review or evolve these > tests. > They've become frozen artifacts, i.e. we work around them rather than with > them. For a small maintainer team, carrying an entire second language > ecosystem that nobody actively speaks is exactly the kind of complexity we > should shed. > > Meanwhile our Java test infrastructure is already mature. Work is already > underway to port these tests to Java. > > A major version bump is the right moment to drop a language dependency > cleanly. It simplifies the build, lowers the barrier for any new > contributors, and removes tooling that nobody is actively maintaining. > > > 2. Java 21 baseline > > A major version bump is always a possibility to raise the Java baseline. > Moving our baseline from Java 17 to 21 lets us adopt virtual threads, pattern > matching, record patterns, sealed classes, and the foreign function API: all > of which can simplify Storm internals going forward. > For a small team, being able to write less code for the same result is a > real benefit. Most downstream users on current JDK LTS tracks are already on > 21. > > 3. This is a discuss thread, not a vote. Questions for the list: > > - Are there objections to dropping Clojure in a 3.0.0? > - Is Java 21 the right baseline, or should we even consider 25? > - Any other changes that should ride along in a major bump? > - Timeline preferences? > > Looking forward to the discussion. > > Gruß > Richard
