Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Andrew Dinn]

Hi Alex,

Your rationale is very logical. The flaw I see in your argument is not
that it makes invalid inferences, rather that it is based on wrong
premises. Indeed, that flaw is visible in the result. Applying your
logic to the status quo ante and deriving JDK9 will break the most
significant body of code that is built on Java in a way that, as Jason
argues, is /in practice/ impossible to undo. That's not just EE servers
themselves that go down the pan. In consequence of breaking them you
break by the majority of code that is commercially and socially important.

In other words Jason's criticism is not an academic point about how
applications might use the capabilities offered by a JDK like JDK8 vs a
JDK like the JDK9 you are proposing. It's a practical point about how we
keep the ship afloat. His suggestion that some level of privileged
access be supported to allow a controlled continuation of the status quo
is a purely pragmatic suggestion to keep Java working and relevant.

n.b. the key word above is controlled. The current proposal to remedy
this issue at the very least undermines many of the benefits Jigsaw
clearly offers. What is worse is that it will confound the expectations
of users who rely on Jigsaw to manage access only to find that the
promise it offers is not in effect at runtime. I am very concerned that
this will lead to many serious security issues.

In sum, I believe your rejection of Jason's approach on the grounds of
logical coherence risks sinking the ship. At some point logic has to be
qualified and recast in the light of experience. What Jason is proposing
is neither illogical nor incoherent. It does, however, appear to me to
be absolutely necessary given the status quo.

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

On 07/07/16 23:10, Alex Buckley wrote:
> Hi Jason,
> 
> On 7/7/2016 1:17 PM, Jason Greene wrote:
>> I wanted to second Paul’s comments on jams-spec-comments[1], but with
>> some additional thoughts.
>>
>> The proposal takes a step in the right direction by allowing a
>> runtime path to bypass access control. However, the fundamental issue
>> at play is that class visibility is being used as an access control
>> mechanism, and these concerns are really orthogonal notions. One of
>> Java’s most powerful historic capabilities is that it is fully
>> introspective and dynamic, and this has empowered a large ecosystem
>> of frameworks and platforms that have extended the language in novel
>> ways. All of which ultimately lead to it being a dominant server side
>> development platform.
>>
>> A major commonality in modern programming models is the notion of
>> inversion of control. For those unaware, with IOC, a fundamental
>> notion is that the user defines code which is solely focused on a
>> particular concern, and it is completely unaware of other parts of
>> the system which later enhance that code. JSR 250 (part of SE),
>> demonstrates an example, the user simply needs to add a few
>> annotations, and their classes are dynamically augmented at runtime
>> with new behavior.  JSR 330 (also part of SE) is another, a container
>> of some sort is responsible for constructing classes that could be
>> anywhere in any module and injecting those instances based on some
>> set of rules into other classes’ private fields. This sort of thing
>> is very pervasive (most specs that make up Java EE, JPA, Spring,
>> JAXB, CXF, custom serialization frameworks, mock frameworks, etc).
>> Even the JDK itself needs this ability.
> 
> I call this the "School of Abstraction" form of modularity, which is
> about hiding _values_, versus the "School of Encapsulation" form of
> modularity, which is about hiding _names_.
> 
> The Java language and VM, with their name-based rules for accessibility,
> have long been in the Encapsulation school. IoC technologies, with their
> abstraction over class instances, are in the Abstraction school. They
> had to look outside the Java language and VM, to Core Reflection
> (java.lang.reflect), to circumvent name-based accessibility
> (setAccessible).
> 
> In SE 9, the Java language and VM gain stronger name-based accessibility
> (unexported package ==> inaccessible public types) without a
> corresponding uplift in Core Reflection to let IoC technologies
> circumvent it. Thus, tension between the two schools.
> 
>> This brings us to the problem with the proposal. The expectation
>> AFAICT appears to be that the user defining the enhanced code knows
>> the identity of the module enhancing it (e.g. exports dynamic
>> com.foo.app.model to jpa). The module is simply not in a position to
>> know that just “jpa” requires access. There might be more than one
>> version of jpa which needs to be selected dynamically, or jpa might
>> be broken into multiple modules itself. It’s effectively bleeding
>> container/framework implementation details into the user defined
>> code.
> 
> 'exports dynamic' does not have to be qualified with a 'to' clause.
> 
>> To run reliably in a Java EE container, the user would have to not
>> qualify dynamic export, and also define an export on everything to
>> every module always. But then we run into a lot of boiler plate that
>> has to always be added by the user and is easily forgotten and/or
>> misconfigured for a very common use case. This runs counter to the
>> goals of many modern programming models, which seek to eliminate
>> boilerplate.
> 
> A long 'exports dynamic' list is precisely the tension between the two
> schools. Even if an IDE generates and maintains it, its presence is a
> reminder to the developer that his module's _internal packages_ are
> inspected at run time by _external forces_. I understand the viewpoint
> that says "So what? It's the Java way for frameworks to peek into user
> code!", and at the same time I appreciate the viewpoint that says
> "Explicit definitions of a module's content and surface are a good thing
> for long-term maintenance".
> 
>> Additionally now the user is forced to define their visibility wider
>> than necessary, causing potential conflicts that would have otherwise
>> been avoided. Also any security benefit the access control check has
>> seems easily defeated at this point, since IIUC anyone can just
>> compile against a different definition removing the dynamic
>> modifier.
> 
> Point of order: you mention visibility but visibility is about class
> loading, and Jigsaw does not change that. We're talking about
> accessibility -- JLS 6.6 and JVMS 5.4.4.
> 
> Accessibility at compile time can't be easily defeated since changing
> someone else's module declaration to remove 'dynamic' is akin to
> changing someone else's type declaration to turn package->public --
> simply not done.
> 
>> One could address the boilerplate/usabilty issue by inverting this
>> mechanism from opt-in to opt-out (all packages are dynamic export
>> unless a restriction is specified). However the other visibility
>> issues aren’t really addressed.
>>
>> I think the only way to truly solve this problem is to decouple
>> access control and visibility.
> 
> (I know what you mean, but terminology matters, so please excuse the
> following paragraph.)
> 
> Point of order: accessibility is decoupled from visibility in Jigsaw. I
> explain this in exhaustive detail in "Project Jigsaw: Under The Hood" --
> see http://openjdk.java.net/projects/jigsaw/talks/.
> 
>> If the code doing the enhancing/introspection had to obtain the
>> permission which applied everywhere, this would achieve the necessary
>> decoupling and still have decent security. In fact this is already
>> accomplished with the Java security manager today. However if a
>> duplicate mechanism is truly necessary, perhaps a special signed code
>> mechanism, similar to what JSSE providers do today is workable,
>> albeit a bit burdensome to framework developers
> 
> This boils down to a use-site mechanism for saying "I get access!", in
> contrast to a declaration-site mechanism like 'exports dynamic' which
> says "He gets access!". We tend to think declaration-site mechanisms are
> more Java-like, e.g. accessibility modifiers, e.g. default methods.
> 
>> One proposal that was brought up long ago to improve access control
>> that I thought seemed quite powerful would have been to support
>> granting access of package-protected to other modules. That would
>> have resulted in far less things being made public, which I suspect
>> is the motivation for adding additional access control checking. I
>> imagine it’s too late for something like that, but worth mentioning.
> 
> There are many ways to tweak the meaning of accessibility modifiers
> (including the zero-length package access modifier) but fundamentally
> this proposal was a declaration-site mechanism like 'exports [dynamic]'.
> 
> Alex
> 
>> Thanks, Jason
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jpms-spec-comments/2016-June/000053.html
>>
>>
>>  -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>