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 <ebre...@gmail.com> 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 <m...@plan99.net> 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 <bruno.bor...@gmail.com> > > 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 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. > > > > > > > -- Steve Hannah Web Lite Solutions Corp.
