Re: Remove JavaFX JPMS enforcement

[Bruno Borges]

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

Re: Remove JavaFX JPMS enforcement

[Kevin Rushforth]

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 

Re: JavaFX controls have large size on Raspberry Pi

[Philip Race]

> I would start by looking at what Font.getDefault().getSize() returns 
since everything should be based off that.


I think the code below is the code that decides what the code above 
should return


> Another thing to check is that the reported DPI of the screen is 
correct.


The way I read the code below is that it wants the default font to be 
1/6 of an inch high on the screen.
I think any smaller than 6 lines per inch and it will be hard to read. 
To do this correctly, it relies on

the y-res being accurate for the device.

So I would follow the path Kevin suggests. For example if something is 
wrongly returning the *dimension* of
the screen when it should be the *dpi* of the screen then you'd have 6 
lines of text filling up the screen.


-phil.

On 4/20/20, 1:56 PM, Kevin Rushforth wrote:

Another thing to check is that the reported DPI of the screen is correct.

-- Kevin


On 4/20/2020 1:25 PM, David Grieve wrote:
The sizes of controls are controlled by CSS styles. Things like 
borders, backgrounds, padding, insets, all of
that defaults to the styles in a stylesheet. Most sizes are 'em' 
units, meaning they are relative to the size
of the font. JavaFX CSS will use the Font.getDefault() font size if 
there is no font explicitly set in either the

styles or in the application code.

I would start by looking at what Font.getDefault().getSize() returns 
since everything should be based off that.

It could also be an issue with the default stylesheets themselves.

-Original Message-
From: openjfx-dev  On Behalf Of 
Alexander Scherbatiy

Sent: Monday, April 20, 2020 2:16 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi

Hello,

I run a simple JavaFX application which shows a button with jdk 
14.0.1 on Raspberry Pi and the drawn button has large size.


This is because of the algorithm which is used by
PrismFontFactory.getSystemFontSize() method [1] to select a system 
font size.

If a system is embedded then the font size is calculated as

  int screenDPI = Screen.getMainScreen().getResolutionY();
  systemFontSize = ((float) screenDPI) / 6f; // 12 points

and the system is detected as embedded because the armv6hf 
architecture is defined as embedded in the armv6hf.gradle file [2].


Raspberri Pi can work both with small touch displays and with big 
monitors. It looks like Raspberry Pi should support two modes for 
font size calculation: one for small screens and another for large.


I would like to contribute a fix for this but I do not know how the 
right fix could look like.
Should there be a special screen size so for smaller screens the font 
is is proportional to the screen size and for bigger screens the font 
size is fixed?

Is there a way to check that used screen is from embedded device?
May be it should be solved in different way?

[1]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3Dreserved=0 


[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3Dreserved=0 



JavaFX application:

import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ButtonFX extends Application {
  public static void main(String[] args) {
  launch(args);
  }

  @Override
  public void start(Stage primaryStage) {
  primaryStage.setTitle("Hello World!");
  Button button = new Button("Hello, World!");

  StackPane root = new StackPane();
  root.getChildren().add(button);
  primaryStage.setScene(new Scene(root, 300, 250));
  primaryStage.show();
  }
}


Thanks,
Alexander.

Re: JavaFX controls have large size on Raspberry Pi

[Kevin Rushforth]

Another thing to check is that the reported DPI of the screen is correct.

-- Kevin


On 4/20/2020 1:25 PM, David Grieve wrote:

The sizes of controls are controlled by CSS styles. Things like borders, 
backgrounds, padding, insets, all of
that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning 
they are relative to the size
of the font. JavaFX CSS will use the Font.getDefault() font size if there is no 
font explicitly set in either the
styles or in the application code.

I would start by looking at what Font.getDefault().getSize() returns since 
everything should be based off that.
It could also be an issue with the default stylesheets themselves.

-Original Message-
From: openjfx-dev  On Behalf Of Alexander 
Scherbatiy
Sent: Monday, April 20, 2020 2:16 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi

Hello,

I run a simple JavaFX application which shows a button with jdk 14.0.1 on 
Raspberry Pi and the drawn button has large size.

This is because of the algorithm which is used by
PrismFontFactory.getSystemFontSize() method [1] to select a system font size.
If a system is embedded then the font size is calculated as

      int screenDPI = Screen.getMainScreen().getResolutionY();
      systemFontSize = ((float) screenDPI) / 6f; // 12 points

and the system is detected as embedded because the armv6hf architecture is 
defined as embedded in the armv6hf.gradle file [2].

Raspberri Pi can work both with small touch displays and with big monitors. It 
looks like Raspberry Pi should support two modes for font size calculation: one 
for small screens and another for large.

I would like to contribute a fix for this but I do not know how the right fix 
could look like.
Should there be a special screen size so for smaller screens the font is is 
proportional to the screen size and for bigger screens the font size is fixed?
Is there a way to check that used screen is from embedded device?
May be it should be solved in different way?

[1]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3Dreserved=0
[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3Dreserved=0

JavaFX application:

import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ButtonFX extends Application {
      public static void main(String[] args) {
      launch(args);
      }

      @Override
      public void start(Stage primaryStage) {
      primaryStage.setTitle("Hello World!");
      Button button = new Button("Hello, World!");

      StackPane root = new StackPane();
      root.getChildren().add(button);
      primaryStage.setScene(new Scene(root, 300, 250));
      primaryStage.show();
      }
}


Thanks,
Alexander.

Re: Remove JavaFX JPMS enforcement

[Tom Eugelink]

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 
example, but does not provide the same functionality (most importantly class 
load separation) and thus is simply less worthwhile. So either 'we' start 
adding that last piece (I recently learned there is such a thing as JPMS 
layers, which provides for that), or it probably will stay a Java core thing 
only.

Regards, Tom



On 20-4-2020 20:18, 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".

But for JavaFX, there are multiple modules.

---
*Bruno Borges*
brunoborges.io


On Mon, Apr 20, 2020 at 10:36 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 

RE: JavaFX controls have large size on Raspberry Pi

[David Grieve]

The sizes of controls are controlled by CSS styles. Things like borders, 
backgrounds, padding, insets, all of
that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning 
they are relative to the size 
of the font. JavaFX CSS will use the Font.getDefault() font size if there is no 
font explicitly set in either the 
styles or in the application code. 

I would start by looking at what Font.getDefault().getSize() returns since 
everything should be based off that. 
It could also be an issue with the default stylesheets themselves. 

-Original Message-
From: openjfx-dev  On Behalf Of Alexander 
Scherbatiy
Sent: Monday, April 20, 2020 2:16 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi

Hello,

I run a simple JavaFX application which shows a button with jdk 14.0.1 on 
Raspberry Pi and the drawn button has large size.

This is because of the algorithm which is used by
PrismFontFactory.getSystemFontSize() method [1] to select a system font size.
If a system is embedded then the font size is calculated as

     int screenDPI = Screen.getMainScreen().getResolutionY();
     systemFontSize = ((float) screenDPI) / 6f; // 12 points

and the system is detected as embedded because the armv6hf architecture is 
defined as embedded in the armv6hf.gradle file [2].

Raspberri Pi can work both with small touch displays and with big monitors. It 
looks like Raspberry Pi should support two modes for font size calculation: one 
for small screens and another for large.

I would like to contribute a fix for this but I do not know how the right fix 
could look like.
Should there be a special screen size so for smaller screens the font is is 
proportional to the screen size and for bigger screens the font size is fixed?
Is there a way to check that used screen is from embedded device?
May be it should be solved in different way?

[1]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3Dreserved=0
[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3Dreserved=0

JavaFX application:

import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ButtonFX extends Application {
     public static void main(String[] args) {
     launch(args);
     }

     @Override
     public void start(Stage primaryStage) {
     primaryStage.setTitle("Hello World!");
     Button button = new Button("Hello, World!");

     StackPane root = new StackPane();
     root.getChildren().add(button);
     primaryStage.setScene(new Scene(root, 300, 250));
     primaryStage.show();
     }
}


Thanks,
Alexander.

RE: Is it possible to customise the theme of the Scene Builder itself?

[David Grieve]

This is probably not the right forum for this question. Try a forum like 
stackoverflow. Or reach out to great people at Gluon.

The short answer, however, is that you can play with the CSS styles that make 
up the theme. You'd either need to update the stylesheets in the jar or build 
scene builder yourself. 

-Original Message-
From: openjfx-dev  On Behalf Of Mailing 
User
Sent: Monday, April 20, 2020 3:29 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Is it possible to customise the theme of the Scene Builder 
itself?

I have downloaded the latest version from a website called Gluon or something. 
The problem is that the default theme lacks contrast. It looks like grey text 
on light grey background. Also the font is too small for me. In File -> 
Preferences, I can see "Scene Builder Theme", but it only has two themes: 
Default and Dark. The Dark theme also lacks contrast. It looks like grey text 
on dark grey background.

Is there any way to change the colours or the font size of Scene Builder 
itself, NOT the scene of my application that I am editing with Scene Builder?

Is it possible to customise the theme of the Scene Builder itself?

[Mailing User]

I have downloaded the latest version from a website called Gluon or something. 
The problem is that the default theme lacks contrast. It looks like grey text 
on light grey background. Also the font is too small for me. In File -> 
Preferences, I can see "Scene Builder Theme", but it only has two themes: 
Default and Dark. The Dark theme also lacks contrast. It looks like grey text 
on dark grey background.

Is there any way to change the colours or the font size of Scene Builder 
itself, NOT the scene of my application that I am editing with Scene Builder?

Re: Remove JavaFX JPMS enforcement

[Philip Race]

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 to do that for Swing. It is because it 
was too hard to decompose it
because of interdependencies between AWT and Swing and 2D. For example 
AWT + 2D APIs are

in the same java.awt package.

And Swing is the 99% use case so it would have amounted to using all of 
the same anyway.


But even if it could have been done likely we would still have had an 
aggregator module to make it easy.


Note that java.datatransfer is required by java.desktop.

-phil.

But for JavaFX, there are multiple modules.

---
*Bruno Borges*
brunoborges.io


On Mon, Apr 20, 2020 at 10:36 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 

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

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 even have cases where I only
allow javafx.base because that is all you need to write your view-models and
it is good that you can explicitly separate that from all the graphics 
and control

stuff. So I have absolutely no problem with that kind of modularization.
Michael

Am 20.04.20 um 20:18 schrieb Bruno Borges:

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 


On Mon, Apr 20, 2020 at 10:36 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 

Re: Remove JavaFX JPMS enforcement

[Bruno Borges]

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


On Mon, Apr 20, 2020 at 10:36 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 

JavaFX controls have large size on Raspberry Pi

[Alexander Scherbatiy]

Hello,

I run a simple JavaFX application which shows a button with jdk 14.0.1 
on Raspberry Pi and the drawn button has large size.


This is because of the algorithm which is used by 
PrismFontFactory.getSystemFontSize() method [1] to select a system font 
size.

If a system is embedded then the font size is calculated as

    int screenDPI = Screen.getMainScreen().getResolutionY();
    systemFontSize = ((float) screenDPI) / 6f; // 12 points

and the system is detected as embedded because the armv6hf architecture 
is defined as embedded in the armv6hf.gradle file [2].


Raspberri Pi can work both with small touch displays and with big 
monitors. It looks like Raspberry Pi should support two modes for font 
size calculation: one for small screens and another for large.


I would like to contribute a fix for this but I do not know how the 
right fix could look like.
Should there be a special screen size so for smaller screens the font is 
is proportional to the screen size and for bigger screens the font size 
is fixed?

Is there a way to check that used screen is from embedded device?
May be it should be solved in different way?

[1] 
https://github.com/openjdk/jfx/blob/ec8608f39576035d41e8e532e9334b979b859543/modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java#L1944
[2] 
https://github.com/openjdk/jfx/blob/ec8608f39576035d41e8e532e9334b979b859543/buildSrc/armv6hf.gradle#L182


JavaFX application:

import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ButtonFX extends Application {
    public static void main(String[] args) {
    launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
    primaryStage.setTitle("Hello World!");
    Button button = new Button("Hello, World!");

    StackPane root = new StackPane();
    root.getChildren().add(button);
    primaryStage.setScene(new Scene(root, 300, 250));
    primaryStage.show();
    }
}


Thanks,
Alexander.

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

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.

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

[Michael Paus]

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. Log4J and NSMenuFX)(I had to abandon Log4J and 
fixed the problems in NSMenuFX.)


Am 20.04.20 um 15:26 schrieb Rony G. Flatscher:

On 20.04.2020 15:06, Michael Paus wrote:

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.

Would you have some link where there would be a technical overview about how 
Java and JavaFX support
gets currently realized under Android/iOS? Also, how is reflection supposed to 
be carried out on
that platform, ie. is java.lang.reflect available?

---rony

Re: Windows Installation Instructions, All DLL Files Missing

[Christopher Miles]

I really appreciate all of the helpful comments in this thread! I have 
made a lot of progress on this issue, I can compile and run my 
application and am working on packaging.


In my opinion, my big problem was that when I was compiling I wasn't 
setting the correct flags with `javac` and, at the same time, probably 
didn't have the correct flags for `java` either. To be honest I was 
mostly button mashing at that point in the hopes that I'd stumble across 
the correct combination.


To get everything working I have moved to using the "mods" with `javac` 
and to compile and then using `jlink` build an image. After `jlink` runs 
I am using the `java` that is in the image directory to run the compiled 
"JAR" file and that is working well.


I think one big hurdle here was my lack of familiarity with Java modules 
and how they work. While I knew that Java modules had been a thing for a 
while I've been working on non-Java projects and it was not at the front 
of my mind.


While the examples on the JavaFX "Getting Started" page worked for me, I 
don't think I came away with a clear understanding of what the flags 
where actually doing and that made it a little harder to migrate that 
information over to my own project. My thinking is that using the "mods" 
will make it easier to eventually get my application packaged but I'm 
not entirely clear on the bit about the JavaFX runtime and if I need it 
at all. I don't think a discussion of the Java modules system would be 
appropriate on the "Getting Started" page, but maybe getting a little 
more into the details of which approach makes the most sense (mods vs. 
the SDK) in which situations would clarify some things.


Thank you all for your help on this! :-)

--
Miles

Kevin Rushforth wrote on 4/20/2020 11:19:
That shouldn't be necessary. It's a better workaround than setting the 
PATH env variable to be sure, but there is some underlying problem that 
isn't yet understood.


-- Kevin

On 4/20/2020 8:13 AM, David Grieve wrote:

Set  -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin

For the jlink question, look at jmod. You'll use jmod to bundle up the 
dll's and whatever else you need, then jlink to create the custom 
runtime.


-Original Message-
From: openjfx-dev  On Behalf Of 
Christopher Miles

Sent: Friday, April 17, 2020 2:56 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files 
Missing


I manage a project[0]  that leverages JavaFX. It's been a while since 
I've worked on this project, almost two years. At that time JavaFX was 
bundled with the Java runtime from Oracle. The few customers I had 
would simply run the application from the bundled launcher and as long 
as they had Java installed, it would work.


It's time for me to add some features to the project, I am now using 
OpenJDK 14.0.1 and I installed the OpenJavaFX package and followed the 
instructions[1] from the following URL:


https://openjfx.io/openjfx-docs/#install-javafx

I am on Windows and followed the instructions for that platform.
Unfortunately, things didn't really work. The error was as follows:

Graphics Device initialization failed for : d3d, sw Error initializing
QuantumRenderer: no suitable pipeline found java.lang.RuntimeException:
java.lang.RuntimeException: Error initializing QuantumRend erer: no 
suitable pipeline found at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno 


wn Source)

I fussed with this and that but nothing made a difference. Eventually 
I tried adding the "bin" directory from the JavaFX distribution to my 
path. This is the entry I added to my global PATH variable:


C:\Program Files\Java\javafx-sdk-14\bin

Is this the right way to do this and, if so, why isn't this included 
in the directions? Is this a Windows specific issue?


Also, what impact does this have on distribution of applications?

Looking at the "Runtime Images" instructions, it looks like the same 
issues will be present. Those instructions use `jlink` to point to the 
JavaFX libraries and the JAVAFX modules (distributed in another 
package) but also leave off references to the DLL files in the "bin" 
directory. I am worried that I will need to have people manually 
install the OpenJavaFX distribution and add the "bin" directory to 
their path in order to run my application. Please say it's not so!


Any help or pointers to additional documentation would be very much 
appreciated! I have made it over the bumps and can now continue 
development of my application, my next concern is distributing it to 
customers.


--
Miles

[0]: https://github.com/cmiles74/xmltool
[1]: https://openjfx.io/openjfx-docs/#install-javafx

Re: Remove JavaFX JPMS enforcement

[Mark Raynsford]

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.
This is on JDK 13, with the 13.0.2 JavaFX release from Central.

-- 
Mark Raynsford | https://www.io7m.com

Re: Remove JavaFX JPMS enforcement

[Ty Young]

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 module path), using
plain Maven builds with no special arguments, and IDEA as the IDE.
This is on JDK 13, with the 13.0.2 JavaFX release from Central.



From the second warning on this page:


https://openjfx.io/openjfx-docs/


That's the absurd part. JavaFX 14 now requires this as a JVM runtime 
argument:



--module-path /path/to/javafx-sdk-12/lib --add-modules 
javafx.controls,javafx.fxml



Which wasn't required before. Not only is this a PITA and confusing 
but it also prevents Maven from just handling everything. Netbeans 
uses a custom file for runtime arguments, which the above is added to.




Also, it gives JavaFX 12 as an example, which is wrong. It should be 14.

Re: Remove JavaFX JPMS enforcement

[Ty Young]

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 no special arguments, and IDEA as the IDE.
This is on JDK 13, with the 13.0.2 JavaFX release from Central.



From the second warning on this page:


https://openjfx.io/openjfx-docs/


That's the absurd part. JavaFX 14 now requires this as a JVM runtime 
argument:



--module-path /path/to/javafx-sdk-12/lib --add-modules 
javafx.controls,javafx.fxml



Which wasn't required before. Not only is this a PITA and confusing but 
it also prevents Maven from just handling everything. Netbeans uses a 
custom file for runtime arguments, which the above is added to.

Porting OpenJFX to BSD

[Yousef Alhashemi]

Hello,

  How difficult would it be to port/compile the latest version of
openjfx (14?) on BSD? On FreeBSD, only version 8 is available as a
port/package and it's deprecated and will be removed later this year.

I haven't done any large scale porting of code, but I do understand
the basic concepts (using typedefs, not using compiler-specific
optimizations so say gcc code can also be compiled on clang, etc).

If porting to BSD is well-documented somewhere and is fairly
systematic, I'd be happy to give it a shot.

Any pointers are appreciated.

Thanks,
Yousef

Re: Remove JavaFX JPMS enforcement

[John Hendrikx]

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 a fat jar with all of JavaFX included 
and run it as above.


I was looking forward to the module system allowing a clean and easy way 
to have a visibility scope inbetween public and package (by making 
packages hierarchical for example), but it turned into a monster that 
just seems to make projects fragile and hard to build/run.


I suppose it may be possible to just generate and publish JavaFX jars 
without all the module-info files included, but I'm not sure it is as 
simple as that.


--John

Re: RFR: 8227425: Add support for e-paper displays on i.MX6 devices

[John Neffenger]

On Fri, 17 Apr 2020 15:14:19 GMT, Kevin Rushforth  wrote:

> I just checked and there is nothing wrong with your merge. But somehow it 
> managed to confuse GitHub.

Thanks, Kevin. A simple `git rebase master` and `git push --force` did the 
trick!

I hope it's okay for me to add some advocacy to the conversation here. My 
initial comment makes it easy to miss the
general context of this update.

This pull request completes the project of adding support for e-paper displays 
that we started back in JavaFX 13. I
would love to see these last few changes merged in time for JavaFX 15.

Below are five reasons to merge this pull request into the next release:

1. It's small. It's only 50 lines of code — the last 3 percent of the entire 
project.

2. It's done. It completes the work already included in JavaFX 13, which was 
1,812 lines of code and 97 percent of the
project.

3. It's safe. The code runs only when the system properties include 
`glass.platform=Monocle` and
`monocle.platform=EPD`, and even then, only when the system has an e-paper 
display with the EPD Controller frame buffer
driver. There are no changes to any JavaFX code outside of the Monocle EPD 
platform.

4. It's tested. I tested the code in November with JDK 13 and JavaFX 14. I 
tested the code again this week with JDK 14
and JavaFX 15. I ran tests with Ubuntu OpenJDK 11 and 13 as well as 
AdoptOpenJDK 11 and 14. I tested older devices
under Ubuntu 14.04 and newer devices under Ubuntu 20.04 Beta. All tests passed.

5. It's unique. This pull request makes JavaFX the only cross-platform 
application framework with built-in support for
e-paper displays. It demonstrates that the Java slogan "write once, run 
anywhere" is as true today as it was in 1995,
not just for different operating systems and processor architectures, but even 
for radically different display
technologies like electronic ink.

To my potential reviewers, @johanvos and @kevinrushforth, is there anything I 
can do to make your code review easier?

-

PR: https://git.openjdk.java.net/jfx/pull/60

Re: Remove JavaFX JPMS enforcement

[Ty Young]

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 
just be straight forward.
JavaFX would become just one more dependency whithout the need for any 
special treatment.



The custom Maven runtime arguments shouldn't exist, period. They didn't 
exist before 14 and there was zero discussion here as to why they are 
suddenly required on this mailing list. It just kinda came out of no where.



Also, correction, the wiki is wrong: that JVM argument is ONLY for Maven 
projects, not Ant.



I still stand that the fault isn't JPMS but rather people not willing to 
add documentation or support for it. When JavaFX fails to reflect on a 
class file or a CSS file it could suggest that it needs to be "open"ed.





I did, however, not say that JavaFX should be de-modularized. For an 
expert user who wants

to use the JPMS nothing would change at all.



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.

Re: Windows Installation Instructions, All DLL Files Missing

[Kevin Rushforth]

That shouldn't be necessary. It's a better workaround than setting the 
PATH env variable to be sure, but there is some underlying problem that 
isn't yet understood.


-- Kevin

On 4/20/2020 8:13 AM, David Grieve wrote:

Set  -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin

For the jlink question, look at jmod. You'll use jmod to bundle up the dll's 
and whatever else you need, then jlink to create the custom runtime.

-Original Message-
From: openjfx-dev  On Behalf Of 
Christopher Miles
Sent: Friday, April 17, 2020 2:56 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files Missing

I manage a project[0]  that leverages JavaFX. It's been a while since I've 
worked on this project, almost two years. At that time JavaFX was bundled with 
the Java runtime from Oracle. The few customers I had would simply run the 
application from the bundled launcher and as long as they had Java installed, 
it would work.

It's time for me to add some features to the project, I am now using OpenJDK 
14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] 
from the following URL:

https://openjfx.io/openjfx-docs/#install-javafx

I am on Windows and followed the instructions for that platform.
Unfortunately, things didn't really work. The error was as follows:

Graphics Device initialization failed for : d3d, sw Error initializing
QuantumRenderer: no suitable pipeline found java.lang.RuntimeException:
java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable 
pipeline found at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno
wn Source)

I fussed with this and that but nothing made a difference. Eventually I tried adding the 
"bin" directory from the JavaFX distribution to my path. This is the entry I 
added to my global PATH variable:

C:\Program Files\Java\javafx-sdk-14\bin

Is this the right way to do this and, if so, why isn't this included in the 
directions? Is this a Windows specific issue?

Also, what impact does this have on distribution of applications?

Looking at the "Runtime Images" instructions, it looks like the same issues will be present. Those 
instructions use `jlink` to point to the JavaFX libraries and the JAVAFX modules (distributed in another 
package) but also leave off references to the DLL files in the "bin" directory. I am worried that I 
will need to have people manually install the OpenJavaFX distribution and add the "bin" directory 
to their path in order to run my application. Please say it's not so!

Any help or pointers to additional documentation would be very much 
appreciated! I have made it over the bumps and can now continue development of 
my application, my next concern is distributing it to customers.

--
Miles

[0]: https://github.com/cmiles74/xmltool
[1]: https://openjfx.io/openjfx-docs/#install-javafx

RE: Windows Installation Instructions, All DLL Files Missing

[David Grieve]

Set  -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin

For the jlink question, look at jmod. You'll use jmod to bundle up the dll's 
and whatever else you need, then jlink to create the custom runtime.

-Original Message-
From: openjfx-dev  On Behalf Of 
Christopher Miles
Sent: Friday, April 17, 2020 2:56 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files Missing

I manage a project[0]  that leverages JavaFX. It's been a while since I've 
worked on this project, almost two years. At that time JavaFX was bundled with 
the Java runtime from Oracle. The few customers I had would simply run the 
application from the bundled launcher and as long as they had Java installed, 
it would work.

It's time for me to add some features to the project, I am now using OpenJDK 
14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] 
from the following URL:

https://openjfx.io/openjfx-docs/#install-javafx

I am on Windows and followed the instructions for that platform. 
Unfortunately, things didn't really work. The error was as follows:

Graphics Device initialization failed for : d3d, sw Error initializing
QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: 
java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable 
pipeline found at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno
wn Source)

I fussed with this and that but nothing made a difference. Eventually I tried 
adding the "bin" directory from the JavaFX distribution to my path. This is the 
entry I added to my global PATH variable:

C:\Program Files\Java\javafx-sdk-14\bin

Is this the right way to do this and, if so, why isn't this included in the 
directions? Is this a Windows specific issue?

Also, what impact does this have on distribution of applications?

Looking at the "Runtime Images" instructions, it looks like the same issues 
will be present. Those instructions use `jlink` to point to the JavaFX 
libraries and the JAVAFX modules (distributed in another package) but also 
leave off references to the DLL files in the "bin" directory. I am worried that 
I will need to have people manually install the OpenJavaFX distribution and add 
the "bin" directory to their path in order to run my application. Please say 
it's not so!

Any help or pointers to additional documentation would be very much 
appreciated! I have made it over the bumps and can now continue development of 
my application, my next concern is distributing it to customers.

--
Miles

[0]: https://github.com/cmiles74/xmltool
[1]: https://openjfx.io/openjfx-docs/#install-javafx

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

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 JVM flags to use JavaFX as modules
rather than ordinary JARs

2 - needing to open packages to JavaFX so it can reflect over them (not a
problem if your app runs on the classpath, but can hit you the moment you
use a component that's been modularised)

The first one has a few workarounds/solutions but what I do is go with the
flow and prepare my own JDK using jlink, which has JavaFX baked in like it
did before. I use a variant on this script:

https://gist.github.com/mikehearn/b18842d45181ac150ec9e6d0b2bb1e24

The output is a JDK directory I can point my IDE at. It's seen as a normal
JDK, but like in Java 8 JavaFX is now fully baked in and available by
default. Because it's already on the module path no special JVM flags are
required.

Probably someone (me?) should upload JDKs for each platform that are "fully
baked" like this.

That leaves the second problem, for which there's no good solution with the
current JFX API. Dependency injectors fundamentally don't mix well with
JPMS. Using Lookup objects is a backwards compatible addition that would
remove part of the pain of using modules with JavaFX because you'd no
longer need to remember to add special incantations to a module-info.java to
enable reflection - incantations which might change between JFX versions as
reflection uses are added or changed.





On Mon, Apr 20, 2020 at 15:06:16, Michael Paus  wrote:

> 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 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 grants whoever holds the object the
> same access rights as whoever created it. Thus if an object creates a
> Lookup and gives it to a framework, that framework can access anything the
> object could itself access.
>
> The lookup object would then be used to do reflection rather than the
> classical reflection API. With this change the API would guide you to a
> form that always works, regardless of module configuration.
>
> Due to its nature as a GUI toolkit JFX often needs to reflect over user
> code. It may be worth considering a deeper upgrade in which a Lookup object
> is provided during application startup, and passed in to the framework e.g.
> the Application class. Lookup objects can be 'teleported' so JFX components
> that wish to work with user GUI code generically can then fetch a Lookup
> from a central place. However, this wouldn't allow overriding of access
> control (i.e. FXMLLoader that takes such a lookup and teleports it to the
> right class for access, wouldn't be able to access private fields, because
> the original place where the lookup was created also couldn't).
>
>

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

[Rony G. Flatscher]

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 started is at https://github.com/gluonhq/client-samples

thank you very much for both, the link and assuring that reflection is still 
available to apps as well!

---rony

>
> On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher  > wrote:
>
> On 20.04.2020 15:06, Michael Paus wrote:
> > 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.
> Would you have some link where there would be a technical overview about 
> how Java and JavaFX
> support
> gets currently realized under Android/iOS? Also, how is reflection 
> supposed to be carried out on
> that platform, ie. is java.lang.reflect available?
>
> ---rony
>

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

[Johan Vos]

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

- Johan

On Mon, Apr 20, 2020 at 3:30 PM Rony G. Flatscher 
wrote:

> On 20.04.2020 15:06, Michael Paus wrote:
> > 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.
> Would you have some link where there would be a technical overview about
> how Java and JavaFX support
> gets currently realized under Android/iOS? Also, how is reflection
> supposed to be carried out on
> that platform, ie. is java.lang.reflect available?
>
> ---rony
>
>
>

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

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 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 grants whoever holds the object the
same access rights as whoever created it. Thus if an object creates a
Lookup and gives it to a framework, that framework can access anything the
object could itself access.

The lookup object would then be used to do reflection rather than the
classical reflection API. With this change the API would guide you to a
form that always works, regardless of module configuration.

Due to its nature as a GUI toolkit JFX often needs to reflect over user
code. It may be worth considering a deeper upgrade in which a Lookup object
is provided during application startup, and passed in to the framework e.g.
the Application class. Lookup objects can be 'teleported' so JFX components
that wish to work with user GUI code generically can then fetch a Lookup
from a central place. However, this wouldn't allow overriding of access
control (i.e. FXMLLoader that takes such a lookup and teleports it to the
right class for access, wouldn't be able to access private fields, because
the original place where the lookup was created also couldn't).

A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLLoader: if script engines implement javax.script.Compilabe

[Rony G. Flatscher]

There is a new WIP at :

This WIP adds the ability for a fallback in case compilation of scripts 
fails, in which case a
warning gets issued about this fact and evaluation of the script will be 
done without
compilation. Because of the fallback scripts get compiled with this version 
by default. It
extends PR 187 #187.

To further ease spotting scripts that cause a ScriptException a message in 
the form of
"filename: caused ScriptException" gets added to the exception handling in 
either of the three
locations: an error message, a stack trace or a wrap-up into a 
RuntimeException (having three
different kinds of reporting ScriptExceptions may be questioned, however 
none of these tear down
the FXML GUI).

This WIP comes with proper test units as well. As per Kevin's suggestion a 
warning gets logged
whenever a script cannot be compiled and the fallback gets used.

It is suggested to use this WIP as it includes the compilation by default with 
a safe fallback to
evaluate the uncompiled script, if compilation (unexpectedly) fails.

Again, any feedback, discussion welcome!

---rony

P.S.: In the log history there is a commit message "Make message more 
pregnant.", it should have
read "Make messages more terse." instead|.||
|


On 17.04.2020 19:37, Rony G. Flatscher wrote:
> There is a new WIP at  which adds a 
> compile PI (process
> instruction) for turning on and off script compilation if the script engine 
> implements the
> Compilable interface.
>
> By default compilation is off (no compilation), such that one needs to add a 
> compile PI
> ("") at the top to activate this feature. Supplying "true" 
> (default) or "false" as the PI
> data turns this feature on and off.
>
> The WIP comes with adapted test units that test "compile on" for an entire 
> fxml file, "compile off",
> alternating using "compile on and off", and alternating using "compile off 
> and on". This will test
> all variants of applying the compile PI for all categories of scripts.
>
> Any feedback appreciated!
>
> ---rony
>
> P.S.: FXML files that contain unknown PIs do not cause a runtime error by 
> FXMLLoader, they just get
> ignored. Therefore one could apply the compile PI to FXML files that are used 
> in older JavaFX runtimes.
>
> P.P.S.: In the next days I will also add Kevin's idea in a separate version 
> that will have a
> fallback solution in case a compilation is (unexpectedly) not successful, 
> reverting to
> (interpretative) evaluation/execution of the script. In that version it is 
> planned to have
> compilation on by default as in the case of a compilation failure there will 
> be a safe backup solution.
>
>
> On 14.04.2020 19:52, Kevin Rushforth wrote:
>> Yes, I agree that enough time has gone by. Go ahead with your proposal. I 
>> would wait a bit to
>> create the CSR until the review is far enough along to know which direction 
>> we intend to go.
>>
>> Unless there is a real concern about possible regressions if scripts are 
>> compiled by default, I
>> think "enabled by default" is the way to go. Your argument that such script 
>> engines are broken
>> seems reasonable, since this only applies to script engines that implement 
>> javax.script.Compilable
>> in the first place. We still might want to add way to turn compilation off 
>> for individual scripts.
>> One other thing to consider is that if compilation fails, it might make 
>> sense to log a warning and
>> fall back to the existing interpreted mode.
>>
>> Does anyone else have any concerns with this?
>>
>> -- Kevin
>>
>>
>> On 4/14/2020 9:48 AM, Rony G. Flatscher wrote:
>>> Hi there,
>>>
>>> as there was probably enough time that has passed by I would intend to 
>>> create a CSR in the next days
>>> with the PR as per Kevin's suggestion.
>>>
>>> (For the case that this feature should not be active by default, the CSR 
>>> will suggest to define a
>>> new "compile" PI in the form  (default, if no PI 
>>> data given: true), which
>>> is independent of the existence of a language PI (this way it becomes also 
>>> possible to allow
>>> compilation of external scripts denoted with the script-element, which do 
>>> not need a page language
>>> to be set as the file's extension allows the appropriate script engine to 
>>> be loaded and used for
>>> execution). A compile-PI would allow for turning compilation of scripts on 
>>> by just adding the PI
>>>  or   to FXML files (and  to 
>>> turn off), which seems to
>>> be simple and self-documentary. In general employing such compile PIs 
>>> allows for setting compilation
>>> of scripts on and off throughout an FXML file.)
>>>
>>> ---rony
>>>
>>>
>>> On 04.04.2020 18:03, Rony G. Flatscher wrote:
>>>
 Hi Kevin,

 On 03.04.2020 01:21, Kevin Rushforth wrote:
> I see that you updated the PR and sent it for review.
>
> Before we formally review it in the PR, let's finish the 

Re: Windows Installation Instructions, All DLL Files Missing

[Kevin Rushforth]

Can you try running your app with the following two flags?

java -Djavafx.verbose=true -Dprism.verbose=true

That might help diagnose the problem.

-- Kevin


On 4/18/2020 11:18 AM, Christopher Miles wrote:

Yep, that's where I downloaded it from.

> PS C:\Users\cmiles\source\repos\xmltool> java --version
> openjdk 14.0.1 2020-04-14
> OpenJDK Runtime Environment (build 14.0.1+7)
> OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

When I look at the "bin" directory that came with the JavaFX SDK and 
compare it to the "bin" directory that comes with OpenJDK there are 
things in the JavaFX distribution that aren't present in the OpenJDK 
distribution. These three caught my attention:


  + prism_common.dll
  + prism_d3d.dll
  + prism_sw.dll

I suspect missing these DLL's is what is causing the exception when I 
try to launch my application.


I took a look at "JDK-8207015" and I don't think that is my problem, 
yet. It could be that if the "prism_xxx.dll" files were present, I 
might run into this issue.


I changed my `jlink` command to point at the "mods" as this seems like 
the correct way to do this. Still, the app refuses to launch with the 
same error message.


> Graphics Device initialization failed for :  d3d, sw
> Error initializing QuantumRenderer: no suitable pipeline found
> java.lang.RuntimeException: java.lang.RuntimeException: Error 
initializing QuantumRenderer: no suitable pipeline found


I would very much like to avoid adding switches to a `java` invocation 
in order to run the application. In your example, I would need to have 
customer installed the JavaFX JDK to a specific location in order for 
that to work. I'd also need to have some kind of wrapper to handle 
other operating systems, like Linux or OS X. My goal is to distribute 
one package with custom launching scripts (i.e. one for batch, 
Powershell, and Linux/OS X shell) as I did under Java 8. This makes me 
think that using `jlink` with the mods is the way to go, as long as I 
can figure out why that is not working.


Thank you for your help with this. :-)

Kevin Rushforth wrote on 4/17/2020 17:34:
 From where are you getting your OpenJDK build? 
https://jdk.java.net/14 ? Somewhere else?


-- Kevin


On 4/17/2020 2:16 PM, Christopher Miles wrote:
Yeah, I've tried it with both. The instructions on the JavaFX page 
tell you to add the "lib" directory to the `javac` path and the 
"mods" to the `jlink` path. I figured, since nothing is working, why 
not try them the other way around? In all cases the results are the 
same.


I'm using OpenJDK, wouldn't that project have the same issue 
distributing these DLL files? I would bet they would, since they are 
also an open source project. I can run Swing projects, however, 
without these DLL files.


I can give the Oracle JDK a try. I had been shying away from it 
since OpenJDK is getting to be so popular. If that works, I will let 
the list know.


As an aside, the JavaFX home page recommends using OpenJDK right now:

  https://openjfx.io/openjfx-docs/#install-java

Thank you!

Kevin Rushforth wrote on 4/17/2020 16:51:
Where are you getting JDK 14.0.1 from? Does it include the 
Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There 
are 45 of them (40 of them are of the form api-ms-win-*.dll). The 
JavaFX 14.0.1 sdk includes them, but the jmods do not. See 
JDK-8207015 [1] for why not. If the JDK has them, then there should 
be no problem running a jlinked app.


One possible problem is that your jlink line is wrong. You should 
not point to the SDK at all when running jlink. Use the jmods with 
jlink (don't use the sdk). Use the sdk with javac and java 
--module-path (don't use the jmods at all).


Btw, even if you are running a JDK that for some reason doesn't 
have the Microsoft DLLs, you should still be able to run using the 
SDK (directly, not via jlink, which requires the jmods) as follows:


java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" 
--add-modules 
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web 
MyApplication


If this doesn't work without you putting javafx-sdk-14/bin in your 
PATH then something else is wrong.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8207015

On 4/17/2020 1:18 PM, Christopher Miles wrote:
I have downloaded both the "mods" and the SDK. I put them 
alongside the JDK on my workstation.


  C:\Program Files\Java\jdk-14.0.1
  C:\Program Files\Java\javafx-sdk-14
  C:\Program Files\Java\javafx-jmods-14.0.1

If I remove the path `C:\Program Files\Java\javafx-sdk-14\bin` and 
point`jlink` at the `C:\Program Files\Java\javafx-jmods-14.0.1` 
path...


jlink --module-path "C:\Program 
Files\Java\javafx-sdk-14\lib;C:\Program 
Files\Java\jdk-14.0.1/jmods" --add-modules 
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web,java.sql,java.base 
--output C:\Users\cmiles\source\repos\xmltool\target/jlink 
--strip-debug --no-man-pages 

RFR: 8087555: [ChoiceBox] uncontained value not shown

[Jeanette Winzenburg]

The issue is that ChoiceBoxSkin
a) doesn't update the text of the label if the value is not contained in the 
items
b) doesn't respect converter for label text

Fixed by
- listening to value changes to update the label
- removing ad-hoc updates (not needed), added update on converter change
- passing all label updates through converter

Added test for text updates that failed before the fix and pass after (note: 
there were no tests for the display text,
so for coveragy, contains also tests that passed before as well as after)

-

Commit messages:
 - 8087555: [ChoiceBox] uncontained value not shown

Changes: https://git.openjdk.java.net/jfx/pull/191/files
 Webrev: https://webrevs.openjdk.java.net/jfx/191/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8087555
  Stats: 464 lines in 2 files changed: 451 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/191.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/191/head:pull/191

PR: https://git.openjdk.java.net/jfx/pull/191

Gradle task for running tests without Webkit

[Nir Lisker]

Hi,

For those who didn't build Webkit, running tests is done with `-x
:web:test`. I think it makes sense to just add a test task that does
exactly that, for convenience.

What do you think?

- Nir

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

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 grants whoever holds the object the
same access rights as whoever created it. Thus if an object creates a
Lookup and gives it to a framework, that framework can access anything the
object could itself access.

The lookup object would then be used to do reflection rather than the
classical reflection API. With this change the API would guide you to a
form that always works, regardless of module configuration.

Due to its nature as a GUI toolkit JFX often needs to reflect over user
code. It may be worth considering a deeper upgrade in which a Lookup object
is provided during application startup, and passed in to the framework e.g.
the Application class. Lookup objects can be 'teleported' so JFX components
that wish to work with user GUI code generically can then fetch a Lookup
from a central place. However, this wouldn't allow overriding of access
control (i.e. FXMLLoader that takes such a lookup and teleports it to the
right class for access, wouldn't be able to access private fields, because
the original place where the lookup was created also couldn't).

Re: Windows Installation Instructions, All DLL Files Missing

[Michael Paus]

Yes, that's what I use in my example together with jlink and jpackage.

Am 20.04.20 um 03:55 schrieb Eric Bresie:

Would jdeps help to see what dependencies are needed?

Eric Bresie
ebre...@gmail.com

On April 18, 2020 at 1:44:43 PM CDT, Michael Paus  wrote:
Hi Christopher,
I do not know what your specific problem is but maybe you just have to
shift your goals a little bit.
Continuing like you did in the Java 8 days is not a good idea for
various reasons. The current trend
for distributing desktop software with Java is to build a platform
specific installer. The tools for that
are all there. Just give it a try. Together with Dirk Lemmermann I have
set up a working example
and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac
and Windows (should also work
on Linux but I haven't tested it.)

The nice thing about this approach is that your customer does not have
to have anything installed on his
own machine. He can just install your software like he would install any
other piece of software.
Michael

Am 18.04.20 um 20:18 schrieb Christopher Miles:

Yep, that's where I downloaded it from.


PS C:\Users\cmiles\source\repos\xmltool> java --version
openjdk 14.0.1 2020-04-14
OpenJDK Runtime Environment (build 14.0.1+7)
OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

When I look at the "bin" directory that came with the JavaFX SDK and
compare it to the "bin" directory that comes with OpenJDK there are
things in the JavaFX distribution that aren't present in the OpenJDK
distribution. These three caught my attention:

+ prism_common.dll
+ prism_d3d.dll
+ prism_sw.dll

I suspect missing these DLL's is what is causing the exception when I
try to launch my application.

I took a look at "JDK-8207015" and I don't think that is my problem,
yet. It could be that if the "prism_xxx.dll" files were present, I
might run into this issue.

I changed my `jlink` command to point at the "mods" as this seems like
the correct way to do this. Still, the app refuses to launch with the
same error message.


Graphics Device initialization failed for : d3d, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error

initializing QuantumRenderer: no suitable pipeline found

I would very much like to avoid adding switches to a `java` invocation
in order to run the application. In your example, I would need to have
customer installed the JavaFX JDK to a specific location in order for
that to work. I'd also need to have some kind of wrapper to handle
other operating systems, like Linux or OS X. My goal is to distribute
one package with custom launching scripts (i.e. one for batch,
Powershell, and Linux/OS X shell) as I did under Java 8. This makes me
think that using `jlink` with the mods is the way to go, as long as I
can figure out why that is not working.

Thank you for your help with this. :-)

Kevin Rushforth wrote on 4/17/2020 17:34:

 From where are you getting your OpenJDK build?
https://jdk.java.net/14 ? Somewhere else?

-- Kevin


On 4/17/2020 2:16 PM, Christopher Miles wrote:

Yeah, I've tried it with both. The instructions on the JavaFX page
tell you to add the "lib" directory to the `javac` path and the
"mods" to the `jlink` path. I figured, since nothing is working, why
not try them the other way around? In all cases the results are the
same.

I'm using OpenJDK, wouldn't that project have the same issue
distributing these DLL files? I would bet they would, since they are
also an open source project. I can run Swing projects, however,
without these DLL files.

I can give the Oracle JDK a try. I had been shying away from it
since OpenJDK is getting to be so popular. If that works, I will let
the list know.

As an aside, the JavaFX home page recommends using OpenJDK right now:

https://openjfx.io/openjfx-docs/#install-java

Thank you!

Kevin Rushforth wrote on 4/17/2020 16:51:

Where are you getting JDK 14.0.1 from? Does it include the
Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There
are 45 of them (40 of them are of the form api-ms-win-*.dll). The
JavaFX 14.0.1 sdk includes them, but the jmods do not. See
JDK-8207015 [1] for why not. If the JDK has them, then there should
be no problem running a jlinked app.

One possible problem is that your jlink line is wrong. You should
not point to the SDK at all when running jlink. Use the jmods with
jlink (don't use the sdk). Use the sdk with javac and java
--module-path (don't use the jmods at all).

Btw, even if you are running a JDK that for some reason doesn't
have the Microsoft DLLs, you should still be able to run using the
SDK (directly, not via jlink, which requires the jmods) as follows:

java --module-path "C:\Program Files\Java\javafx-sdk-14\lib"
--add-modules
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web
MyApplication

If this doesn't work without you putting