A common use case for me is that there is a package that contains functionality to interface with the contents of a package (and it’s subpackages). That could be interfaces, factories, enums, or classes that are required in those interfaces. Then, there are a number of sub-packages that deal with specific implementation details that need not be of any concern to other packages. Ideally, other packages should never need to know the implementation details in those subpackages. They also shouldn’t need to instantiate classes from those subpackages. Let me show an example:
±- public ConfigParser
±- public ConfigEntry
So basically, the idea is that you only need to look into the main package parser to get a high-level understanding of the functionality. You only need to look into parser.json if you’re desperate to know how the mechanics for the JSON implementation work. All of this is too small to be considered to be it’s own module (jar file). In fact, in most cases, this parser package might only be an implementation detail of a module without any significance to other modules. This is one of the beefs that I’m having with Java for a long time: it’s just not possible to model this (IMHO common scenario) with the access modifiers available.
I just noticed in the release notes for M8 the info about private and that Kotlin seems to take a completely different approach: The xml implementation would be able to see private classes/functions of the parser package but not the other way around. I was wondering about the reasons to design private the way it is designed in Kotlin? What are the use cases you have in mind for the visibility of private elements in subpackages? And even more importantly, what would be the Kotlin way to design the parser package shown above?