So, if I'm not correct, does that mean that by choosing option 1, there will no remaining usage of JavaFX internally by Oracle themselves?
Felix On 9 June 2016 at 08:31, Kevin Rushforth <[email protected]> wrote: > As some of you may be aware, JavaFX has shipped a JMX plugin as a separate > jar file along with the JDK (not part of the JRE) in > <JDK>/lib/javafx-mx.jar. Development on this plugin stopped prior to JDK 8 > being shipped, although we continued to ship javafx-mx.jar in JDK 8. > > Are there any developers that still use this? We haven't seen any bug > reports or had questions on it for quite a while. I note that this jar file > has been gone from JDK 9 ea since build 111 and we are trying to determine > how best to address this in JDK 9. > > Our options are: > > 1) Remove it entirely and drop this tooling support > > 2) Continue to ship it as a legacy jar file, meaning that any use would > require command line qualified exports to be added since it uses internal > packages > > 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be one > of the default modules, so it would need to be added with -addmods. > > Obviously #1 would be the least amount of work, and given that it isn't > being actively maintained, might be a viable solution. If we do need to > keep it, then #2 might be less effort than #3, while still preserving the > ability for developers to use it. This is only used for tooling, so > requiring qualified exports, as is done for Robot and PerformanceTracker, > is not a problem. > > Separately, if we don't remove it for JDK 9, we probably will deprecate it > with the intention to remove it in a future release. > > -- Kevin > >
