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 <mp at jugs.org> 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 be that way.
>>>