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

[Kevin Rushforth]

Is this any better? It adds an example module-info.java file to 
JavaBeanXXX as is done in the FXML class.

------------------------------------------------------------------------------------------
NOTE: If the Java Bean class is in a named module, then it must be 
reflectively accessible to the javafx.base module. A class is 
reflectively accessible if the module "opens" the containing package to 
at least the javafx.base module. For example, if com.foo.MyBeanClass is 
in the foo.app module, the module-info.java might look like this:

module foo.app {
    opens com.foo to javafx.base;
}

Alternatively, a class is also reflectively accessible if the module 
"exports" the containing package unconditionally.
------------------------------------------------------------------------------------------

Comments?

-- Kevin


Kevin Rushforth wrote:
>
>
> 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)
>>