It's not too late for access control

[David M. Lloyd]

Not commenting on the entire piece here, just one bit...

On 07/12/2016 11:00 AM, John Rose wrote:
> On Jul 12, 2016, at 8:01 AM, Paul Benedict <pbenedict at apache.org
> <mailto:pbenedict at apache.org>> wrote:
>> This makes great sense to me. Why? Because when I develop a library, I
>> really don't see any great benefit in hiding a type from another package.
>> Let me qualify that.... I really don't see any great benefit in hiding a
>> type from another package **that I own!** (double emphasis). I have
>> inspected all my uses of "package private" and it always comes down to one
>> thing: preventing static linkage to the type from packages **outside my
>> library**.
>
> To me this looks like a simple power struggle between the class author
> expecting a platform for full publicity, and the system assembler expecting
> to be able to control inter-library visibility.  Both can't have the
> final word.
> Shouldn't the assembler have it?  And if the assembler is given absolute
> control over some unit of access control, it seems likely to me that this
> unit has to look a lot like a Jigsaw module.

In the current model though, the assembler doesn't have the control at 
all.  The module author is the one who decides who can access what. 
Before Java 9, it was just by making some things public and some things 
non-public; now it's a question of ensuring that certain packages (maybe 
all) are accessible to all using explicit mechanisms, but the end result 
is basically the same.

If the assembler wants to add nuance to accessibility, they have to 
modify those lovely binary descriptors at assembly time.  I don't think 
Jigsaw's restriction of "public" adds anything over what I propose in 
this regard (note that what I propose does not involve editing classes 
for any reason though); my proposal doesn't really change this one way 
or another, except that it retains the current well-understood 
difference between visibility and accessibility, with the former acting 
not as a security mechanism but a linking mechanism, just like today.

> Note that system assemblers cannot be expected to edit individual classes.
> That would be another scale error.  So in the end, the author of a class and
> of a package has to provide a provisional, local spec. of what's
> visible, while
> the assembler (who works with unmodifiable libraries) owns the global spec.

Yeah but think about it: how different is the need to edit classes from 
the need to edit binary module descriptors, encoded *as* class files? 
Really, the assembler should have to do neither thing, because that's an 
undue burden.

-- 
- DML