It's not too late for access control

[David M. Lloyd]

On 07/12/2016 10:43 AM, John Rose wrote:
> On Jul 12, 2016, at 2:00 AM, Remi Forax <forax at univ-mlv.fr
> <mailto: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.

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