On 26/09/2016 17:37, Andrew Dinn wrote:
:
That's very good to hear, because your previous phrasing certainly
brought that commitment into question. As I am afraid does your
continued unwillingness to provide motivation for why the current Jigsaw
implementation operates in the way it does.
n.b. I'm not saying this because I personally want to see Jigsaw
drastically changed (although I know others, such as my colleague David
Lloyd, have good reasons for requesting significant changes). No, it's
rather because I think it is important that the rationale for one choice
over another conflicting choice is articulated openly so that the
consequences of making or rejecting any such choice can be understood
and their pros and cons correctly weighed in the balance by all OpenJDK
project members and users who are willing to expend the effort needed to
understand and review those consequences. Isn't that how this project is
supposed to work?
To your last paragraph, this project has an associated JSR and so design
issues and proposals are discussed on jpms-spec-experts. There are
associated -observers and -comments lists for those that want to follow
and comment. Implementation issues are discussed here. It's impossible
to distinguish the discussions sometimes, especially on this list as
there are lots of passionate people with wildly different perspectives
and expectations.
As regards design proposals then there are an infinite number of
choices, esp. when you get into the details. In all honestly, there just
isn't time in the day to write up all the details of every possible path.
On the specific topic of using the security manager to do JLS and JVMS
specified access checks then it doesn't make any sense to me. If I'm
compiling a class A that has a reference to a member in type B then do
you really want the compiler calling into a security manager to ask if
this access is allowed? Security managers don't know anything about the
access control at this level. The permission checks that a security
manager does involve stack walks and computing the intersection of
permissions to see if the effective permissions are granted or not. This
is right when checking access to security sensitive resources (network
end points or files for example) but not at the level of checking if A
has access to a member of B. At run-time then would you really want the
the VM calling out to a security manager when doing JVMS-specified
access checks? If there is no security manager (the common case) then
does it mean that code in class A can access a private field in class B.
Going further then executing the security manager's checkPermission will
likely involve access checks in the VM so how would you handle those?
Hopefully you'll start to see that the access checks that we dealing
with here are at a completely different level to the permission checks
that a security manager implements.
-Alan.
