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
