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
