Exporting - the wrong default?

[Stephen Colebourne]

On 2 August 2016 at 12:49, dalibor topic <dalibor.topic at oracle.com> wrote:
> Let's now consider two different scenarios, in which Sling and Stone are
> either public, or not, and denote the variants with a P or N prefix - PSling
> is a public Sling, while NStone is a non-public Stone, for example.
>
> Let's also consider two defaults: permissive (i.e. all packages are
> exported) and fail safe (i.e. no packages are exported).
>
> Permissive:
> PSling + PStone can induce a headache, while the other three cases
> fortunately can not. So a mere 25% opportunity for a headache.
>
> Fail safe:
> none of the four cases induce a headache.

Er, now no-one can use the library.

The purpose of a library is to provide public types for applications
to use. That these have bugs and/or security issues is a fact of life
in software. Developers are not going to suddenly stop using external
OSS libraries.

> Let's now add reflection & setAccessible to the mix.
> ...
> Again, no headache occurs in the Failsafe case, because no packages are
> exported,

Er, now no-one can use the library because it can't operate without
reflection+setAccessible.

I again draw attention to the fact that many many OSS libraries use
reflection+setAccessible, and that the ecosystem relies on it pretty
much everywhere [1], at least in part because beans+properties has
never been addressed.

> Of course, you can get to the same cases starting with a Permissive default
> and then restricting exports of the packages in question.
>
> Yet, there is an interesting difference between the two scenarios:
>
> a) in the fail safe default case you start at no risk of headache inducing
> combinations of Slings and Stones, and then can increase your risk of a
> headache occurring to a certain level by adding exports, while in the
> permissive case you start at a coin toss level of headache risk and have to
> remove exports to decrease it to the same level, and
>
> b) regardless of how many Slings and Stones there are in the mix, you always
> start at no risk of headache inducing combinations of Stones and Slings in
> the fail safe default case, while adding further Slings and Stones to the
> mix makes your initial headache risk significantly greater than a coin toss
> in the permissive case.

Er, but this is such a straw man. There is no "initial headache risk".
The packages have to be exported to actually use the library, and are
today. The vast majority of libraries porting to Java 9 will have to
export all packages because nothing else will work. In virtually no
cases, is the end-user developer going to be changing the exported
packages of the libraries they depend on.

To get any benefit from the new modular scope, existing OSS projects
will require significant backward-incompatible reworking - to take
existing public classes and methods and move them to different
packages. This is major work, and far less likely than just exporting
everything (how many years has it taken to do this in the JDK?).

What I want from jigsaw is a *new* ability, not alteration of the
status quo. ie. to allow developers to *opt-in* to selectively hide
things at the module level *going forward*. Ideally I also want to
hide individual classes, methods and fields, because packages are far
too coarse grained for this.

IMO, we need to get existing OSS libraries migrated to modules ASAP to
maintain the ecosystem, which requires the migration to be really
simple. Get this wrong, and we'll all just carry on using the
classpath, and the last 5+ years of effort in the JDK will have little
value.

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008855.html