Remove JavaFX JPMS enforcement

Mike Hearn mike at
Tue Apr 21 11:30:21 UTC 2020

Maybe needs more maintainers? I opened a PR against that repo
some days ago and it's not been looked at. The JavaFX docs are certainly a
weak point right now, given that the Java 8 era docs aren't really being
maintained, and aren't open source, and the main docsite isn't really
actively worked on either.

On Tue, Apr 21, 2020 at 03:04:10, Bruno Borges <bruno.borges at>

> One thing I do miss in website in terms of documentation is
> the definition of a jmods file and the sdk.
> For new developers looking at the download page, it's really not simple to
> figure it out.
> On Mon, Apr 20, 2020, 15:55 Kevin Rushforth <kevin.rushforth at>
> wrote:
> As of JDK 9, there are a few places in JavaFX that assume the JavaFX
> modules are, in fact modules. While it would likely be technically possible
> to find them all, and make modifications that will allow running JavaFX
> either on the classpath or on the module path, I am not in favor of that. I
> think it would be a step backwards. For one thing, we would lose the
> encapsulation that the module system provides, and applications would be
> able to access internal packages without so much as a warning that it's not
> public API. Also it would increase the testing burden, since that would be
> one more mode in which it would need to be tested to ensure that it doesn't
> break.
> I tend to agree with those who say that this is mostly a documentation
> issue. I suppose it's also a bit of a tooling problem, since first class
> support for modules is still in progress in various IDEs and build tools
> (gradle, maven, etc). The support in the IDEs is pretty good now, and
> gradle 6.4 reportedly has full support for modules. Someone with more
> familiarity with Maven can comment about their module support.
> -- Kevin
> On 4/20/2020 10:31 AM, Michael Paus wrote:
> Oh I see. You are obviously not familiar with the fact that the JDK has a
> built-in test
> which checks whether the JavaFX graphics module is on the module path when
> you
> try to launch an application main class which is derived from the JavaFX
> Application class.
> If you try this and the graphics module is not on the module path the
> launch will fail
> with an error message. That's the only reason why JavaFX programs cannot
> be launched
> completely on the classpath and that's where all the trouble starts. If
> you circumvent this
> test with the trick, I have mentioned before, everything becomes nice and
> easy.
> So for me there are only two questions.
> 1. Is there any proof of a technical reason why JavaFX could not run
> correctly on the classpath?
> 2. If there is no such reason, then why do we torture all the newbies with
> the "intricacies" of the
> module system instead of just removing this barrier?
> As I said before, I have not found any such problem in all the time since
> JavaFX was separated
> from the JDK, so this test seems to be quite artificial to me but of
> course I may be wrong. That's
> why I asked here.
> Am 20.04.20 um 17:25 schrieb Ty Young:
> I'm a bit confused here. if you don't want JPMS then you should be able to
> run everything on the classpath like normal. Netbeans at least doesn't
> force modules wtih Maven. Or is reflection disabled on classpath as of Java
> 9 too unless you have a module-info?
> Michael
> Am 18.04.20 um 12:58 schrieb Ty Young:
> On 4/18/20 5:01 AM, Michael Paus wrote:
> Getting started with JavaFX is made overly complicated by the fact that
> the use of the
> module system is enforced by some code in the JDK. Especially for
> beginners, who just
> want to get some small program running, this is almost always a big source
> of frustration.
> It is not very good marketing for JavaFX to make these initial steps such
> a pain. If you
> need some evidence for this statement, then just follow JavaFX on
> Stackoverflow or similar
> sites (and also this mailing list). Almost every day you can read
> frustrated posts from
> helpless people who would just like to get some JavaFX project running but
> are failing
> because they get lost in the module system jungle.
> Speaking as a long time JavaFX user(literally since Java 8), I have mostly
> disagree that the JPMS is hurting JavaFX.
> That said, I don't think the frustration is misplaced. What you say is
> true(Netbeans mailing list is fill of JavaFX issues) and the end user is
> *NOT* to be blamed here.
> Rather, I think what's to blame is poor documentation, JavaFX requiring
> absurd runtime module VM arguments, and poor/buggy IDE support.
> Starting with documentation, JavaFX uses reflection for things like
> TableView(everyone's favorite) and CSS style sheets. While this may be
> obvious for people who are more experienced, those who are not may be very
> confused when they get an onslaught of error messages regarding reflection.
> Better documentation on what requires reflection, why, and how to enable it
> would be useful.
> Likewise, the notice about having to include to the
> runtime module arguments here:
> Apply to Maven as well, but it's under Ant for some reason. I don't know
> what was changed in JavaFX 14 that now suddenly requires a runtime VM
> argument, but it's a PITA and BS. End users are going to struggle with
> this, and it prevents JavaFX runtime from being purely managed by Maven. No
> other JavaFX version requires this, so it's mind boggling that all of a
> sudden JavaFX needs this.
> Poor/buggy IDE support is really the big one here. I don't know about
> other IDEs but Netbeans DOES NOT provide a project template for creating a
> JavaFX application with setup dependencies. Netbeans, when setup with a
> Maven project, allows you to select an entire project(pom) rather than the
> individual dependencies(jar) which doesn't work. What you search for also
> matters: if you search for "JavaFX" you will get the wrong search results.
> You need to search for "openjfx" which can be confusing.
> Anyway, yeah, it's a PITA. There is also an issue with Ant based projects
> and Netbeans because JavaFX puts its in a folder that is supposed
> to only include the runtime library that has existed for years(literally a
> 1 line fix too). No one really uses Ant anymore so it's probably not a big
> deal now but yeah, getting JavaFX working hasn't been "include and done"
> when it could potentially be that way.

More information about the openjfx-dev mailing list