It's not too late for access control

[Alan Bateman]

On 11/07/2016 15:21, David M. Lloyd wrote:

> The crux of this access control discussion is that, up until JDK 9, 
> "public" meant "public".  End of story.  If you did not want something 
> to be visible, you made it not public.  Very simple and very clear.  
> The word "public" literally means "accessible to all" after all; 
> that's why the term was selected in the first place, and it is nearly 
> certain that this was the intent of the thing up to this date.
>
> What is being required in the JPMS spec, and, I dare to suggest, what 
> has been generally asked for by the public (and even required by the 
> JDK), is a way to provide an additional capability - the ability to 
> selectively share otherwise unshared code.
>
> The existing Java language accessibility model is (of course) 
> well-understood by experts.  For new developers, the concepts takes a 
> bit of time to explain but can generally be grasped.  In the end the 
> accessibility of a member is generally easily determined by examining 
> the qualifiers of that member.
>
> What has been proposed and implemented in Jigsaw is essentially a 
> completely new approach to access checking.  Because it is new, and 
> because it is essentially untried, I predicted that issues would arise 
> not unlike the ones being currently discussed.  I argue that this 
> approach is not optimal, for at least reasons discussed on this list 
> and in this email, but that even now, it's not too late to change the 
> approach.
>
> I propose, once again, that rather than changing the meaning of 
> "public" to something unintuitive (and indeed counter to the 
> definition of the actual word), we instead allow the selective 
> extension of package-private.  Users would make public any type or 
> member which is *meant* to be public, i.e. accessible by all. Rather 
> than (at best) changing their expectations as to the behavior of 
> "public" only to immediately betray that expectation by forcing them 
> through a backdoor in order to meet practical needs, we ensure that 
> their expectations remain: public members are public, and things that 
> are secret are not public.
>
> Conceptually (and, hopefully, technically) this should not be too far 
> away from where we've arrived at now in Jigsaw, at least as far as the 
> package inventory is shared between modules for the purpose of access 
> control.  Can anyone think of any good reason we should *not* do this, 
> or ways that this would be substantially weaker than restricting public?
It's hard to know where to start on this as what you proposing would 
have massive implications. I think what you are proposing is to drop the 
notion of exporting packages. You didn't mention the dependency module 
or the concept of readability - are you suggesting to drop that too? I 
can't tell if you've grokked that this is the basis for reliable 
configuration. You haven't said how I could release a library that works 
on the class path in some environments and as a module in other 
environments. I don't see how you proposing to do the equivalent of 
qualified exports. I could go on, smarter much people than me could go 
further, but I'm not sure that it's worth spending time on now.

At a high level then I think it's important to understand that a lot of 
time has been put into the design. The proposal in the JPMS has to take 
account that the core platform is very mature. This means compatibility, 
migration and co-existence with the existing world significantly 
influences the design. I have no doubt that if the modules were in the 
Java Language from the start or adding in the early days then the design 
would be different. As regards changing `public` so that it no longer 
implies "accessible to all" then it is unfortunate but it's a change 
that you should be able to get used too quickly.

-Alan