JVM stack is about to be massively modernized

5 min readJust now

–

No one likes to fight with a build tool. Especially when you try to do some routine task, like upgrading your libraries/toolchains versions and suddenly you get an error you don’t understand what to do with. We all have been there and for some reason build tools nevertheless cause problems don’t help us to solve it anyhow. That’s just unacceptable.

However, not only that

Let’s say I’d like to add jmh into my build.

<plugin>   <groupId>org.apache.maven.plugins</groupId>   <artifactId>maven-shade-plugin</artifactId>   <version>3.2.1</version>   <executions>       <execution>           <phase>package</phase>           <goals>               <goal>shade</goal>           </goals>           <configuration>               <fi...

5 min readJust now

–

However, not only that

Let’s say I’d like to add jmh into my build.

<plugin>   <groupId>org.apache.maven.plugins</groupId>   <artifactId>maven-shade-plugin</artifactId>   <version>3.2.1</version>   <executions>       <execution>           <phase>package</phase>           <goals>               <goal>shade</goal>           </goals>           <configuration>               <finalName>${uberjar.name}</finalName>               <transformers>                   <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">                       <mainClass>org.openjdk.jmh.Main</mainClass>                   </transformer>                   <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>               </transformers>               <filters>                   <filter>                       <!--                           Shading signed JARs will fail without this.                           http://stackoverflow.com/questions/999489/invalid-signature-file-when-attempting-to-run-a-jar                       -->                       <artifact>*:*</artifact>                       <excludes>                           <exclude>META-INF/*.SF</exclude>                           <exclude>META-INF/*.DSA</exclude>                           <exclude>META-INF/*.RSA</exclude>                       </excludes>                   </filter>               </filters>           </configuration>       </execution>   </executions></plugin>

Just take a look at how many unnecessary things as a developer I need to think about. What is a shade plugin? Transformers? o_0 what? Excluding signatures from jar file: why is this even needed? Of course it’s just the complexity of shading, but why as a developer you need to deal with all of this complexity if your original goal was “I just want to microbenchmark my code”.

And not only that. Maven developer’s experience is the worst in a class. There is no build avoidance, reactor is a just unusable, build parallelization just doesn’t exist in Maven, incremental compilation leads to incorrect behavior and you can spend hours to find a bug that was introduced by IC that just isn’t aware of ABI changes (or just clean build all the time, but what is the point of IC then?).

Most maven users probably even don’t know, that it’s not Maven that is fast, but Intellij is fast. When you build Maven project, by default JPS (Jetbrains Project System) is used to build your project. It’s just basically an incremental compiler that read a project model was built after Maven import. We have to learn and implement a lot of sneaky tricks to provide really good developer experience with such slow and non-toolable tools.

If I had started to enlist all of the current maven DX problems, it would have taken so many characters, that no one would have read this post.

But what about Gradle

Can you recall without googling what is the difference between api and implementation ? And what does this even mean? What is configuration and what is the difference from configuration phase. And who the hell came up with the idea to use Turing-complete programming language during the configuration phase? Who decided to have mutable god object during configuration phase so that it became impossible to do it in parallel without proper isolation (yes, there is a configuration cache, but step left, step right, and the whole world is invalidated, and project isolation is here, however, there are nuances, so stay tuned). And please, start already deprecating things.

What else

src/main/java
src/main/resources
…

Why this folder structure is so complicated in 2025? It’s just ridiculous, imagine explaining this to the student. Or imagine this in javascript world: src/main/js, src/main/ts, src/test/js, etc. Who would like to use that designed that way? Especially when I have the only language, I’ve no mixed projects. It’s just not enjoyable, and would never be.

Of course, build tools aren’t about joy. This is just a thing we as developers have to deal with. And we hat to deal with that, we are busy developers. The best build tool is the build tool that you never see. However, we can’t afford that. Because life is hard, as just as programming. This is why we need to be smart about where to show up with our request of the choice. We must strive to have reasonable defaults and only appear when the conscious decision from the developer is needed.

In general I could do it until it gets dark, I can tell a lot of stories about how awful the JVM ecosystem is toolingwise.

The fresh start

Imagine when you decided to start a new project, your module configuration would look like this:

product: jvm/app

And that’s it! There is nothing more required. Of course, everything which should be configurable is configurable, and very opinionated defaults are just chosen for you!

And not only that:

Imagine build tool that was designed with IDE support in mind, which is tooling friendly just by design. Imagine what things you could do with that:

Like you try to run the app and it failed with meaningfull message about Main class being not found and you are thinking: what if I just try main in the IDE?