On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
> This fix adds documentation and a warning to clarify that loading the JavaFX > modules from the classpath is not a supported configuration. This will not > affect deployments that put the JavaFX modular jars on the classpath, but > will simply warn that it is an unsupported mode. > > JavaFX is built and distributed as a set of named modules, each in its own > modular jar file. This supports running both modular and non-modular > applications. > > The JavaFX runtime expects its classes to be loaded from a set of named > `javafx.*` modules, and does not support loading those modules from the > classpath. The Java launcher will fail to load applications that extend > `javafx.application.Application` unless the `javafx.graphics` module is on > the module path. > > Applications that do not extend `javafx.application.Application` can be > loaded even if the `javafx.*` classes are loaded from the classpath, but this > is an unsupported configuration. > > This creates the perception that there is a problem with the standard case of > loading a subclass of `javafx.application.Application`, since it fails to > load in the case where the JavaFX classes are loaded from the classpath. > Further, allowing applications to run in an unsupported mode that likely has > bugs creates a maintenance burden. Another problem is that when the JavaFX > classes are loaded from the classpath, it breaks encapsulation, since we mo > longer get the benefit of the java module system. > > The primary reason given for application deployments loading the javafx > modules on the classpath usually boils down to one of tooling support, > although both gradle and maven now support modules as do all of the popular > IDEs. This looks good, and I didn't hear objections (on the warning) on this PR nor in JBS or the mailinglist, so this is ok to be merged. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/354
