Me trying to explain the problem behind #ReflectiveAccessToNonExportedTypes

[mark.reinhold at oracle.com]

2016/7/14 14:46:21 -0700, Remi Forax <forax at univ-mlv.fr>:
> 2016/07/14 09:33:04 -0700, mark.reinhold at oracle.com:
>> 2016/7/14 8:06:36 -0700, Remi Forax <forax at univ-mlv.fr>:
>>> ...
>>> 
>>> 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.

Requiring something to be declared explicitly one way or the other,
rather than offer a safe and sensible default, seems very unlike the
rest of the language.

- Mark