Hi,
I was chatting to Alex Buckley at DevoxxUS about my experiences migrating a
project to using Java 9 modules (specifically, this project:
https://github.com/trishagee/sense-nine) and mentioned some surprising
behaviour in a module that uses JavaFX. I've been asked to send the
details so people
Trisha, many thanks for forwarding. Here's the fun part of the trace:
On 3/24/2017 2:34 PM, Trisha Gee wrote:
Caused by: java.lang.IllegalAccessException: class
sun.reflect.misc.Trampoline cannot access class
com.mechanitis.demo.sense.client.user.TwitterUser (in module
com.mechanitis.demo.sense.
Hi Trisha,
Thanks for the report and stack trace. I created
https://bugs.openjdk.java.net/browse/JDK-8177566 for further
investigation.
Mandy
> On Mar 24, 2017, at 2:34 PM, Trisha Gee wrote:
>
> Hi,
>
> I was chatting to Alex Buckley at DevoxxUS about my experiences migrating a
> project to
Sorry for the delay in responding.
I added a simple test program to the JBS bug that shows the same
behavior as the application and also an evaluation of the bug.
The short version is that JavaFX beans is (mostly) working as expected,
except for the misleading exception message. In JDK 9 it i
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 for the delay in responding.
>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 helpfu
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 acc
The interesting thing about this issue, is that it points out that even inside
of Oracle, reflection against users objects for “features” of the software
system, is useful practice. At some level, this denial of service is really
just a “control the user” front to an attempt to solidify the wal
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-UNNA
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 th
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 u
Alex Buckley wrote:
OK, so for the JDK 9 docs, "unconditionally exported (or
unconditionally opened)" would be clear.
I was originally thinking to require unconditional export, but since it
will also be fine for an application to open the package
unconditionally, I will make this change and
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]
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 u
14 matches
Mail list logo
