Issue with JavaFX and Jigsaw

[Kevin Rushforth]

The current implementation effectively requires that the containing 
package of the type in question be exported unconditionally, since 
javafx.beans uses the sun.reflect.misc.Trampoline class to reflectively 
call the module. It happens to work if the user exports or opens the 
package to ALL-UNNAMED on the command line, but that isn't something we 
would want to document or recommend. Without changing the implementation 
(which would be quite risky for JDK 9), it seems best to just require 
the application's package to be unconditionally exported in JDK 9 and 
then relax this requirement in JDK 10 to allow it to be exported (or 
opened) just to javafx.base.

-- Kevin


Alex Buckley wrote:
> On 4/10/2017 3:56 PM, Kevin Rushforth wrote:
>> The short version is that JavaFX beans is (mostly) working as expected,
>> except for the misleading exception message. In JDK 9 it is required
>> that any object that is reflected on by JavaFX beans, specifically the
>> items passed to TableView, which are accessed via a
>> PropertyValueFactory, will need to be in a package that is exported
>> unconditionally. In JDK 10 we can look into relaxing this requirement
>> such that the package only needs to be exported to javafx.beans.
>
> "exported unconditionally" -- sorry to be picky but this guidance 
> needs to be a bit tighter. Can't the user export to a (possibly large) 
> set of javaxfx.* modules, rather than unconditionally? Is it OK to 
> _export_ the package (rather than open it) because beans will access 
> only its public types/members? What if the user opens the package 
> anyway (rather than exports it)? I don't know the relationship between 
> the PropertyValueFactory type and the type of the items passed to 
> TableView, but I think the high-level requirement is: some user type 
> must be accessible to JavaFX code, and that is achieved by exporting 
> or opening the type's package to at least the javafx.* modules.
>
> Alex