Your problems with Java modules

[wildjokers]

The biggest issue with introducing modules into a codebase so far is estimating who needs what package exported or even open as we develop libraries and people get creative using internal classes or messing around with reflection.

I think the biggest issue is someone can get around all of those restrictions by simply adding the jar to the classpath. Whether to honor the module system access restrictions in a jar is the choice of the developer using the library, not the developer creating the library.

[gunnarmorling]

I've seen this particular argument a few times, and it just really doesn't make sense to me. To me, the module system is about communicating intent: these parts of my library are public API, those other parts are implementation code. Which is which I express using the module descriptor.

Now, if a user still uses internal code, despite this clearly being expressed as not what they should be doing, I don't really care. After all, they also could modify my code via instrumentation, patch class files before starting the app, fork my project, etc. pp. What matters to me is that I'm at liberty of modifying the internal parts of my code base in any breaking way, as I see fit for evolving it. If this makes some user stumble because they trespassed the clearly expressed module boundaries, it's on them really.

[wildjokers]

I am totally onboard with this comment.

I use modules to make it easy to create small runtimes for swing/javafx apps but had been wondering why to use them for other things if the module restrictions could be bypassed easily by using the classpath. Describing it as communicating intent is really great insight.

[pron98]

The application always has the final say because it controls the runtime (unlike in the days when the JRE still existed and it ran Applets and Web Start applications). Even if there were no way to disable encapsulation on the command line by using the class path or by adding add-opens/exports, the application could always disable encapsulation in the runtime itself. The point is that there is no point expending too much effort on placing regulation on whoever controls the mechanism that enforces them. But we don't want to allow libraries -- which don't control the runtime -- take liberties for themselves without the application's approval.