Following up on this thread...
While writing the unit tests and documentation for this it became clear
to me that it requiring applications to export as public API all
packages used by FXML, Java Beans, and JavaScript callbacks from WebView
is not a reasonable requirement.
The fact that we
Actually, since the API doc for Module#isExported(String) [1] specifies
that it also returns true if the package is opened unconditionally, do
you think I need to mention it in the JavaFX docs as a parenthetical
comment, or it is sufficient to link to Module#isExported(String)?
-- Kevin
[1]
On 4/17/2017 12:56 PM, Kevin Rushforth wrote:
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
I don't follow your logic. All we are saying in this case is that an
application that wishes to migrate to using modules will have to provide
explicit access to the objects that they want another module
(javafx.beans in this case) to access.
-- Kevin
Gregg Wonderly wrote:
The interesting
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
>From a user/developer point of view, a more descriptive error message would
be a big help. I was completely at a loss to understand why I needed to
unconditionally export my packages, I figured there was a requirement from
the JavaFX-side of things but it wasn't clear what it was or why. A
It may be useful to point to the javadoc where it specifies to require the
module to export the packages unconditionally.
It would be a good RFE to relax the exports to at least javafx.beans.
Mandy
> On Apr 10, 2017, at 3:56 PM, Kevin Rushforth
> wrote:
>
> Sorry