Exporting - the wrong default?

[Jason Greene]

> On Jul 28, 2016, at 8:09 AM, Stephen Colebourne <scolebourne at 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