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 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 walls around the
implementation of Java to hopefully allow those details to be more readily
enhanced in implementation. But, we are still at this point where all of this
is so much about “how Java works today”, that it seems amazingly intrusive to
productivity to yank the carpet out from underneath every single user/developer
of Java.
It seems less intrusive, overall, to just summarily change the implementation
of details inside of Java when needed because doing that, and breaking people
software, is exactly the same thing that will happen for JDK 9. No-one, it
would appear, is going to be able to “change JVM” implementations to take
advantage of any features in JDK-9 without replacing all the software too.
What is really going to be accomplished? Is it not possible to create SPIs around what is already going to be broken by enhancing implementations of JVM details, as those enhancements are made, and forcing people using “just” those details to introduce the use of the SPIs using standard Java “version inspection” mechanisms through Class.forName(“Some.new.SPI.Implementation”), rather than by summarily breaking everything now, and creating all of this new, essentially pointless churn for developers to have to use the module system?
JavaFX in particular means all desktop applications… Again, this is going to
be the environment where users JDKs are going to update automatically without
replacing and fixing the software they are using, and it will break their
applications with probably no information other than an icon that now seems to
not respond to double clicks.
Gregg
On Apr 17, 2017, at 1:58 PM, Alex Buckley <alex.buck...@oracle.com> 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
