Hi,
I would just like to add that many of the problems you have cited would
just vanish if the JPMS
enforcement would be removed from the JDK. There would be no "JavaFX
requiring absurd
runtime module VM arguments" anymore and the IDE integration would just
be straight forward.
JavaFX would become just one more dependency whithout the need for any
special treatment.
I did, however, not say that JavaFX should be de-modularized. For an
expert user who wants
to use the JPMS nothing would change at all.
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.