Re: Remove JavaFX JPMS enforcement

To: openjfx-dev@openjdk.java.net Subject: Re: Remove JavaFX JPMS enforcement On 4/20/20 11:36 AM, Ty Young wrote: > > On 4/20/20 10:47 AM, Mark Raynsford wrote: >> Am I missing something here? What absurd arguments are required for >> Maven projects? >> >> I have mult

Re: Re: Remove JavaFX JPMS enforcement

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

Re: Re: Remove JavaFX JPMS enforcement

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)

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

Hi Michael, thank you very much for sharing this link, which is very interesting! Reading the limitation section is interesting and also reveals current assumptions of the GraalVM developers that may not meet reality in full, hence making it a little bit cumbersome/difficult to fully support

Re: Remove JavaFX JPMS enforcement

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

Re: Remove JavaFX JPMS enforcement

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 wrote: > As of JDK 9, there are a few places

Re: Remove JavaFX JPMS enforcement

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

Re: Remove JavaFX JPMS enforcement

JFXtras is split in many modules as well, the question is if it really is that important to do. Splitting up in jars -so you don't need to include what is not needed- is good, but whether they need to be modules... The way I see it is that JPMS requires the same amount of effort as OSGi for

Re: Remove JavaFX JPMS enforcement

On 4/20/20, 11:18 AM, Bruno Borges wrote: I do wonder why isn't JavaFX in a single module, like Swing? For Java developers to build Swing apps, all they need is a "requires java.desktop". Well it isn't because we wanted

Re: Remove JavaFX JPMS enforcement

Hi Bruno I actually like the fact that JavaFX has been split up into some smaller parts. E.g., javafx.web is the biggest moster in this context and if you do not really need it, it is nice that you leave it out. Also media, swing and fxml are not always needed and so you can leave them out. I

Re: Remove JavaFX JPMS enforcement

I do wonder why isn't JavaFX in a single module, like Swing? 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

Re: Remove JavaFX JPMS enforcement

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

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

The Android/iOS work is based on GraalVMs Native Image which has some limitations. These can be found here: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md I stumbled over the problem with Method Handles when I tried to integrate some third-party software into it. (E.g.

Re: Remove JavaFX JPMS enforcement

Am I missing something here? What absurd arguments are required for Maven projects? I have multiple applications here running in full module-path mode (the applications are modularized, and JavaFX is on the module path), using plain Maven builds with no special arguments, and IDEA as the IDE.

Re: Remove JavaFX JPMS enforcement

On 4/20/20 11:36 AM, Ty Young wrote: On 4/20/20 10:47 AM, Mark Raynsford wrote: Am I missing something here? What absurd arguments are required for Maven projects? I have multiple applications here running in full module-path mode (the applications are modularized, and JavaFX is on the

Re: Remove JavaFX JPMS enforcement

On 4/20/20 10:47 AM, Mark Raynsford wrote: Am I missing something here? What absurd arguments are required for Maven projects? I have multiple applications here running in full module-path mode (the applications are modularized, and JavaFX is on the module path), using plain Maven builds with

Re: Remove JavaFX JPMS enforcement

With a not very intuitive hack you can circumvent this problem already now. Just add a line like this to the file which contains your main class extending Application (MyApp). class MyAppLauncher {public static void main(String[] args) {MyApp.main(args);}} I do exactly the same, I construct

Re: Remove JavaFX JPMS enforcement

On 4/18/20 7:40 AM, Michael Paus wrote: Hi, I would just like to add that many of the problems you have cited would just vanish if the JPMS enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd runtime module VM arguments" anymore and the IDE integration would

Re: Remove JavaFX JPMS enforcement

Possibly - I posted this because, being ultimately still a product of the Java group at Oracle, I'm sceptical JavaFX will become *less* dependent on the module system when the trend has been to use it more. So there are at least two usability problems: 1 - needing additional downloads and new

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

Hi Johan, On 20.04.2020 15:54, Johan Vos wrote: > The JavaFX implementation used in Android and iOS is using 100% the same code > as the one on desktop. > JavaFX internally uses reflection, and that is supported indeed (can be used > in app-specific code > as well). > The best place to get

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

Hi, The JavaFX implementation used in Android and iOS is using 100% the same code as the one on desktop. JavaFX internally uses reflection, and that is supported indeed (can be used in app-specific code as well). The best place to get started is at https://github.com/gluonhq/client-samples -

Re: Remove JavaFX JPMS enforcement

This is deviating quite a bit from the original issue of this thread, isn't it? As a side note: MethodHandles are not supported by GraalVM native image and so this would probably collide with the attempts to get JavaFX running on Android/iOS. Am 20.04.20 um 11:28 schrieb Mike Hearn: With

Re: Remove JavaFX JPMS enforcement

With respect to reflection, it seems like the module system really wants you to use Lookup capabilities rather than "open" modules to reflection. That is, JFX could be changed to use var objects = FXMLLoader.load(MethodHandles.lookup(), new URL("")); The semantics of a Lookup are that it

Re: Remove JavaFX JPMS enforcement

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

RE: Remove JavaFX JPMS enforcement

alf Of Michael Paus Sent: Saturday, April 18, 2020 6:01 AM To: OpenJFX Subject: Remove JavaFX JPMS enforcement 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

Re: Remove JavaFX JPMS enforcement

I'm in the process of porting an app from Java 8 to Java 11. Just getting it to run in classpath mode is not that hard anymore; upgrade a bunch of libraries and you're set. As an experiment I'm now activating JPMS. Right! What a lot of work! Do you have any idea how many fairly common

Re: Remove JavaFX JPMS enforcement

I have built both non-modular and modular JavaFX apps in the past five years, and I agree that bootstrapping a modular Hello World JavaFX application is not as trivial as bootstrapping a non-modular one. The big challenges are related to the JPMS. These challenges are not unique to JavaFX.

Re: Remove JavaFX JPMS enforcement

Hi, I would just like to add that many of the problems you have cited would just vanish if the JPMS enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd runtime module VM arguments" anymore and the IDE integration would just be straight forward. JavaFX would

Re: Remove JavaFX JPMS enforcement

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

Remove JavaFX JPMS enforcement

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