On 26/09/16 12:11, Alan Bateman wrote:
> On 26/09/2016 10:28, Andrew Dinn wrote:
>
>> :
>> I'm sorry, Alan ,but I think that is disingenuous. When we see "access
>> control" on this list all of us really ought to bear in mind what have
>> been the de facto access control mechanisms for many JDK releases and
>> many more years. There are two such levels of control and one of them is
>> the security manager. That's a historic fact. Your statement above reads
>> very much like an attempt to hijack the discourse by hijacking
>> terminology so it addresses the topic you want to talk about (there is
>> no imputation of such a motive here -- I'm just reporting how it looks).
> I was simply pointing out that when we are discussing access control
> here then we're talking about the access control that is enforced by the
> Java Language and VM. No new terminology.
>
> It is unfortunate that the legacy security manager mechanism also uses
> the term "access control" but it's completely different mechanism that
> is not relevant to anything we are doing here.
I addressed that in the text you snipped. The one point of relevance is
that which the original poster asked about:
-- Why do we need Jigsaw to constrain access control when we can do so
using a security manager?
Do you (or anyone else involved in defining and implementing Jigsaw)
have an answer to that question?
Also, you have used the phrase twice now so I have to ask. Where does
the notion that the "legacy security manager mechanism" is actually a
legacy mechanism come from? Is it to be retired? Or are you just saying
that you think it ought to be legacy because you think Jigsaw makes it
redundant? If the former then can you point out where the decision was
consulted on and agreed by the OpenJDK community? If the latter then I
would regard that as yet more of an imperative for you provide the
original poster with an answer (I'd also advise that you stop using the
term so definitively).
>> Has this really been the specification? If so then many years of
>> differing practice as regards the implementation have made that
>> 'putative' specification worth less than the paper it is (probably no
>> longer :-) printed on.
> The core reflection methods that do access checks (Method.invoke,
> Constructor.newInstance, Field.set, ...) have always specified IAE.
> Compliant implementations have always implemented these checks. So there
> is nothing really here. Core reflection has been loosened slightly so
> that it assumes readability but it is otherwise aligned with the Java
> Language and bytecode.
I find your account of the specification to be very misleading then. Of
course code employing reflection has to protect against IAE because the
methods it uses include it as a checked exception. But the core
reflection API is also specified to provide setAccessible and it has
always been possible to rely on that method to ensure that IAE does not
actually get thrown in a large and well-defined set of cases.
To describe a severe reduction of that set of cases with the words
"there is nothing really here" seems to be even more misleading than
your partial account of the specified API. Given that this has been the
topic of intense discussion and debate here for the last few months I
find it hard to understand how you expect to wave it away with such
light words. Perhaps it would be better if you provided those who are
concerned by this change with a better account of why it really is
needed -- or maybe even considered working towards some more limited
change that attempt to meet both their needs and yours.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
