Remove JavaFX JPMS enforcement

Mon Apr 20 18:36:44 UTC 2020

Hi Bruno
I actually like the fact that JavaFX has been split up into some smaller 
parts.
E.g., javafx.web is the biggest moster in this context and if you do not 
really
need it, it is nice that you leave it out. Also media, swing and fxml 
are not
always needed and so you can leave them out. I even have cases where I only
allow javafx.base because that is all you need to write your view-models and
it is good that you can explicitly separate that from all the graphics 
and control
stuff. So I have absolutely no problem with that kind of modularization.
Michael

Am 20.04.20 um 20:18 schrieb Bruno Borges:
> I do wonder why isn't JavaFX in a single module, like Swing?
>
> 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 <http://brunoborges.io>
>
>
> On Mon, Apr 20, 2020 at 10:36 AM Michael Paus <mp at jugs.org 
> <mailto: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.
>     >>>
>     >>
>
>