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