> On Jul 28, 2016, at 8:09 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > > As I have shown, in most libraries, > 90%+ of the packages need to be exposed - hiding packages is the > minority/specialist use case (the JDK is unusual in the packages it > wants to hide).
FWIW with jboss modules we ended up with an export everything local by default behavior because for already existing code (it’s a typical use-case to retrofit code), this is your starting point. In cases where your project fits the Java package accessibility model well, then I agree this is also what you want for even a new project. However, it’s not uncommon for a project to break up functionality into factory/delegation patterns with packages that are intended to be private, but the accessibility model just doesn’t support a way other than making the package public. Theres also another common approach, which you see frequently in standards, where you have an API jar and a impl jar. In such a scenario you want to hide all of the packages in impl. Finally a weaker, yet interesting, case worth mentioning, is that I have seen some projects with a very large number of classes break them up into packages for organizational purposes, and this tends to introduce a great deal of “hidden" packages. So I think an opt-in model makes sense, but, unsurprisingly, I like David’s proposal where you can expand the Java package model to allow for essentially friend package-protection. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
