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
