Me trying to explain the problem behind #ReflectiveAccessToNonExportedTypes

[mark.reinhold at oracle.com]

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.

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

- Mark