It's not too late for access control

[John Rose]

On Jul 12, 2016, at 2:00 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> First, there is already in the Java ecosystem a notion of non-exported package, packages startings with com.sun or packages containing internal, it was just a convention and not something enforced by the VM. What the JPMS spec does is just to normalize how to declare an exported package and mandate that the VM check this new rule.
> 
> Sure it means that public classes are not accessible/visible by everybody anymore, but a class like sun.misc.Unsafe was never really accessible by everybody despite being declared public.
> 
> Furthermore, declaring if something is exported or not at class level instead of at package level seems wrong to me, usually, several classes works together for a purpose and you want these classes to be exported or not, so it's not something that should be decided at class level.
> 
> So i see the JPMS spec conept of non-exported package as a standardization of an existing practice not something new that people will have trouble to understand and reason about.

My $0.02:

As an author of Unsafe I agree enthusiastically with this viewpoint.  (Well stated, Remi.)  System assemblies (not individual classes or packages) need to isolate portion A of the global package namespace from portion B.

For me, declaring such assembly instructions inside class definitions would be a scale error.  The access control in question is not a relation between individual classes; it's a relation between larger entities: packages.

It's a relief to see the old ad hoc package-scale hiding mechanisms (restricted packages, shared secrets, providers, class loaders, etc., etc.) getting supplanted by a first-class formalism.  It's also scary to see the amount of work involved, but it's worth it.

— John