It's not too late for access control

[Sanne Grinovero]

On Tue, Jul 12, 2016 at 10:00 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
>> Envoyé: Lundi 11 Juillet 2016 16:21:46
>> Objet: It's not too late for access control
>>
>> 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?
>> --
>> - DML
>>
>
> Hi David,
> package private means package private :)

I'm sorry but I don't think this is valid, as there is no such explicit keyword.

The source code that people will be reading doesn't explicitly state
"package private" at all, there just is a notion of default
visibility, and those rules are always a bit confusing to newcomers of
the language. Please don't look at this issue just with the eyes of an
expert: I assume we're all familiar with such peculiarities here, but
that doesn't make it any less weird to newcomers.

Jigsaw is already changing the rules about visibility, so having to
change textbooks and update people on what "default visibility" means
is a minor concern.

On the other hand, having an explicit "public" keyword which doesn't
mean quite what it should, is counter intuitive and doesn't help with
the long term consistency of the language.

I think David's proposal is very sensible, and indeed I also believe
that while we need modularity, this doesn't have to be at the cost of
screwing up the notion of "public".

"public means public" ;)

Regards,
Sanne


>
> One early design idea of jigsaw was to introduce a new modifier "module" with a visibility in between public and package private.
> It's a bad idea !
>
> 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.
>
> regards,
> Rémi
>