It's not too late for access control

[Paul Benedict]

I agree with David in what his email says. I find everything he has said in
his email to be reasonable. It's not useful for me to repeat what he has
stated. However, I will note that I, too, in my Jigsaw testing have found
myself having difficulty retraining my mind that "public" does not mean
public anymore. During the course of my experimentation, I, at times, found
myself forgetting to export my packages because I am still adjusting my
habits. I have said to myself, "It's public so why can't I see it? Oh,
that's right, the package is not exported." Point being that i was focusing
on the visibility modifier of the class and forgetting how the package
export plays into things.

It's a difficult habit for me to break (evidently) because I am still
making that mistake from time-to-time. :-) With that said, I believe David
is absolutely correct on the downside of having changed the meaning of
"public" since it is now (possibly) bounded by module boundaries. I can't
offer myself up as the prime example of tripping over the change, but I did
want to offer my experience as an example, nevertheless, to emphasis that
David is on the mark with his analysis.

All things being equal with Jigsaw features today, I'd rather have "public"
retain it's global visibility and extend "package private" to the module.
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**.

That's how I really use it. The wisdom in David's suggestion is that the
change from "package private" to "module private" aligns how the visibility
modifier is actually used to protect types. I think it would be a shame to
pass on David's suggestion since it is so elegant, so please seriously
consider it.

Cheers,
Paul

On Tue, Jul 12, 2016 at 8:25 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 07/12/2016 04:00 AM, Remi Forax 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 :)
>>
>> 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 !
>>
>
> I am not suggesting that; we definitely should not do that for reasons
> discussed in the past.
>
> 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.
>>
>
> The key advantage of using package-private is that you can drop the access
> of shared internal classes out of public, and just make that package
> accessible directly to its internal consumers.  From the JDK perspective:
> imagine getting rid of all those "shared secret" classes, for example.  In
> fact many JDK internal classes and APIs could just be hidden, closing
> innumerable security holes.
>
> For many, many existing projects, this approach promises exact
> compatibility with the status quo in terms of accessibility, while also
> opening an avenue forward to improve module security.
>
> 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.
>>
>
> I did not propose deciding at a class level; I think that would be a bad
> idea.
>
> 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.
>>
>
> Except that there is no existing practice here.  Today, if I can access a
> Class or a ClassLoader, I can access all its public members, and this is
> the crux of the whole thing.  There is no valid compatibility-based
> argument for changing this behavior.  The idea is to take the status quo,
> and add a new capability that can optionally be utilized for better
> security, rather than to break the status quo, call it "compatible", and
> completely break many, many users instantly.
>
> --
> - DML
>