Re: Remove JavaFX JPMS enforcement

[Abhinay Agarwal]

Hi Ty Young,

I am trying to identify which part of the documentation changed after JavaFX 
13. The JVM arguments that you have specified are required since JavaFX 11. 
Alternatively, user doesn't need to pass these arguments if they are using 
javafx-maven-plugin to build and run the application.

I might be missing something here. Can you be kind enough to point me to the 
specific issue and the related section in docs so that it can be fixed?

Thanks in advance.

-- Abhinay

From: openjfx-dev  on behalf of Ty Young 

Sent: Monday, April 20, 2020 10:07 PM
To: openjfx-dev@openjdk.java.net 
Subject: Re: Remove JavaFX JPMS enforcement


On 4/20/20 11:36 AM, Ty Young wrote:
>
> On 4/20/20 10:47 AM, Mark Raynsford wrote:
>> Am I missing something here? What absurd arguments are required for
>> Maven projects?
>>
>> I have multiple applications here running in full module-path mode (the
>> applications are modularized, and JavaFX is on the module path), using
>> plain Maven builds with no special arguments, and IDEA as the IDE.
>> This is on JDK 13, with the 13.0.2 JavaFX release from Central.
>>
>
> From the second warning on this page:
>
>
> https://openjfx.io/openjfx-docs/
>
>
> That's the absurd part. JavaFX 14 now requires this as a JVM runtime
> argument:
>
>
> --module-path /path/to/javafx-sdk-12/lib --add-modules
> javafx.controls,javafx.fxml
>
>
> Which wasn't required before. Not only is this a PITA and confusing
> but it also prevents Maven from just handling everything. Netbeans
> uses a custom file for runtime arguments, which the above is added to.
>

Also, it gives JavaFX 12 as an example, which is wrong. It should be 14.

Re: Re: Remove JavaFX JPMS enforcement

[Steve Hannah]

Personally, the lack of a "just add these jars to your classpath" install
option is a big enough pain point that I avoid dependence on JavaFX as much
as possible.   Many of the things I develop are distributed as jar files
and the requirements are (JDK8+).  If I use JavaFX the requirements change
to either ZuluFX8+, or JDK8+ PLUS appropriate JavaFX distribution for your
version of OS/JDK combination.

I've had to develop elaborate bootstrap systems to detect the OS/JDK
version, and download the correct version of JavaFX for the platform before
launch... but these are hacky and painful.  And I'm regularly looking for
options to purge the remaining JavaFX dependencies so I don't need to do
this anymore.

I know my use case is not the same as everyone else's (I make developer
tools mostly), but thought I'd throw that in here in case it resonates with
others.



On Tue, Apr 21, 2020 at 8:50 AM Eric Bresie  wrote:

>
> Thought I would provide a few references (1,2,3,4,5) on JPMS over time
> with a few pros and cons embedded within them .
>
> Maybe some will be of help.
>
> (1) https://blog.joda.org/2018/03/jpms-negative-benefits.html?m=1
>
> (2) https://jaxenter.com/java-9-modules-jpms-basics-135885.html
>
> (3)
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html
>
> (4)
> https://stackoverflow.com/questions/45655210/benefits-of-jpms-project-jigsaw-for-small-applications-libraries
>
> (5) https://www.javaworld.com/article/2878952/modularity-in-java-9.html
>
> Eric Bresie
> ebre...@gmail.com
> > On April 21, 2020 at 6:30:21 AM CDT, Mike Hearn  wrote:
> > Maybe openjfx.io 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 
> > wrote:
> >
> > > One thing I do miss in openjfx.io 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.rushfo...@oracle.com>
> > > 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 

Re: Re: Remove JavaFX JPMS enforcement

[Eric Bresie]

Thought I would provide a few references (1,2,3,4,5) on JPMS over time with a 
few pros and cons embedded within them .

Maybe some will be of help.

(1) https://blog.joda.org/2018/03/jpms-negative-benefits.html?m=1

(2) https://jaxenter.com/java-9-modules-jpms-basics-135885.html

(3) http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html

(4) 
https://stackoverflow.com/questions/45655210/benefits-of-jpms-project-jigsaw-for-small-applications-libraries

(5) https://www.javaworld.com/article/2878952/modularity-in-java-9.html

Eric Bresie
ebre...@gmail.com
> On April 21, 2020 at 6:30:21 AM CDT, Mike Hearn  wrote:
> Maybe openjfx.io 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 
> wrote:
>
> > One thing I do miss in openjfx.io 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 
> > 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 

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

[Rony G. Flatscher]

Hi Michael,

thank you very much for sharing this link, which is very interesting!

Reading the limitation section is interesting and also reveals current 
assumptions of the GraalVM
developers that may not meet reality in full, hence making it a little bit 
cumbersome/difficult to
fully support it in use cases that they have not thought of or have not seen a 
need for (e.g. not
invoking finalize() because it got deprecated in Java 9, where the discussions 
that led to that
deprecation annotation were related to stated misuse of finalize() by Java 
programmers; but in those
discussions it also was undisputed that there are use cases where finalize() is 
actually useful and
important, e.g. in native bridges where finalize() gets used to clean-up Java 
proxies and their
non-Java peers; for that reason finalize() was not "deprecated for removal" and 
should only be
deployed, if there is a good reason; removing the invocation of finalize() is 
just a wrong decision
in that context with implications leading to scenarios where GraalVM might be 
considered to not be
usable). However, GraalVM is also a project in motion/development and as long 
as the ultimate goal
is to become fully compatible with Java hopes are that eventually the current
shortcomings/restrictions get solved/lifted (but some may prefer to wait until 
that has happened).

In any case it is impressive already that you guys have become able to use 
GraalVM for allowing
JavaFX to run on iOS and Android.

Again, thank you very much for your link which helps me a lot to assess that 
route (and to think
about solutions for current problems that may exist in GraalVM in supporting a 
dynamic language,
that needs reflective support and uses JNI).

---rony


On 20.04.2020 19:29, Michael Paus wrote:
> The Android/iOS work is based on GraalVMs Native Image which has some 
> limitations.
> These can be found here: 
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
> I stumbled over the problem with Method Handles when I tried to integrate 
> some third-party
> software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and fixed 
> the problems in
> NSMenuFX.)
>
> Am 20.04.20 um 15:26 schrieb Rony G. Flatscher:
>> On 20.04.2020 15:06, Michael Paus wrote:
>>> This is deviating quite a bit from the original issue of this thread, isn't 
>>> it?
>>>
>>> As a side note: MethodHandles are not supported by GraalVM native image
>>> and so this would probably collide with the attempts to get JavaFX running
>>> on Android/iOS.
>> Would you have some link where there would be a technical overview about how 
>> Java and JavaFX support
>> gets currently realized under Android/iOS? Also, how is reflection supposed 
>> to be carried out on
>> that platform, ie. is java.lang.reflect available?
>>
>> ---rony 

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

Maybe openjfx.io 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 
wrote:

> One thing I do miss in openjfx.io 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 
> 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 

Re: Remove JavaFX JPMS enforcement

[Bruno Borges]

One thing I do miss in openjfx.io 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 
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 javafx.graphics to the
>  runtime module arguments 

Re: Remove JavaFX JPMS enforcement

[Kevin Rushforth]

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 

Re: Remove JavaFX JPMS enforcement

[Tom Eugelink]

JFXtras is split in many modules as well, the question is if it really is that 
important to do. Splitting up in jars -so you don't need to include what is not 
needed- is good, but whether they need to be modules...

The way I see it is that JPMS requires the same amount of effort as OSGi for 
example, but does not provide the same functionality (most importantly class 
load separation) and thus is simply less worthwhile. So either 'we' start 
adding that last piece (I recently learned there is such a thing as JPMS 
layers, which provides for that), or it probably will stay a Java core thing 
only.

Regards, Tom



On 20-4-2020 20:18, Bruno Borges wrote:

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


On Mon, Apr 20, 2020 at 10:36 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 

Re: Remove JavaFX JPMS enforcement

[Philip Race]

On 4/20/20, 11:18 AM, Bruno Borges wrote:

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


Well it isn't because we wanted to do that for Swing. It is because it 
was too hard to decompose it
because of interdependencies between AWT and Swing and 2D. For example 
AWT + 2D APIs are

in the same java.awt package.

And Swing is the 99% use case so it would have amounted to using all of 
the same anyway.


But even if it could have been done likely we would still have had an 
aggregator module to make it easy.


Note that java.datatransfer is required by java.desktop.

-phil.

But for JavaFX, there are multiple modules.

---
*Bruno Borges*
brunoborges.io


On Mon, Apr 20, 2020 at 10:36 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 

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

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 


On Mon, Apr 20, 2020 at 10:36 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 

Re: Remove JavaFX JPMS enforcement

[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


On Mon, Apr 20, 2020 at 10:36 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 

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

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.

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

[Michael Paus]

The Android/iOS work is based on GraalVMs Native Image which has some 
limitations.
These can be found here: 
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
I stumbled over the problem with Method Handles when I tried to 
integrate some third-party
software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and 
fixed the problems in NSMenuFX.)


Am 20.04.20 um 15:26 schrieb Rony G. Flatscher:

On 20.04.2020 15:06, Michael Paus wrote:

This is deviating quite a bit from the original issue of this thread, isn't it?

As a side note: MethodHandles are not supported by GraalVM native image
and so this would probably collide with the attempts to get JavaFX running
on Android/iOS.

Would you have some link where there would be a technical overview about how 
Java and JavaFX support
gets currently realized under Android/iOS? Also, how is reflection supposed to 
be carried out on
that platform, ie. is java.lang.reflect available?

---rony

Re: Remove JavaFX JPMS enforcement

[Mark Raynsford]

Am I missing something here? What absurd arguments are required for
Maven projects?

I have multiple applications here running in full module-path mode (the
applications are modularized, and JavaFX is on the module path), using
plain Maven builds with no special arguments, and IDEA as the IDE.
This is on JDK 13, with the 13.0.2 JavaFX release from Central.

-- 
Mark Raynsford | https://www.io7m.com

Re: Remove JavaFX JPMS enforcement

[Ty Young]

On 4/20/20 11:36 AM, Ty Young wrote:


On 4/20/20 10:47 AM, Mark Raynsford wrote:

Am I missing something here? What absurd arguments are required for
Maven projects?

I have multiple applications here running in full module-path mode (the
applications are modularized, and JavaFX is on the module path), using
plain Maven builds with no special arguments, and IDEA as the IDE.
This is on JDK 13, with the 13.0.2 JavaFX release from Central.



From the second warning on this page:


https://openjfx.io/openjfx-docs/


That's the absurd part. JavaFX 14 now requires this as a JVM runtime 
argument:



--module-path /path/to/javafx-sdk-12/lib --add-modules 
javafx.controls,javafx.fxml



Which wasn't required before. Not only is this a PITA and confusing 
but it also prevents Maven from just handling everything. Netbeans 
uses a custom file for runtime arguments, which the above is added to.




Also, it gives JavaFX 12 as an example, which is wrong. It should be 14.

Re: Remove JavaFX JPMS enforcement

[Ty Young]

On 4/20/20 10:47 AM, Mark Raynsford wrote:

Am I missing something here? What absurd arguments are required for
Maven projects?

I have multiple applications here running in full module-path mode (the
applications are modularized, and JavaFX is on the module path), using
plain Maven builds with no special arguments, and IDEA as the IDE.
This is on JDK 13, with the 13.0.2 JavaFX release from Central.



From the second warning on this page:


https://openjfx.io/openjfx-docs/


That's the absurd part. JavaFX 14 now requires this as a JVM runtime 
argument:



--module-path /path/to/javafx-sdk-12/lib --add-modules 
javafx.controls,javafx.fxml



Which wasn't required before. Not only is this a PITA and confusing but 
it also prevents Maven from just handling everything. Netbeans uses a 
custom file for runtime arguments, which the above is added to.

Re: Remove JavaFX JPMS enforcement

[John Hendrikx]

With a not very intuitive hack you can circumvent this problem already now.
Just add a line like this to the file which contains your main class
extending
Application (MyApp).

class MyAppLauncher {public static void main(String[] args)
{MyApp.main(args);}}


I do exactly the same, I construct a fat jar with all of JavaFX included 
and run it as above.


I was looking forward to the module system allowing a clean and easy way 
to have a visibility scope inbetween public and package (by making 
packages hierarchical for example), but it turned into a monster that 
just seems to make projects fragile and hard to build/run.


I suppose it may be possible to just generate and publish JavaFX jars 
without all the module-info files included, but I'm not sure it is as 
simple as that.


--John

Re: Remove JavaFX JPMS enforcement

[Ty Young]

On 4/18/20 7:40 AM, Michael Paus wrote:

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.



The custom Maven runtime arguments shouldn't exist, period. They didn't 
exist before 14 and there was zero discussion here as to why they are 
suddenly required on this mailing list. It just kinda came out of no where.



Also, correction, the wiki is wrong: that JVM argument is ONLY for Maven 
projects, not Ant.



I still stand that the fault isn't JPMS but rather people not willing to 
add documentation or support for it. When JavaFX fails to reflect on a 
class file or a CSS file it could suggest that it needs to be "open"ed.





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.



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.

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

Possibly - I posted this because, being ultimately still a product of the
Java group at Oracle, I'm sceptical JavaFX will become *less* dependent on
the module system when the trend has been to use it more.

So there are at least two usability problems:

1 - needing additional downloads and new JVM flags to use JavaFX as modules
rather than ordinary JARs

2 - needing to open packages to JavaFX so it can reflect over them (not a
problem if your app runs on the classpath, but can hit you the moment you
use a component that's been modularised)

The first one has a few workarounds/solutions but what I do is go with the
flow and prepare my own JDK using jlink, which has JavaFX baked in like it
did before. I use a variant on this script:

https://gist.github.com/mikehearn/b18842d45181ac150ec9e6d0b2bb1e24

The output is a JDK directory I can point my IDE at. It's seen as a normal
JDK, but like in Java 8 JavaFX is now fully baked in and available by
default. Because it's already on the module path no special JVM flags are
required.

Probably someone (me?) should upload JDKs for each platform that are "fully
baked" like this.

That leaves the second problem, for which there's no good solution with the
current JFX API. Dependency injectors fundamentally don't mix well with
JPMS. Using Lookup objects is a backwards compatible addition that would
remove part of the pain of using modules with JavaFX because you'd no
longer need to remember to add special incantations to a module-info.java to
enable reflection - incantations which might change between JFX versions as
reflection uses are added or changed.





On Mon, Apr 20, 2020 at 15:06:16, Michael Paus  wrote:

> This is deviating quite a bit from the original issue of this thread,
> isn't it?
>
> As a side note: MethodHandles are not supported by GraalVM native image
> and so this would probably collide with the attempts to get JavaFX running
> on Android/iOS.
>
> Am 20.04.20 um 11:28 schrieb Mike Hearn:
>
> With respect to reflection, it seems like the module system really wants
> you to use Lookup capabilities rather than "open" modules to reflection.
> That is, JFX could be changed to use
>
> var objects = FXMLLoader.load(MethodHandles.lookup(), new URL(""));
>
> The semantics of a Lookup are that it grants whoever holds the object the
> same access rights as whoever created it. Thus if an object creates a
> Lookup and gives it to a framework, that framework can access anything the
> object could itself access.
>
> The lookup object would then be used to do reflection rather than the
> classical reflection API. With this change the API would guide you to a
> form that always works, regardless of module configuration.
>
> Due to its nature as a GUI toolkit JFX often needs to reflect over user
> code. It may be worth considering a deeper upgrade in which a Lookup object
> is provided during application startup, and passed in to the framework e.g.
> the Application class. Lookup objects can be 'teleported' so JFX components
> that wish to work with user GUI code generically can then fetch a Lookup
> from a central place. However, this wouldn't allow overriding of access
> control (i.e. FXMLLoader that takes such a lookup and teleports it to the
> right class for access, wouldn't be able to access private fields, because
> the original place where the lookup was created also couldn't).
>
>

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

[Rony G. Flatscher]

Hi Johan,

On 20.04.2020 15:54, Johan Vos wrote:
> The JavaFX implementation used in Android and iOS is using 100% the same code 
> as the one on desktop.
> JavaFX internally uses reflection, and that is supported indeed (can be used 
> in app-specific code
> as well).
> The best place to get started is at https://github.com/gluonhq/client-samples

thank you very much for both, the link and assuring that reflection is still 
available to apps as well!

---rony

>
> On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher  > wrote:
>
> On 20.04.2020 15:06, Michael Paus wrote:
> > This is deviating quite a bit from the original issue of this thread, 
> isn't it?
> >
> > As a side note: MethodHandles are not supported by GraalVM native image
> > and so this would probably collide with the attempts to get JavaFX 
> running
> > on Android/iOS.
> Would you have some link where there would be a technical overview about 
> how Java and JavaFX
> support
> gets currently realized under Android/iOS? Also, how is reflection 
> supposed to be carried out on
> that platform, ie. is java.lang.reflect available?
>
> ---rony
>

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

[Johan Vos]

Hi,

The JavaFX implementation used in Android and iOS is using 100% the same
code as the one on desktop.
JavaFX internally uses reflection, and that is supported indeed (can be
used in app-specific code as well).
The best place to get started is at
https://github.com/gluonhq/client-samples

- Johan

On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher 
wrote:

> On 20.04.2020 15:06, Michael Paus wrote:
> > This is deviating quite a bit from the original issue of this thread,
> isn't it?
> >
> > As a side note: MethodHandles are not supported by GraalVM native image
> > and so this would probably collide with the attempts to get JavaFX
> running
> > on Android/iOS.
> Would you have some link where there would be a technical overview about
> how Java and JavaFX support
> gets currently realized under Android/iOS? Also, how is reflection
> supposed to be carried out on
> that platform, ie. is java.lang.reflect available?
>
> ---rony
>
>
>

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

This is deviating quite a bit from the original issue of this thread, 
isn't it?


As a side note: MethodHandles are not supported by GraalVM native image
and so this would probably collide with the attempts to get JavaFX running
on Android/iOS.

Am 20.04.20 um 11:28 schrieb Mike Hearn:

With respect to reflection, it seems like the module system really wants
you to use Lookup capabilities rather than "open" modules to reflection.
That is, JFX could be changed to use

var objects = FXMLLoader.load(MethodHandles.lookup(), new URL(""));

The semantics of a Lookup are that it grants whoever holds the object the
same access rights as whoever created it. Thus if an object creates a
Lookup and gives it to a framework, that framework can access anything the
object could itself access.

The lookup object would then be used to do reflection rather than the
classical reflection API. With this change the API would guide you to a
form that always works, regardless of module configuration.

Due to its nature as a GUI toolkit JFX often needs to reflect over user
code. It may be worth considering a deeper upgrade in which a Lookup object
is provided during application startup, and passed in to the framework e.g.
the Application class. Lookup objects can be 'teleported' so JFX components
that wish to work with user GUI code generically can then fetch a Lookup
from a central place. However, this wouldn't allow overriding of access
control (i.e. FXMLLoader that takes such a lookup and teleports it to the
right class for access, wouldn't be able to access private fields, because
the original place where the lookup was created also couldn't).

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

With respect to reflection, it seems like the module system really wants
you to use Lookup capabilities rather than "open" modules to reflection.
That is, JFX could be changed to use

var objects = FXMLLoader.load(MethodHandles.lookup(), new URL(""));

The semantics of a Lookup are that it grants whoever holds the object the
same access rights as whoever created it. Thus if an object creates a
Lookup and gives it to a framework, that framework can access anything the
object could itself access.

The lookup object would then be used to do reflection rather than the
classical reflection API. With this change the API would guide you to a
form that always works, regardless of module configuration.

Due to its nature as a GUI toolkit JFX often needs to reflect over user
code. It may be worth considering a deeper upgrade in which a Lookup object
is provided during application startup, and passed in to the framework e.g.
the Application class. Lookup objects can be 'teleported' so JFX components
that wish to work with user GUI code generically can then fetch a Lookup
from a central place. However, this wouldn't allow overriding of access
control (i.e. FXMLLoader that takes such a lookup and teleports it to the
right class for access, wouldn't be able to access private fields, because
the original place where the lookup was created also couldn't).

Re: Remove JavaFX JPMS enforcement

[Glenn Holmer]

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. 

> I'd now like to have some feedback of the community about this.

Making it easy for beginners is the job of an IDE. NetBeans 12.0 beta3
can already create modular JavaFX projects using Maven in which "run
project" and "debug project" work out of the box. Look for the addition
of out-of-box profiling support in beta 4 (hopefully the last before
12.0 releases).

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

RE: Remove JavaFX JPMS enforcement

[Mohammad Saleem Yusuf]

Michael,
I completely agree with you. I am Professor at a community college (NHTI) and 
teach entry level courses to students who have just graduated from high school.
About a year ago (JDK 8 to 11), I started including Java FX in my Java course, 
but after that I had to remove it (JDK > 11.03) as the Oracle examples on web 
stopped working. I noticed that the textbook I use (Java, The Complete 
Reference 11 ed, Oracle Press) also took Java FX out.

I really like JavaFX and I also teach Microsoft and Google (Android) courses. 
For GUI, they also use similar technologies in WPF, UWP and Android 
Development. It would be very helpful to make Java FX use easy again, so 
students start using Java FX again. I tried for a while but gave as I don't 
have to time to do all the research and install additional software.

M. Saleem Yusuf



-Original Message-
From: openjfx-dev  On Behalf Of Michael 
Paus
Sent: Saturday, April 18, 2020 6:01 AM
To: OpenJFX 
Subject: Remove JavaFX JPMS enforcement

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.

In order to make JavaFX more easily accessible, especially for beginners, I'd 
like to start a discussion here about the possibility to unconditionally remove 
the JavaFX JPMS enforcement. IMHO this enforcement is simply not necessary and 
is just the root for a lot of frustration with JavaFX. It should just be 
possible to put all the JavaFX jars on the classpath (instead of the module 
path) like you would do with any other external dependency in a non-modular 
setup.

With a not very intuitive hack you can circumvent this problem already now.
Just add a line like this to the file which contains your main class extending 
Application (MyApp).

class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}}

Because of this launcher it is now possible to put all dependencies and all 
JavaFX jars on the classpath and to completely forget the module system with 
all its intricacies and pitfalls.
But why should people be forced to use such dirty tricks? The better 
alternative would be to just lift the current constraint.

I am using this trick for a long time now, even on bigger projects, and I have 
never ever experienced any problem resulting from this. Even in theory I don't 
know anything that could prevent a formally correct module jar to also work on 
the classpath (which is of course not true the other way round). Therefore I 
say that this constraint is just not necessary and only does a lot of damage to 
JavaFXs reputation.

I'd now like to have some feedback of the community about this.

Michael

Re: Remove JavaFX JPMS enforcement

[Tom Eugelink]

I'm in the process of porting an app from Java 8 to Java 11. Just getting it to 
run in classpath mode is not that hard anymore; upgrade a bunch of libraries 
and you're set.

As an experiment I'm now activating JPMS. Right! What a lot of work! Do you 
have any idea how many fairly common libraries not even include an automatic 
module name in the manifest? Let alone being full fledged modules. It seems 
modules is a threshold a lot of projects see no need to cross. So I figure most 
JavaFX projects also run in classic classpath mode, hence that would be the 
main usage of the library. Just sayin'

Tom


On 18-4-2020 16:56, Weiqi Gao wrote:

I have built both non-modular and modular JavaFX apps in the past five years, 
and I agree that bootstrapping a modular Hello World JavaFX application is not 
as trivial as bootstrapping a non-modular one.

The big challenges are related to the JPMS. These challenges are not unique to 
JavaFX. They are present in almost all libraries that are going through the 
modularization process. (JAXB for example.)

The good news in this regard is that with a combination of tools like Gradle 
and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular 
JavaFX application has become a non-event that can be done in minutes.

And after that initial setup, further development of the application is almost 
the same as for non-modular JavaFX applications, with the occasional need to 
add an exports or an opens line to the module-info.java file to allow FXML (or 
the dependency injector of your choice, I used Juice and Micronaut in two 
different projects to good effect) reflective access to your controller classes.

My IDE of choice, IntelliJ IDEA, works happily with JavaFX.

—
Weiqi Gao

Sent from my iPhone


On Apr 18, 2020, at 7:43 AM, Michael Paus  wrote:

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, 

Re: Remove JavaFX JPMS enforcement

[Weiqi Gao]

I have built both non-modular and modular JavaFX apps in the past five years, 
and I agree that bootstrapping a modular Hello World JavaFX application is not 
as trivial as bootstrapping a non-modular one.

The big challenges are related to the JPMS. These challenges are not unique to 
JavaFX. They are present in almost all libraries that are going through the 
modularization process. (JAXB for example.)

The good news in this regard is that with a combination of tools like Gradle 
and its JavaFX plugin and Java Modularity plugin, bootstrapping a modular 
JavaFX application has become a non-event that can be done in minutes.

And after that initial setup, further development of the application is almost 
the same as for non-modular JavaFX applications, with the occasional need to 
add an exports or an opens line to the module-info.java file to allow FXML (or 
the dependency injector of your choice, I used Juice and Micronaut in two 
different projects to good effect) reflective access to your controller classes.

My IDE of choice, IntelliJ IDEA, works happily with JavaFX.

—
Weiqi Gao

Sent from my iPhone

> On Apr 18, 2020, at 7:43 AM, Michael Paus  wrote:
> 
> 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 

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

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.

Re: Remove JavaFX JPMS enforcement

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