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.h...@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)
