JDK-8256362 : JavaFX must warn when the javafx.* modules are loaded from the classpath
  • Type: Bug
  • Component: javafx
  • Sub-Component: application-lifecycle
  • Affected Version: openjfx11,openjfx15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-11-13
  • Updated: 2021-02-12
  • Resolved: 2021-01-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
openjfx16Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Sub Tasks
JDK-8262948 :  
Description
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.

As of JDK 9, the JavaFX runtime expects to be loaded as a set of named  javafx.* modules, and no longer supports loading those modules from the classpath. If it accidentally happens to work on the classpath, then it isn't by design nor it is supported. We are unlikely to address any bugs that might result from this use case. 

As such, the JavaFX runtime should produce a warning if the classes are not loaded from the expected named module.

This restriction should be documented, so this will need a CSR.

The main reason for doing this is to clearly indicate to application developers that they are running in an unsupported mode. Running on the classpath will fail if an application that extends javafx.application.Application, and has led to filing bugs such as JDK-8248122 (which is not the right way to solve it in the first place). It can also lead to applications that work in some modes, but not in others, since it will break encapsulation.
Comments
Changeset: 1d459973 Author: Kevin Rushforth <kcr@openjdk.org> Date: 2021-01-12 20:27:50 +0000 URL: https://git.openjdk.java.net/jfx/commit/1d459973
12-01-2021

In order to catch more of this discussion, the Twitter thread should also be considered: https://twitter.com/johanvos/status/1327540197110771713 (Read the whole thread and not just this initial tweet)
17-11-2020

The mail thread is very interesting. To give my summary of that thread: 1. end users get errors (no javafx.graphics module on modulepath) that they don't understand and that seem pointless. 2. there is however a very clear reason on why these warnings are there: JavaFX is designed to work as a set of modules (which of course does not mean that all JavaFX apps need to be modules too). 3. At this moment, I am not aware of functionality that is broken when using the JavaFX JARs on the classpath, fuelling the assumption that the error is bogus 4. It is very likely though that some functionality is broken, or will be broken in the future (due to different access etc in a modular system), hence it is important we recommend users to use the JavaFX artifacts on the modulepath. It will be impossible to support the JavaFX platform jars running on the classpath, due to differences between packages/modules etc (which currently can mainly be overcome with e.g. add-opens etc) 5. The javafx maven and gradle plugin already do this: if you use those, the javafx artifacts are on the modulepath 6. If you still use other tools/IDE's, or manually start JavaFX on the classpath, (a) that should be allowed, but (b) a clear warning is needed that, which explains that you might run into issues (now or later) This issue will deal with the last point (6b).
17-11-2020

This issue has also been discussed on the mailing list. I therefore add the link to it here: https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025903.html
14-11-2020