On 26/09/16 09:19, Alan Bateman wrote:
> On 26/09/2016 04:50, GREGG WONDERLY wrote:
>
>> I still, like others seem to, find it amazingly odd, that the security
>> manager, existing basis for access control is not still what would
>> count. I understand that the JDK itself is not deployed with a
>> security manager impl in most cases, and thus there would be no access
>> context for the security manager to be used against. What’s odd, is
>> that you are still trying to block access to reflective access to the
>> “open JDK”. If it’s really open and it’s really something that the
>> community contributes to, why do we need to block access, hide details
>> and otherwise obfuscate access details? Modularization should just be
>> about separating pieces not needed should it not? Why has this
>> degenerated into such a huge bit of access restriction too?
> When you see "access control" in mails on this list then think the
> access control specified by the Java Language Specification and Java
> Virtual Machine Specification. It's nothing to do with the legacy
> security manager mechanism.
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).
Greg has asked you to talk about the wider controls and precisely why
you don't want to consider security manager control. I am sure there are
good reasons for that. Could you not explain them?
> As regards core reflection then keep in mind that it has always been
> specified to do the same access checks as the Java Language and VM. It
> should not be a surprise if you get IllegalAccessException when
> attempting to access something when the equivalent Java code does not
> compile or where the equivalent bytecode would fail with
> IllegalAccessError.
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. In which case I don't think it is a legitimate
gambit to dismiss the consequences of moving to enforce such a contract
without fairly assessing the potential damage that such a move might
wreak and squarely explaining the countervailing benefits that doing so
would offer in compensation.
Personally, I can see why a move to limit accessibility is attractive
for a variety of purposes -- mostly to do with consequential
opportunities in the way the JVM and JDK runtime can be developed for
future-proofing the managed runtime that Java and other JVM languages,
current or future, ought to profit from. Of course, I see those reasons
because that's what I work on but even then I don't really know what the
rest of the JVM devs think and I would be happy to hear other reasons.
The problem is that no one on this list has really stated any broader
reasons for limiting the current state of reflective access beyond
pushing the line that restricting access is a self-evident good because
it improves security and expresses programmer intentions more clearly.
That position is clearly in complete opposition to the views of a large
swathe of Java developers who feel that those presumed benefits are a
sideshow to the much more important (in their eyes) need to retain the
ability to dynamically wire up linkage. I don't doubt that this latter
capability is /critical/ to a lot of long-term investment in Java that
underpins most of the commercial use of the language. I don't blame
those who made such an investment for i) wanting compelling reasons for
accepting the restrictions you are proposing and ii) (with or without
such compelling reasons) requiring that you either provide some means of
retaining in part or in whole the status quo. If you don't address these
points then I don't see that you can expect anything other than a
wholesale rejection of Jigsaw.
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
