On 07/12/2016 04:00 AM, Remi Forax wrote:
----- Mail original -----
De: "David M. Lloyd" <david.ll...@redhat.com>
À: "jigsaw-dev" <jigsaw-dev@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
