I am sorry if this is a question you would prefer not to answer but I believe the answer is significant.
I am sure the entire JavaFX community would love to know if Oracle "eats their own dog food" so to speak. Felix On 9 June 2016 at 10:02, Felix Bembrick <felix.bembr...@gmail.com> wrote: > 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 <kevin.rushfo...@oracle.com> > 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 >> >> >
