On 07/12/2016 10:43 AM, John Rose wrote:
On Jul 12, 2016, at 2:00 AM, Remi Forax <fo...@univ-mlv.fr
<mailto: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.
I agree, though I disagree with the concept of a "global" package
namespace, but that's a different discussion.
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.
Absolutely, and I want to re-emphasize that I do not advocate for
changing anything inside class definitions in any way compared to what
is in Java 8. That is in fact the whole point of my proposal: do not
change anything over Java 8; just add a new capability which can be used
to improve security, and which would then subsequently be used within
the JDK to close the various problems which exist due to internal
classes being public.
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.
Sure, and I don't believe my proposal deviates all that far from the
existing work, but it does solve the reflective access problems that
everyone keeps hitting, which arise from the redefinition of public to
relate to exports.
--
- DML
