I do wonder why isn't JavaFX in a single module, like Swing? <https://docs.oracle.com/javase/10/docs/api/java.desktop-summary.html> 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 <m...@jugs.org> wrote: > Oh I see. You are obviously not familiar with the fact that the JDK has > a built-in test > which checks whether the JavaFX graphics module is on the module path > when you > try to launch an application main class which is derived from the JavaFX > Application class. > If you try this and the graphics module is not on the module path the > launch will fail > with an error message. That's the only reason why JavaFX programs cannot > be launched > completely on the classpath and that's where all the trouble starts. If > you circumvent this > test with the trick, I have mentioned before, everything becomes nice > and easy. > > So for me there are only two questions. > 1. Is there any proof of a technical reason why JavaFX could not run > correctly on the classpath? > 2. If there is no such reason, then why do we torture all the newbies > with the "intricacies" of the > module system instead of just removing this barrier? > > As I said before, I have not found any such problem in all the time > since JavaFX was separated > from the JDK, so this test seems to be quite artificial to me but of > course I may be wrong. That's > why I asked here. > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > I'm a bit confused here. if you don't want JPMS then you should be > > able to run everything on the classpath like normal. Netbeans at least > > doesn't force modules wtih Maven. Or is reflection disabled on > > classpath as of Java 9 too unless you have a module-info? > > > > > >> > >> Michael > >> > >> Am 18.04.20 um 12:58 schrieb Ty Young: > >>> > >>> On 4/18/20 5:01 AM, Michael Paus wrote: > >>>> Getting started with JavaFX is made overly complicated by the fact > >>>> that the use of the > >>>> module system is enforced by some code in the JDK. Especially for > >>>> beginners, who just > >>>> want to get some small program running, this is almost always a big > >>>> source of frustration. > >>>> It is not very good marketing for JavaFX to make these initial > >>>> steps such a pain. If you > >>>> need some evidence for this statement, then just follow JavaFX on > >>>> Stackoverflow or similar > >>>> sites (and also this mailing list). Almost every day you can read > >>>> frustrated posts from > >>>> helpless people who would just like to get some JavaFX project > >>>> running but are failing > >>>> because they get lost in the module system jungle. > >>> > >>> > >>> Speaking as a long time JavaFX user(literally since Java 8), I have > >>> mostly disagree that the JPMS is hurting JavaFX. > >>> > >>> > >>> That said, I don't think the frustration is misplaced. What you say > >>> is true(Netbeans mailing list is fill of JavaFX issues) and the end > >>> user is *NOT* to be blamed here. > >>> > >>> > >>> Rather, I think what's to blame is poor documentation, JavaFX > >>> requiring absurd runtime module VM arguments, and poor/buggy IDE > >>> support. > >>> > >>> > >>> Starting with documentation, JavaFX uses reflection for things like > >>> TableView(everyone's favorite) and CSS style sheets. While this may > >>> be obvious for people who are more experienced, those who are not > >>> may be very confused when they get an onslaught of error messages > >>> regarding reflection. Better documentation on what requires > >>> reflection, why, and how to enable it would be useful. > >>> > >>> > >>> Likewise, the notice about having to include javafx.graphics to the > >>> runtime module arguments here: > >>> > >>> > >>> https://openjfx.io/openjfx-docs/#IDE-NetBeans > >>> > >>> > >>> Apply to Maven as well, but it's under Ant for some reason. I don't > >>> know what was changed in JavaFX 14 that now suddenly requires a > >>> runtime VM argument, but it's a PITA and BS. End users are going to > >>> struggle with this, and it prevents JavaFX runtime from being purely > >>> managed by Maven. No other JavaFX version requires this, so it's > >>> mind boggling that all of a sudden JavaFX needs this. > >>> > >>> > >>> Poor/buggy IDE support is really the big one here. I don't know > >>> about other IDEs but Netbeans DOES NOT provide a project template > >>> for creating a JavaFX application with setup dependencies. Netbeans, > >>> when setup with a Maven project, allows you to select an entire > >>> project(pom) rather than the individual dependencies(jar) which > >>> doesn't work. What you search for also matters: if you search for > >>> "JavaFX" you will get the wrong search results. You need to search > >>> for "openjfx" which can be confusing. > >>> > >>> > >>> Anyway, yeah, it's a PITA. There is also an issue with Ant based > >>> projects and Netbeans because JavaFX puts its src.zip in a folder > >>> that is supposed to only include the runtime library that has > >>> existed for years(literally a 1 line fix too). No one really uses > >>> Ant anymore so it's probably not a big deal now but yeah, getting > >>> JavaFX working hasn't been "include and done" when it could > >>> potentially be that way. > >>> > >> > > >
