Me trying to explain the problem behind #ReflectiveAccessToNonExportedTypes

[forax at univ-mlv.fr]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Jeudi 14 Juillet 2016 18:33:04
> Objet: Re: Me trying to explain the problem behind #ReflectiveAccessToNonExportedTypes
> 
> 2016/7/14 8:06:36 -0700, forax at univ-mlv.fr:
> > Let me try to explain again the problem and the possible solution.
> > 
> > ...
> > 
> > What Mark as proposed is to introduce a new "export dynamic" semantics
> > which doesn't allow the package to be visible at compile time but to
> > be visible at runtime.
> > This solve the issue by supposing that everyone will write export
> > dynamic on every non exported package to be backward compatible with
> > the Java 8 behavior.
> 
> That wasn't my assumption.
> 
> The intent here is that the author of a module should be able to declare
> which of the module's packages are exported, and when, and which are
> not.  The author should also be able to be reasonably sure that these
> declarations will not be overridden lightly, by any random code that
> uses reflection.  (Overriding encapsulation via second-class mechanisms
> such as command-line options or container-based module-descriptor
> rewriting, however, is fine.)  This is what strong encapsulation is
> all about.

The choice for the author seems to be strong encapsulation vs users being able to use their favorite reflection library.

> 
> > While i agree that "export dynamic" is a semantics that jigsaw should
> > provide, i disagree with the syntax "export dynamic" because for me,
> > the a non exported package should have this semantics in order to be
> > backward compatible with existing code.
> > So we should have 3 way to export or not a package,
> >   1. don't export at compile time, don't export at runtime
> >   2. don't export at compile time, export at runtime
> >   3. export at compile time, export at runtime.
> > 
> > 2 should be the default, 1 should be use by the package of the JDK (or
> > any other libs) that want strong security, 3 is for the package that
> > defines API (that will be maintained forever).
> 
> A problem with changing the default is that many developers will never
> think to do anything else, and leave all their packages unnecessarily
> exported.  We have examples of this sort of thing elsewhere in Java,
> e.g., default public constructors, which have been problematic for
> years.  Do we really want to repeat that kind of mistake?
> 
> What do you think of allowing wildcards, i.e., `exports dynamic *`?
> That way a developer could explicitly choose to export everything at
> run time, but could do so in a very compact way.

Wildcards seems a great idea.

But if we want authors to make a decision, instead of choosing a default for them,
we should let them to make a decision.

So wildcards should exist in both way 'export dynamic *' or 'export noexport *'
(or whatever we call it) and we should mandate that a module to have an export
wildcard declaration.

It's more verbose that the current settings but at least this make the choice explicit.

> 
> - Mark
> 

Rémi