When Nx first dipped its toes into the world of Java, no one could have predicted the ride ahead. From an accidental prototype to enterprise-level adoption, the path of Java support at Nx, particularly through the @nx/gradle plugin, has been one of exploration, iteration, and growing maturity.
Humble Beginnings: An Accidental Start
In February 2020, the Nx team attended their first Java conference, DevNexus. At the time, there was no Java solution from Nx, so we spent the next couple of days thinking about what Nx for Java would look like and what kind of technical challenges would need to be addressed. At the time, Nx was still very much tied to Angular, and while it was technically possible to target Gradle projects this way, it was very rough and never went past the point of being a prototype. Shortly after the conference, Covid lock downs went into place and we put development on pause.
Laying the Foundations with Crystal
Fast forward to 2024, and we made a major change to Nx. Code name Project Crystal was a shift in how Nx worked under the hood. Instead of configuring Nx separately to work with a particular tool, most tools have their own configuration that Nx would reference to get even better configuration programmatically. We started using this inferred approach for all of our core supported tools (like Vite) and would read the config from the associated config file (vite.config.js). Project Crystal made Nx more transparent, simplified how Nx was configured, optimized the configuration, made running tools through Nx even faster, and reduced maintenance required all in one fell swoop. Even during Project Crystal, Gradle was at the forefront of our considerations during this re-architecture. This new architecture set the stage for how Java/Gradle support could be implemented. Nx would get information from Gradle itself for how Nx should run Gradle and Nx would transparently invoke Gradle.
The Birth of the Nx plugin for Gradle
Shortly after inferred projects shipped, we had a reworked version of that early prototype that was ready for some real world testing as @nx/gradle. We announced the plugin and started to use it internally in our closed-source monorepo. We even had interest from some clients who had Java projects that they wanted to consolidate with their existing Nx monorepo.
However, after it’s initial usage, we had started to notice some limitations with this approach. The main limitation was our usage of Gradle's built-in project-report feature which didn't provide Nx with enough detail for accurate configuration. We went back to the drawing board and reimagined how to add support for more complex setups that we saw in the real world.
A Smarter, Deeper Integration: v2 of the Nx plugin for Gradle
By November 2024, the team began experimenting with a v2 of Gradle plugin that aimed to extract richer and more granular data from Gradle itself. This involved building a dedicated Nx plugin for Gradle (dev.nx.gradle). The new approach could detect:
- Available tasks
- Task inputs and outputs
- Dependency chains (
dependsOn) - And more!
At the start of 2025 we started testing this against a much larger and more complex Java codebase, the Spring Boot repository.
Benchmarking Nx in Spring Boot
Even though we had learned a lot from the initial adoption of @nx/gradle, if we can get Nx working here, we can better support other projects with ease. The Spring Boot repo ran more than 8000 tasks for its CI pipeline taking up to 1 hour 40 minutes for the worst case scenario without caching. Integrating Nx into this pipeline required us to make even more improvements to Nx to get things running smoothly. We introduced Batch mode support for running @nx/gradle tasks which allowed Nx to run multiple tasks within a single invocation of Gradle greatly reducing the overhead that Nx would incur running Gradle. We also introduced atomization for running Gradle tests. Today, Nx is able to run the same 8000+ tasks in a worst case scenario with no caching in 50 minutes.
Looking Ahead
As of now, the Nx plugin for Gradle is in a much better state than when we started last year. We can now handle multi-module Gradle projects, as well as polyglot monorepos with existing JavaScript projects. This week, we're going to take a refreshed look at @nx/gradle and what you can expect in the future. We have more plans for Nx’s Java Support (like Maven support) so we're not done yet. In fact, we are actively prototyping a Maven plugin against the Quarkus repository!
What began as an off-the-cuff prototype at a conference has matured into a serious offering for Java developers working in monorepos. The Nx plugin for Gradle has evolved from a limited tool into a reliable, insightful, and enterprise-friendly integration—bringing the Nx developer experience to Java and teams. And with Maven support on the horizon, the journey is far from over.
Stay tuned—because the future of Java at Nx is only just getting started.
Learn more: