Remove JavaFX JPMS enforcement

[Bruno Borges]

I do wonder why isn't JavaFX in a single module, like Swing?

<https://docs.oracle.com/javase/10/docs/api/java.desktop-summary.html>
For Java developers to build Swing apps, all they need is a "requires
java.desktop".

But for JavaFX, there are multiple modules.

---
*Bruno Borges*
brunoborges.io


On Mon, Apr 20, 2020 at 10:36 AM Michael Paus <mp at jugs.org> 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 javafx.graphics to the
> >>> runtime module arguments here:
> >>>
> >>>
> >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans
> >>>
> >>>
> >>> 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 src.zip 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.
> >>>
> >>
>
>
>