Thanks Richard Below is a summary courtesy of Claude of why we have Clojure in the project. It is not just tests, there is also a DSL
*Why it exists* Storm was originally written in Clojure (by Nathan Marz, ~2011). Over the years the core was rewritten in Java, but the Clojure DSL for writing topologies and the Clojure-based test harness were kept. The DSL lets users define bolts/spouts with Clojure macros instead of Java boilerplate. * How it could be removed* > Phase 1 — Remove the DSL modules (low risk) > The Clojure DSL (storm-clojure) is not used by any core runtime code. No > Java > module imports ClojureBolt or ClojureSpout — they're only instantiated > by the > Clojure macros themselves. Removal steps: > 1. Delete storm-clojure/ and storm-clojure-test/ > 2. Remove their <module> entries from the root pom.xml > 3. Delete storm-buildtools/maven-shade-clojure-transformer/ > 4. Remove the Clojure dependency properties from root pom.xml (clojure > 1.12.4, > tools.logging 1.3.1, carbonite 1.6.0) > 5. Delete storm-starter/src/clj/ examples (or rewrite in Java) > Impact: Users who write topologies in Clojure lose the DSL. This is a > public > API removal — would need a deprecation cycle and a major version bump. > * Phase 2 — Port the tests to Java (high effort, no user impact)* ~4,990 lines of Clojure integration tests in storm-core/test/clj/ cover > nimbus, scheduler, cluster, security, etc. These are the main reason the > Clojure dependency is still load-bearing in the build: 1. Port each test file to Java/JUnit using the existing Java test > utilities > (many already exist in storm-server/src/test/java/) > 2. Remove storm-core/test/clj/ and the clojure-maven-plugin config from > storm-core/pom.xml > 3. Remove the shared test runner at > storm-clojure/test/resources/test_runner.clj > The biggest file is nimbus_test.clj at ~1,982 lines. The tests heavily > use > Clojure-specific helpers (with-simulated-time-local-cluster, > complete-topology), so porting isn't a simple transliteration — the test > harness patterns need Java equivalents. I have created an issue to cover the tests side of things -> https://github.com/apache/storm/issues/8445 I will be adding more PRs to port the tests over the next few days. I am in favour of a 3.0.0 release with Clojure totally removed and using Java 21. Cheers Julien 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 -- *Julien Nioche * digitalpebble.com <http://www.digitalpebble.com/>
