On Jul 12, 2016, at 2:00 AM, Remi Forax <fo...@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
