Me trying to explain the problem behind #ReflectiveAccessToNonExportedTypes

[Paul Benedict]

On Thu, Jul 14, 2016 at 11:33 AM, <mark.reinhold at oracle.com> wrote:

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

I don't thinks can be reasonable assured. With the ability to rewrite
Module Descriptors at packaging, assembly, or run time, I think this effort
is just trying to delay the inevitable. Just as there are ton of reflection
libraries for users, I expect module descriptor rewriting libraries to be
popular too. The only absolute way of stopping this and securing things is
to use the Security Manager. That's the only mechanism in the JDK that has
the authority to stop code from reflecting what is forbidden.


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

I think "exports dynamic *" is tremendously better than listing out per
package. Good suggestion.