[9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

[Kevin Rushforth]

David Hill wrote:
>
> Current:
>    All classes and properties used in a select-binding have to be 
> declared public. Additionally, if any class is in a named module, then 
> the module must |open| 
> <http://download.java.net/java/jdk9/docs/api/java/lang/Module.html?is-external=true#isOpen-java.lang.String-java.lang.Module-> 
> the containing package for that class to at least the |javafx.base| 
> module (or |export| 
> <http://download.java.net/java/jdk9/docs/api/java/lang/Module.html?is-external=true#isExported-java.lang.String-> 
> the containing package unconditionally).
>
> Suggestion:
>
>    All classes and properties used in a select-binding have to be 
> declared public. If any class is in a named module, then the module or 
> package containing the class needs to be open or include |javafx.base 
> in the export list.|
>
> any better ?
>

It might read better, but is now incorrect. It is not sufficient for a 
module to *export* the package to javafx.base. Nor is it required that 
the module be *open* unconditionally. Rather it must *open* the package 
to javafx.base. The alternative is to export it unconditionally as 
public API of the app:

WORKS:  module foo.app { opens com.foo to javafx.base; }
WORKS:  module foo.app { exports com.foo; }
WORKS (but overkill):  module foo.app { opens com.foo; }

FAILS:  module foo.app { exports com.foo to javafx.base; }
FAILS:  module foo.app { /* does not export or open com.foo */ }


-- Kevin






>
>
> On 5/2/17, 9:04 AM, Alan Bateman wrote:
>> On 02/05/2017 01:21, Kevin Rushforth wrote:
>>
>>> This review is being cross-posted to both openjfx-dev and jigsaw-dev.
>>>
>>> Please review the proposed fix for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8177566
>>> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/
>>>
>>> Details of the fix as well as notes to reviewers are in the bug 
>>> report [1] (e.g., I've also generated separate webrevs for the fix 
>>> itself, the doc changes, and the test changes).
>> Overall I think the approach is okay but I wonder how easy it will be 
>> for joe developer to understand. By this I mean the description in 
>> the javadoc is lengthy and I wonder if it might be better to split up 
>> the two "solutions" so that it the choice is clearer. Related is that 
>> the IAE thrown by MethodHelper.invoke could make it clear that the 
>> package is not exported.
>>
>> -Alan.
>
>
> -- 
> David Hill <David.Hill at Oracle.com>
> Java Embedded Development
>
> "A man's feet should be planted in his country, but his eyes should survey the world."
> -- George Santayana (1863 - 1952)
>