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 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.