How are Spring Modulith's application modules different from Java Modularity (introduced in java 9)?

[shreyy1234]

How Spring modulith verify modules different from Java Modularity (introduced in java 9)

[JosRoseboom]

Hi @shreyy1234

As far as I understand, I think the confusion is that module is a generic term. In Java's module system, the module is a JAR. In Spring Modulith, the module is a package. So they operate on a different level.

[odrotbohm]

I'll copy my response to a Reddit post for reference:

It's complementary. There are certain things we cannot / do not want to do and vice versa. And there's a different tradeoff in technical complexity. JPMS implies one module per JAR. That means 5 modules mean 5 JARs, build modules and the complexity that comes with that. With Spring Modulith you don't need that, but can still work in such an arrangement. Our focus is logical, domain-driven modules, and only those. We're not in the business of fully modularizing the entire stack.

The integration testing story is a bit cumbersome on JPMS (again, separate module, descriptors, etc.) With Spring Modulith, you basically keep integration testing as you were before, but can still bootstrap modules isolated, or in combinations of various degrees.

In other words, you get a very non-intrusive tool to structure your Spring Boot applications internally. If that app consists of JPMS modules, Spring Modulith will just work fine with those and can add a few more bells and whistles on top (the entire event publication registry, observability, documentation generation story, etc.)

Also, regarding the interplay with build modules:

… Build modules have a couple of upsides (explicit dependencies and their directions, no cycles by definition) but also come with a significant setup overhead. Multiple build files (Maven), or additional build file complexity (Gradle). Dedicated module APIs mean either additional build modules or JPMS, which both are not free lunch either. Also, Spring Modulith easily allows defining different granularity for integration tests (standalone, entire module subtree etc.) within the very same test suite. Much more complex to achieve with build modules.

All that said, build modules are just fine. If you want to use them. Go ahead, Spring Modulith will work fine with them. They're just modularity on a different, more infrastructure-focussed level.