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