Before Java 9, the only way to hide private APIs would be to have everything in the same JAR.
If a library is splinted across multiple JARs, then private APIs only to be used internally by library become exposed to everyone, and there will always exist someone making use of them even if explicitly marked as internal.
This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept.
.NET does have the module level directive "InternalsVisibleTo" that declares another assembly as a friend assembly that can use internal API's from the first assembly. So if you have e.g MyLib.Core and then two impls on top say MyLib.Windows and MyLib.OSX, where everyone would only use one of the impl libs but always the core lib (which is why it was split - then you could make internal API in the core lib visible ONLY to the Windows/OSX libs by using InternalsVisibleTo, and users of the library could not see that internal API.
Yep, that is what I meant by mentioning .NET in "This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept."
I see, why would you split a library accross many Jars though? What's the advantages? Isn't it again IOT, so that if you only use part of a jar, you don't need to have the full thing loaded?
Before Java 9, the only way to hide private APIs would be to have everything in the same JAR.
If a library is splinted across multiple JARs, then private APIs only to be used internally by library become exposed to everyone, and there will always exist someone making use of them even if explicitly marked as internal.
This is nothing new to Java, other languages e.g. Ada, Delphi, .NET and even Go have this kind of visibility concept.