Me trying to explain the problem behind #ReflectiveAccessToNonExportedTypes

[forax at univ-mlv.fr]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: forax at univ-mlv.fr
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Mercredi 20 Juillet 2016 16:33:29
> Objet: Re: Me trying to explain the problem behind #ReflectiveAccessToNonExportedTypes
> 
> 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.


Choisir c'est renoncer (Andrée Gide) - To choose is to forsake

There are parts of Java that have no defaults, method calls resolution, default methods. There are parts were the defaults was great in 1995 (or later) but that are not great anymore, fields non-private/non-final by default, inference of type variable defaulting to Object instead of reporting an error. And you have defaults that are still great, unlike C++ you don't have to opt-in to enable reflection.

A great strength of Java, is to have resisted to make backward incompatible changes even for good reason, we have renounced to great features to keep backward compatibility, fully reified generics, structural typing of lambdas. In Java, backward compatibility trump all other considerations. And we have all witnesses of the Python2/Python3 debacle, we even know the consequence of not being backward compatible.  

So the only safe and sensible choice is to be to have non-exported packages classes to be available at runtime by default.
And obviously to have a way to declare for a given module that all accesses to a classe of a non exported package are denied at runtime.

> 
> - Mark
> 

Rémi