[jfx16] RFR: 8256362: JavaFX must warn when the javafx.* modules are loaded from the classpath

[Kevin Rushforth]

On Tue, 17 Nov 2020 18:10:13 GMT, Kevin Rushforth <kcr at 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.

I am switching the target branch to `jfx16` now that we are in RDP1 and have forked the stabilization branch.

-------------

PR: https://git.openjdk.java.net/jfx/pull/354