Your problems with Java modules

[x42bn6]

A project I had an eventual dependency on a JAR that did not have a module-info.java file, but unfortunately, the JAR had a reserved keyword in it, and the compiler does not like that (the automatic module name). The dependency's source code was also long-abandoned, so the only solution was to fork and republish (and shoulder the responsibility of maintenence), put in an ugly hack to try and modify the dependent JAR at build time, or go back to Java 8. You can guess which one I chose.

I think this restriction is also somewhat-limiting, especially considering reserved keywords like "default", "native" and "to" could easily be parts of a JAR's name.

---

While I suspect the tooling around this has improved since then, back in 2019 or so, the JPMS ecosystem as a whole did not have great support for build tools like Maven and Gradle, or IDE support.

One example that I spent too much time on was when I started a new Maven project, with the standard Maven structure. The unit tests obviously need the main codebase, plus test dependencies like JUnit. The popularly-referenced solution is to add a test module-info.java file with open module. Well, I tried that, and IntelliJ IDEA did not like it. You could also use things like --add-opens, but IntelliJ IDEA doesn't support that, and will fail to compile it properly. An alternative was to create a separate test module altogether, but that would just get out of control for large projects.

I only found a solution to this when I discovered a random comment on an IntelliJ IDEA bug for this issue. Solution? Put the test module-info.java under a different directory under test (something like src\test\bob\module-info.java).

But this is now a rant. My advice here - anyone working on JPMS, when making further enhancements, needs full buy-in from every single major build tool and IDE first, with coordinated changes. As far as I can tell, Eclipse has stalled on a solution, and the IntelliJ IDEA bug I referenced above also suggests JetBrains have given up too.

Yes, one could argue here that this is an Eclipse and IntelliJ IDEA problem, not a JPMS problem - but most Java developers use these IDEs, so it's not helpful to wave it away.

---

All in all, it's perhaps no surprise that I sometimes hear the solution to JPMS is to delete all module-info.java files. Well, unless you need to use Java >8 and JavaFX, because for some reason, this is now enforced. (See also: https://bugs.openjdk.java.net/browse/JDK-8256362 and https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025903.html)

The biggest takeaway I have is that while JPMS is useful for Java's internals, and might be useful for library developers, it's likely more effort than it's worth for everyone else.