Exporting - the wrong default?

[dalibor topic]

On 02.08.2016 14:47, Stephen Colebourne wrote:
> 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.

OK, let's adjust the "reflection under failsafe defaults" example to 
take the "vast majority" effect into account.

Let's say that a component author is n times more likely to export the 
packages containing Sling and Stone than not, for example by just 
exporting all packages.

In that case, the headache inducing XPSling+XPStone and XPSling+XNStone 
cases give us 2*(n*n) combinations that might cause a headache (i.e. 2n^2).

They are balanced out by XNSling+XPStone and XNSling+XNStone cases, 
which give us another 2n^2 combinations that can't cause a headache.

In addition, there are 8n + 4 other combinations that can't cause a 
headache, such as XNSling+OPStone, etc.

 From this example, I think two things are quite obvious:

a) Regardless of how high n is, the ratio of headache inducing 
combinations vs. the total is always going to be less than a half - i.e. 
the fail safe default always provides less risk than the coin toss of 
the permissive default, regardless of how widespread a practice of just 
exporting all packages to everyone would be.

c) Looking at 
https://www.wolframalpha.com/input/?i=(2n%5E2)%2F(4n%5E2%2B8n%2B4) , 
even assuming that n is as extreme as 15, you get a roughly 44% ratio of 
headache inducing cases - which would still be quite an improvement over 
the coin toss of the permissive case.

If we look at your survey in 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008823.html, 
you found about 20 components that export all packages to everyone vs. 
about 5 that don't. That suggests n may be closer to 4 for some types of 
components.

In that case the ratio of headache inducing combinations ends up being a 
mere 32% compared to the coin toss probability of the permissive default.

I think that's quite a substantial difference.

> 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?).

I'm not sure that the JDK with its millions of lines of code developed 
over decades in hundreds of packages is a perfect example to guide 
expectations of effort necessary to benefit from modules for most 
components in the Java ecosystem.

For example, assuming for the sake of argument that the effort to 
determine and untangle dependencies and exports between packages is 
roughly quadratic in the number of packages, a multi-year effort for the 
JDK would translate to much smaller efforts for components with a much 
smaller number of packages to consider.

As a real world example, in your survey above around half of the 
components have 5 packages or less.

> IMO, we need to get existing OSS libraries migrated to modules ASAP to
> maintain the ecosystem, which requires the migration to be really
> simple.

Yes, a general migratory movement would be great! Of course, many 
component developers may want to continue to support JDK 8, so for 
example http://openjdk.java.net/jeps/238 is important in this context, 
as well.

Outside of individual organizations, it might be quite hard for everyone 
everywhere to migrate at the same time though, so ways for modularized 
and non-modularized components to safely coexist are important in order 
to allow such migrations to take place at the pace their users and 
developers are comfortable with.

For some of the ways the proposed module system design works hard behind 
the scenes to support that approach, please see 
http://openjdk.java.net/projects/jigsaw/spec/sotms/#compatibility--migration 
.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment