Exporting - the wrong default?

[Stephen Colebourne]

This artificial description/analogy seems to bear no relation to real
world development or the proposal in this thread,

To get any module to work with the basic jigsaw design, it has to
somehow expose a set of packages. 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).

This proposal simply alters how that set of packages is calculated
when processing module-info. It asks the module writer to deliberately
hide something, rather than to slavishy create a super long list of
exposed packages. But the binary format could still list the exported
packages rather than the restrictions.

No more packages would be exposed than with the current proposal. No
more headache inducing problems would be created.

Stephen


On 28 July 2016 at 13:33, dalibor topic <dalibor.topic at oracle.com> wrote:
> In the "exported by default" world view, the assembler is responsible for
> restricting all such headache inducing interactions between these classes,
> originating in different components with different trade offs.
>
> Let's hope for their sake they are really awesome experts at that sort of
> thing, and especially good at handling the potentially exponential
> complexities that can arise from adding new components with further third
> party provided Guns and Bullets to their software system.
>
> In the "failsafe by default" world view, they are responsible for enabling
> "just" the non-headache inducing interactions between those classes, of
> which there in most cases may very well be none.
>
> That's (potentially) a substantial difference in effort necessary to
> accurately make such trade offs, in particular over the maintenance life
> cycle of a software system.