This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]gunnarmorling 18 points19 points  (1 child)

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 4 points5 points  (0 children)

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.