Hacker News Reader

Comment by alex_smart | Hacker News Reader

The use case for modules is to have a unit of organizing code (deciding what is visible and accessible to who) at a higher level of abstraction than a package. It allows library authors to be much more explicit about what is the public API of their library.

Ever wrote "List" in Intellij and instead of importing "java.util.List" Intellij prompts you to choose between like twenty different options from all the libraries you have included in your classpath that have implemented a public class named "List"? Most likely 90% of the libraries did not even want to expose their internal "List" class to the world like that but they got leaked into your classpath just because java didn't have a way to limit visibility of classes beyond packages.

View on HN

Yes, but at what cost? Many libraries can solve visibility problem with package level visibility. And modules cost a lot: dependency management was a non-goal for them, so anyone who wants to use module path instead of classpath, has to declare dependencies twice. It was a big mistake not to integrate modules with a de facto standard of Maven.

> Many libraries can solve visibility problem with package level visibility

The only way of doing this would be to put all classes in the same package. Any nontrivial library would have hundreds of classes. How is that a practical solution?

Well designed non-trivial libraries should be open for extension and thus should not hide most of the implementation details, leaving the risk of too tight coupling to users. E.g. if I‘m not 100% satisfied with some feature of a library, I should be able to create a slightly modified copy of implementation of some class, reusing all internal utilities, without forking it. So no, modules as means to reduce visibility are not as cool as you think. And given the specific example of the list, it’s possible to filter out irrelevant suggestions for auto-complete or auto-import in IDE settings.

So goalpost moved from “libraries can solve visibility problem with package level visibility” to “libraries should not try to solve the visibility problem because it is not even a problem at all”?

No, it has not. If you are software engineer you should understand the difference between what I actually said and what you quote from logical perspective. I said "many libraries", not "all". For majority of use cases package level visibility is sufficient and is more granular. Yes, many libraries have already migrated and include module-info, but they still are fully compatible with classpath and actively use more classic mechanisms for visibility control. How many projects do use modules? I haven't seen a single one yet.

To add to this, modules make it easy for external tools like GraalVM native-image to produce self-contained binaries that are smaller compared to the standard practice of distributing fat binaries (i.e. large JARs).

Reply on news.ycombinator.com