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