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