It should be pointed out that the only reason IoC containers can succeed with setAccessible() is because developers commonly run without the Security Manager enabled. People who use IoC want to this circumvention on purpose. It's not an oversight -- it's intended. As far as I am concerned, if you're a module running inside of my application, I have every right to reflect into every you. That's my right, of course, unless I have explicitly turned on the Security Manager. So if I want the magic, I can have it. If I want to forbid it, I can.... but I do not buy into the argument the Module System is doing me a favor by preventing me (de facto) from reflecting into the non-exported types.
If this restriction stays (and I am really hoping it doesn't), my next best hope is for Containers like WildFly, Tomcat, SpringBoot etc. to enable me to do this. If the Layer has a hook into amending the Module Descriptor, then I am hoping each Container will automatically set "dynamic" to each non-exported package. I think this will be a highly requested and sought-after feature. Cheers, Paul On Thu, Jul 7, 2016 at 5:10 PM, Alex Buckley <alex.buck...@oracle.com> 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 >> >>
