The openjfx native library cache path should be platform dependent

[Glavo]

I noticed that openjfx packaged in jar caches native libraries in
~/.openjfx/cache/${version}, it is not related to the system and
architecture.

It should be noted that in fact, we can start programs with different
architectures on the same system. A typical example is that Windows x86
software can be run on the Windows amd64 platform.
With the popularization of aarch64 architecture, this situation will become
more common: The software of Windows x86 and Windows amd64 can be run on
the Windows aarch64 platform, and the  software of MacOs x86 can be run on
the MacOS aarch64.

The native library file names of different schemas on the same system are
usually the same, which will cause conflicts.
For example, I tried to launch the same JavaFX application on my Windows
amd64 machine with two jdks that for x86 architecture and amd64
architecture at the same time, and it crashed:

https://paste.ubuntu.com/p/NZBK3pNrh7/

On ARM machines, it is often necessary to run x86 applications through
translators, and such crashes may be more common.

I think openjfx should adjust the cache path of the native library, such as
~/.openjfx/cache/17.0.2/win-aarch64/.
This can avoid crashes and avoid openjfx repeatedly decompressing the
native library to cover the native libraries of other architectures.

I don't have a JBS account. If you need to open an issue for this problem,
please do it for me, thanks.

Re: JavaFX Launch Failure on Ubuntu from JNI

[Kevin Rushforth]

Point #1 is one of the known limitations of using javafx modules on the 
classpath (and is one of the reasons we recommend against it), so that's 
not surprising. And I see you found the workaround.


I wonder if it might have something to do with a shared library that is 
being loaded in one case and not the other, but that's just a vague 
guess. Maybe someone else will spot something.


Since you have something minimal that reproduces the problem for you, 
can you file a bug?


-- Kevin


On 1/19/2022 4:07 PM, Steve Hannah wrote:

I've reduced the problem down to something minimal and have found that:

1. If your main class extends Application, and you try to run it like:
java -jar MyApplication.jar

It will fail immediately with:
Error: JavaFX runtime components are missing, and are required to run this
application

2. If you "trick" it, by making your Application class a separate class
that you call from your main class, it will run fine using:
java -jar MyApplication.jar

3. It will also run fine in this scenario using
-Djava.class.path=MyApplication.jar instead of -jar:
java -Djava.class.path=MyApplication.jar Main

3. If I try to simulate the exact same thing with my own launcher, it will
hang somewhere in the JavaFX initialization:

with javafx.verbose=true, the output is:

System.loadLibrary(prism_es2) succeeded
JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
System.loadLibrary(glass) succeeded

But it hangs there, and never displays the screen.

The C code for this launcher is:

char *mainClass;

JavaVM *vm;
JNIEnv *env;
JavaVMInitArgs vm_args;
JavaVMOption options[2];
mainClass = "Main";
options[0].optionString = "-Djava.class.path=MyApplication.jar";
options[1].optionString = "-Djavafx.verbose=true";
vm_args.version = JNI_VERSION_1_2;
vm_args.options = options;
vm_args.nOptions = 2;
vm_args.ignoreUnrecognized = 0;

jobjectArray args;
jint res = JNI_CreateJavaVM(, (void **), _args);
if (res < 0) {
 printf("Can't create Java VM\n");
 exit(1);
}
jclass cls = (*env)->FindClass(env, mainClass);
if (cls == 0) {

 printf("Main class %s class not found\n", mainClass);
 exit(1);
}
jmethodID mid =
(*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V");
if (mid == 0) {
 printf("main() method not found\n");
 exit(1);
}
//jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list
args =
  (*env)->NewObjectArray(env, 0, (*env)->FindClass(env,
"java/lang/String"), NULL);
if (args == 0) {
 printf("Out of memory\n");
 exit(1);
}

(*env)->CallStaticVoidMethod(env, cls, mid, args);



Can anyone spot any differences between that and running with the "java"
binary:?
java -Djava.class.path=MyApplication.jar Main

I have experimented both with JDKs that include JavaFX (e.g. Zulu) and ones
that do not (e.g. AdoptOpenJDK).  Both exhibit the same behaviour (except
with AdoptOpenJDK, I also add the javafx jars to the classpath).

For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent with
my earlier troubles on Ubuntu (also JDK11).


Best regards

Steve


On Wed, Jan 19, 2022 at 3:06 PM John Neffenger  wrote:


On 1/19/22 2:12 PM, Steve Hannah wrote:

I have been resisting using modules for a long time because it just makes
things more complicated, ...

It also makes some things easier, though, and certainly smaller. It's
easier to use an old-school Makefile with modules, and using 'jlink' can
get a simple Hello World JavaFX application and Java runtime down to
just 31 megabytes.

Here's my minimal, no-magic example:

https://github.com/jgneff/hello-javafx

with a simple Makefile:

https://github.com/jgneff/hello-javafx/blob/main/Makefile

and a Maven POM for use online with Maven Central or offline with a
local Debian- or Ubuntu-built Maven repository:

https://github.com/jgneff/hello-javafx/blob/main/pom.xml

John

Re: JavaFX Launch Failure on Ubuntu from JNI

[Nir Lisker]

>
> 1. If your main class extends Application, and you try to run it like:
> java -jar MyApplication.jar


> It will fail immediately with:
> Error: JavaFX runtime components are missing, and are required to run this
> application


> 2. If you "trick" it, by making your Application class a separate class
> that you call from your main class, it will run fine using:
> java -jar MyApplication.jar


This is documented behavior, although I admit it was hard to find it.
If you go to the getting started documentation at
https://openjfx.io/openjfx-docs/ and the go to Runtime images > Non-Modular
project it will tell you that:

"As explained here, in order to create a runnable jar with all the required
JavaFX dependencies, you will need to use a launcher class that doesn't
extend from Application." with a link to the explanation.

Another option is to add the vm argument -Djava.library.path and point to
the missing runtime components (which I believe is just the bin directory
of the JavaFX runtime where the .dll files are in the case of Windows).

If we could explain this in the error message somehow it will save a lot of
trouble for a lot of people. Something like:

"Error: JavaFX runtime components are missing, and are required to run this
application. Either start the application from a class that does not extend
Application or specify the -Djava.library.path VM argument pointing to the
bin directory".

 I don't know if this specific case is detectable. Maybe Johan can comment.

On Thu, Jan 20, 2022 at 2:08 AM Steve Hannah  wrote:

> I've reduced the problem down to something minimal and have found that:
>
> 1. If your main class extends Application, and you try to run it like:
> java -jar MyApplication.jar
>
> It will fail immediately with:
> Error: JavaFX runtime components are missing, and are required to run this
> application
>
> 2. If you "trick" it, by making your Application class a separate class
> that you call from your main class, it will run fine using:
> java -jar MyApplication.jar
>
> 3. It will also run fine in this scenario using
> -Djava.class.path=MyApplication.jar instead of -jar:
> java -Djava.class.path=MyApplication.jar Main
>
> 3. If I try to simulate the exact same thing with my own launcher, it will
> hang somewhere in the JavaFX initialization:
>
> with javafx.verbose=true, the output is:
>
> System.loadLibrary(prism_es2) succeeded
> JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
> System.loadLibrary(glass) succeeded
>
> But it hangs there, and never displays the screen.
>
> The C code for this launcher is:
>
> char *mainClass;
>
> JavaVM *vm;
> JNIEnv *env;
> JavaVMInitArgs vm_args;
> JavaVMOption options[2];
> mainClass = "Main";
> options[0].optionString = "-Djava.class.path=MyApplication.jar";
> options[1].optionString = "-Djavafx.verbose=true";
> vm_args.version = JNI_VERSION_1_2;
> vm_args.options = options;
> vm_args.nOptions = 2;
> vm_args.ignoreUnrecognized = 0;
>
> jobjectArray args;
> jint res = JNI_CreateJavaVM(, (void **), _args);
> if (res < 0) {
> printf("Can't create Java VM\n");
> exit(1);
> }
> jclass cls = (*env)->FindClass(env, mainClass);
> if (cls == 0) {
>
> printf("Main class %s class not found\n", mainClass);
> exit(1);
> }
> jmethodID mid =
> (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V");
> if (mid == 0) {
> printf("main() method not found\n");
> exit(1);
> }
> //jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list
> args =
>  (*env)->NewObjectArray(env, 0, (*env)->FindClass(env,
> "java/lang/String"), NULL);
> if (args == 0) {
> printf("Out of memory\n");
> exit(1);
> }
>
> (*env)->CallStaticVoidMethod(env, cls, mid, args);
>
>
>
> Can anyone spot any differences between that and running with the "java"
> binary:?
> java -Djava.class.path=MyApplication.jar Main
>
> I have experimented both with JDKs that include JavaFX (e.g. Zulu) and ones
> that do not (e.g. AdoptOpenJDK).  Both exhibit the same behaviour (except
> with AdoptOpenJDK, I also add the javafx jars to the classpath).
>
> For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent with
> my earlier troubles on Ubuntu (also JDK11).
>
>
> Best regards
>
> Steve
>
>
> On Wed, Jan 19, 2022 at 3:06 PM John Neffenger  wrote:
>
> > On 1/19/22 2:12 PM, Steve Hannah wrote:
> > > I have been resisting using modules for a long time because it just
> makes
> > > things more complicated, ...
> >
> > It also makes some things easier, though, and certainly smaller. It's
> > easier to use an old-school Makefile with modules, and using 'jlink' can
> > get a simple Hello World JavaFX application and Java runtime down to
> > just 31 megabytes.
> >
> > Here's my minimal, no-magic example:
> >
> > https://github.com/jgneff/hello-javafx
> >
> > with a simple Makefile:
> >
> > https://github.com/jgneff/hello-javafx/blob/main/Makefile
> >
> > and a Maven POM for use online with Maven Central or offline with a
> > local Debian- or 

Re: JavaFX Launch Failure on Ubuntu from JNI

[Steve Hannah]

I've reduced the problem down to something minimal and have found that:

1. If your main class extends Application, and you try to run it like:
java -jar MyApplication.jar

It will fail immediately with:
Error: JavaFX runtime components are missing, and are required to run this
application

2. If you "trick" it, by making your Application class a separate class
that you call from your main class, it will run fine using:
java -jar MyApplication.jar

3. It will also run fine in this scenario using
-Djava.class.path=MyApplication.jar instead of -jar:
java -Djava.class.path=MyApplication.jar Main

3. If I try to simulate the exact same thing with my own launcher, it will
hang somewhere in the JavaFX initialization:

with javafx.verbose=true, the output is:

System.loadLibrary(prism_es2) succeeded
JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
System.loadLibrary(glass) succeeded

But it hangs there, and never displays the screen.

The C code for this launcher is:

char *mainClass;

JavaVM *vm;
JNIEnv *env;
JavaVMInitArgs vm_args;
JavaVMOption options[2];
mainClass = "Main";
options[0].optionString = "-Djava.class.path=MyApplication.jar";
options[1].optionString = "-Djavafx.verbose=true";
vm_args.version = JNI_VERSION_1_2;
vm_args.options = options;
vm_args.nOptions = 2;
vm_args.ignoreUnrecognized = 0;

jobjectArray args;
jint res = JNI_CreateJavaVM(, (void **), _args);
if (res < 0) {
printf("Can't create Java VM\n");
exit(1);
}
jclass cls = (*env)->FindClass(env, mainClass);
if (cls == 0) {

printf("Main class %s class not found\n", mainClass);
exit(1);
}
jmethodID mid =
(*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V");
if (mid == 0) {
printf("main() method not found\n");
exit(1);
}
//jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list
args =
 (*env)->NewObjectArray(env, 0, (*env)->FindClass(env,
"java/lang/String"), NULL);
if (args == 0) {
printf("Out of memory\n");
exit(1);
}

(*env)->CallStaticVoidMethod(env, cls, mid, args);



Can anyone spot any differences between that and running with the "java"
binary:?
java -Djava.class.path=MyApplication.jar Main

I have experimented both with JDKs that include JavaFX (e.g. Zulu) and ones
that do not (e.g. AdoptOpenJDK).  Both exhibit the same behaviour (except
with AdoptOpenJDK, I also add the javafx jars to the classpath).

For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent with
my earlier troubles on Ubuntu (also JDK11).


Best regards

Steve


On Wed, Jan 19, 2022 at 3:06 PM John Neffenger  wrote:

> On 1/19/22 2:12 PM, Steve Hannah wrote:
> > I have been resisting using modules for a long time because it just makes
> > things more complicated, ...
>
> It also makes some things easier, though, and certainly smaller. It's
> easier to use an old-school Makefile with modules, and using 'jlink' can
> get a simple Hello World JavaFX application and Java runtime down to
> just 31 megabytes.
>
> Here's my minimal, no-magic example:
>
> https://github.com/jgneff/hello-javafx
>
> with a simple Makefile:
>
> https://github.com/jgneff/hello-javafx/blob/main/Makefile
>
> and a Maven POM for use online with Maven Central or offline with a
> local Debian- or Ubuntu-built Maven repository:
>
> https://github.com/jgneff/hello-javafx/blob/main/pom.xml
>
> John
>


-- 
Steve Hannah
Web Lite Solutions Corp.

Re: JavaFX Launch Failure on Ubuntu from JNI

[John Neffenger]

On 1/19/22 2:12 PM, Steve Hannah wrote:

I have been resisting using modules for a long time because it just makes
things more complicated, ...


It also makes some things easier, though, and certainly smaller. It's 
easier to use an old-school Makefile with modules, and using 'jlink' can 
get a simple Hello World JavaFX application and Java runtime down to 
just 31 megabytes.


Here's my minimal, no-magic example:

https://github.com/jgneff/hello-javafx

with a simple Makefile:

https://github.com/jgneff/hello-javafx/blob/main/Makefile

and a Maven POM for use online with Maven Central or offline with a 
local Debian- or Ubuntu-built Maven repository:


https://github.com/jgneff/hello-javafx/blob/main/pom.xml

John

Re: JavaFX Launch Failure on Ubuntu from JNI

[Steve Hannah]

Thanks for all the replies on this.  I'm working on getting a minimal
example.  Sadly I'm reduced to a hello-world JavaFX application that I
can't get running using Maven dependencies, even just doing it the plain
old way with "java -jar target/hello-world-1.0-SNAPSHOT.jar".

I get: "Error: JavaFX runtime components are missing, and are required to
run this application", even though all the jars should be findable on the
classpath via the executable jar's Class-Path entry.

I have been resisting using modules for a long time because it just makes
things more complicated, but I'm getting the feeling (both from replies on
this thread, and from the quirks I'm hitting here) that I'll need to use
modules if I want to use JavaFX.

Currently the hello world project is just a plain maven project where I add
the javafx dependencies (i.e. I'm not using the javafx archetype).  This
works in my real projects, but not in the hello-world - perhaps because the
hello world project extends Application in its main class, and the
real-world project does not.  I'll have to dissect the javafx archetype to
see what kind of magic sauce it adds over and above just the dependencies.

Steve

On Wed, Jan 19, 2022 at 1:49 PM Kevin Rushforth 
wrote:

>
>
> On 1/19/2022 1:46 PM, Michael Hall wrote:
> >
> >> On Jan 19, 2022, at 2:13 PM, Matthias Bläsing <
> mblaes...@doppel-helix.eu> wrote:
> >>
> >> Unsupported != does not work!
> > But it might mean less tested. So you might have to worry about things
> like it works here but does it work on Linux? It works with version x but
> does it work with y?
> >
> >> At this point in time Apache NetBeans loads JavaFX from classpath and
> >> it works.
> > Probably means it’s pretty thoroughly tested though.
> >
> >> FWIW,  in a draft of my earlier reply, I had written a comment pointing
> out that JavaFX is only supported with modules. I didn't include it,
> because I think it very unlikely that that's related to the problem.
> >>
> >> I think a simple reproducer will be most helpful in tracking this down.
> >>
> >> — Kevin
> > It probably isn’t the cause but since the OP indicated he was looking
> for suggestions, and not necessarily a bug fix at this point, I thought it
> might be worth a mention. If he wasn’t aware of this he might want to
> consider it on future updates.
>
> Yes, it was worth a mention, and might even be something he could test
> locally to see if it makes a difference.
>
> -- Kevin
>
>

-- 
Steve Hannah
Web Lite Solutions Corp.

Re: JavaFX Launch Failure on Ubuntu from JNI

[Kevin Rushforth]

On 1/19/2022 1:46 PM, Michael Hall wrote:



On Jan 19, 2022, at 2:13 PM, Matthias Bläsing  wrote:

Unsupported != does not work!

But it might mean less tested. So you might have to worry about things like it 
works here but does it work on Linux? It works with version x but does it work 
with y?


At this point in time Apache NetBeans loads JavaFX from classpath and
it works.

Probably means it’s pretty thoroughly tested though.


FWIW,  in a draft of my earlier reply, I had written a comment pointing out 
that JavaFX is only supported with modules. I didn't include it, because I 
think it very unlikely that that's related to the problem.

I think a simple reproducer will be most helpful in tracking this down.

— Kevin

It probably isn’t the cause but since the OP indicated he was looking for 
suggestions, and not necessarily a bug fix at this point, I thought it might be 
worth a mention. If he wasn’t aware of this he might want to consider it on 
future updates.


Yes, it was worth a mention, and might even be something he could test 
locally to see if it makes a difference.


-- Kevin

Re: JavaFX Launch Failure on Ubuntu from JNI

[Michael Hall]

> On Jan 19, 2022, at 2:13 PM, Matthias Bläsing  
> wrote:
> 
> Unsupported != does not work!

But it might mean less tested. So you might have to worry about things like it 
works here but does it work on Linux? It works with version x but does it work 
with y?

> At this point in time Apache NetBeans loads JavaFX from classpath and
> it works.

Probably means it’s pretty thoroughly tested though.

> FWIW,  in a draft of my earlier reply, I had written a comment pointing out 
> that JavaFX is only supported with modules. I didn't include it, because I 
> think it very unlikely that that's related to the problem.
> 
> I think a simple reproducer will be most helpful in tracking this down.
> 
> — Kevin

It probably isn’t the cause but since the OP indicated he was looking for 
suggestions, and not necessarily a bug fix at this point, I thought it might be 
worth a mention. If he wasn’t aware of this he might want to consider it on 
future updates.

Re: JavaFX Launch Failure on Ubuntu from JNI

[Kevin Rushforth]

FWIW,  in a draft of my earlier reply, I had written a comment pointing 
out that JavaFX is only supported with modules. I didn't include it, 
because I think it very unlikely that that's related to the problem.


I think a simple reproducer will be most helpful in tracking this down.

-- Kevin


On 1/19/2022 12:13 PM, Matthias Bläsing wrote:

Hi,

Am Mittwoch, dem 19.01.2022 um 13:49 -0600 schrieb Michael Hall:

They are included in the classpath.  I'm not using modules.

This one 
https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna
 

Says…

The Warning

JavaFX only supports being loaded as named modules. In other words, JavaFX only 
supports being loaded from the module-path, not the class-path.


Unsupported != does not work!

At this point in time Apache NetBeans loads JavaFX from classpath and
it works.

And before people throw fire at me, doing this revealed at least two
implementation issues, that would have bitten anyone running JavaFX
with a semi-complex module setup, but the classpath case is just so
much more realistic for an applicatin, that tries to work on JDK 8-17.

Greetings

Matthias

Re: JavaFX Launch Failure on Ubuntu from JNI

[Matthias Bläsing]

Hi,

Am Mittwoch, dem 19.01.2022 um 13:49 -0600 schrieb Michael Hall:
> 
> > They are included in the classpath.  I'm not using modules.
> 
> This one 
> https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna
>  
> 
> Says…
> 
> The Warning
> 
> JavaFX only supports being loaded as named modules. In other words, JavaFX 
> only supports being loaded from the module-path, not the class-path.
> 

Unsupported != does not work!

At this point in time Apache NetBeans loads JavaFX from classpath and
it works.

And before people throw fire at me, doing this revealed at least two
implementation issues, that would have bitten anyone running JavaFX
with a semi-complex module setup, but the classpath case is just so
much more realistic for an applicatin, that tries to work on JDK 8-17.

Greetings

Matthias

Re: JavaFX Launch Failure on Ubuntu from JNI

[Michael Hall]

> On Jan 19, 2022, at 11:40 AM, Steve Hannah  wrote:
> 
> com.sun.javafx.application.PlatformImpl startup
> Exception in thread "Thread-5" java.lang.IllegalStateException: This
> operation is permitted on the event thread only; currentThread =
> Thread-5

Searching on…
com.sun.javafx.application.PlatformImpl startup Exception in 
java.lang.IllegalStateException: This operation is permitted on the event 
thread only;

Gets some hits. Somewhat interestingly given…

> They are included in the classpath.  I'm not using modules.

This one 
https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna
 

Says…

The Warning

JavaFX only supports being loaded as named modules. In other words, JavaFX only 
supports being loaded from the module-path, not the class-path.

With…

> java.lang.IllegalStateException: Not on FX application thread;
> currentThread = Thread-31
>at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)

Searching only on 
checkFxUserThread 
gets a number of similar sounding issues. Mostly they seem to suggest timing 
issues or taking various steps to ensure you are on the correct thread. 

e.g.
https://stackoverflow.com/questions/29449297/java-lang-illegalstateexception-not-on-fx-application-thread-currentthread-t
 

https://github.com/sarxos/webcam-capture/issues/469 

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v5]

[Martin Fox]

> When a window is closed while handling performKeyEquivalent the same NSEvent 
> might be passed to the new key window causing it to being processed twice. 
> Long ago a fix was put in for this case; when the GlassWindow was closed a 
> flag was set to ensure that we would return YES from performKeyEquivalent. To 
> fix RT-39813 the closing of the window was deferred causing the flag to be 
> set too late. This PR simply sets that flag when we schedule the close event 
> instead of when the OS actually closes the window.
> 
> This is a spot-fix for a larger problem, namely that we have no way of 
> knowing whether a performKeyEquivalent event was consumed or not. The changes 
> for fixing that are in PR #694. The changes got bundled into that PR only 
> because there's a lot of files involved and the exact same code paths are 
> touched.
> 
> System test is included (I'm surprised, it really is possible to generate 
> Cmd+Enter using a Robot). This is new territory for me so I have a manual 
> test I can submit as a backup.

Martin Fox has updated the pull request incrementally with one additional 
commit since the last revision:

  More coding standard tweaks

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/715/files
  - new: https://git.openjdk.java.net/jfx/pull/715/files/4962a1fb..182bad4b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=715=04
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=715=03-04

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/715.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715

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

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4]

[Kevin Rushforth]

On Wed, 19 Jan 2022 16:25:17 GMT, Martin Fox  wrote:

>> When a window is closed while handling performKeyEquivalent the same NSEvent 
>> might be passed to the new key window causing it to being processed twice. 
>> Long ago a fix was put in for this case; when the GlassWindow was closed a 
>> flag was set to ensure that we would return YES from performKeyEquivalent. 
>> To fix RT-39813 the closing of the window was deferred causing the flag to 
>> be set too late. This PR simply sets that flag when we schedule the close 
>> event instead of when the OS actually closes the window.
>> 
>> This is a spot-fix for a larger problem, namely that we have no way of 
>> knowing whether a performKeyEquivalent event was consumed or not. The 
>> changes for fixing that are in PR #694. The changes got bundled into that PR 
>> only because there's a lot of files involved and the exact same code paths 
>> are touched.
>> 
>> System test is included (I'm surprised, it really is possible to generate 
>> Cmd+Enter using a Robot). This is new territory for me so I have a manual 
>> test I can submit as a backup.
>
> Martin Fox has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Renamed test to match existing conventions along with minor cleanup.

The fix and test both look good, with one requested code style change. I can 
confirm that the test fails without the fix and passes with the fix.

Also, In order to avoid problems with our CI and nightly build, I want #720 to 
be integrated before this PR.

tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessingTest.java
 line 25:

> 23:  * questions.
> 24:  */
> 25: package test.robot.javafx.scene;

Very minor: we usually add a blank line between the copyright header block and 
the `package` statement. I only mention it because I have another change to 
request.

tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessingTest.java
 line 67:

> 65: waitForLatch(dialogLatch, 5, "Dialog never received shortcut");
> 66: if (testApp.failed())
> 67: Assertions.fail("performKeyEquivalent was handled twice in 
> separate windows");

Please add curly braces around the target of the `if` statement. The only 
exception to this rule for Java code is where the statement is short enough to 
be on the same line as the `if`.

-

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

[jfx18] RFR: 8280280: Update boot JDK to 17.0.2

[Kevin Rushforth]

JDK 17.0.2 shipped yesterday as part of the January CPU release. We should 
update the JavaFX 18 build to use that version, so this is targeted for `jfx18`.

-

Commit messages:
 - 8280280: Update boot JDK to 17.0.2

Changes: https://git.openjdk.java.net/jfx/pull/721/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=721=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280280
  Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jfx/pull/721.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/721/head:pull/721

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

Re: [jfx18] RFR: 8280280: Update boot JDK to 17.0.2

[Kevin Rushforth]

On Wed, 19 Jan 2022 18:43:31 GMT, Kevin Rushforth  wrote:

> JDK 17.0.2 shipped yesterday as part of the January CPU release. We should 
> update the JavaFX 18 build to use that version, so this is targeted for 
> `jfx18`.

I'd like two reviewers given that we are in ramp-down for JavaFX 18.

-

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

Re: [External] : Re: JavaFX Launch Failure on Ubuntu from JNI

[Kevin Rushforth]

Very odd. If you can create a simple, standalone test case, ideally a 
single, self-contained JavaFX application and a C main program as a 
launcher, then you might want to file a bug at https://bugreport.java.com/


-- Kevin


On 1/19/2022 10:42 AM, Steve Hannah wrote:

Thanks for the reply.

>  What are the JVM args you use for launching?

vm_args.version = JNI_VERSION_1_6;
  vm_args.options = options;
  vm_args.nOptions = numOptions;
  vm_args.ignoreUnrecognized = 1;

For options, I'm just using -Djava.class.path, though I have 
experimented using -Djavafx.verbose=true, which doesn't tell me much 
more.  It just logs warnings when it can't find the javafx nativelibs, 
in the JDK libs directory - and reports that they are loaded from 
resource.


>  Are the JavaFX modules jlink'ed into the JDK or loaded via 
--module-path?


They are included in the classpath.  I'm not using modules.

Best regards

Steve

On Wed, Jan 19, 2022 at 10:35 AM Kevin Rushforth 
 wrote:


Hard to say what's going on without more information. What are the
JVM
args you use for launching? Are the JavaFX modules jlink'ed into
the JDK
or loaded via --module-path? As a debugging aid, you might try
setting
the system property "javafx.verbose" to "true" before loading your
MyApplication class.

-- Kevin


On 1/19/2022 9:40 AM, Steve Hannah wrote:
> The following issue only seems to occur on Linux (Ubuntu
20.04.1), and only
> when I try to launch the JVM from a custom C launcher using
JNI.  It does
> not occur when launching the JVM as a separate process using the
"java"
> binary.  It also does not occur on MacOS when using the same C
launcher
> using JNI.
>
> When I call MyApplication.launch(args). (where MyApplication
extends the
> JavaFX Application class), I get the following stack trace:
>
> Jan. 19, 2022 8:54:27 A.M.
com.sun.javafx.application.PlatformImpl startup
> Exception in thread "Thread-5" java.lang.IllegalStateException: This
> operation is permitted on the event thread only; currentThread =
> Thread-5
>          at
com.sun.glass.ui.Application.checkEventThread(Application.java:447)
>          at
com.sun.glass.ui.Application.setName(Application.java:200)
>          at

com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142)
>          at

com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
>          at
java.base/java.security.AccessController.doPrivileged(Native Method)
>          at

com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
>          at

com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
> Exception in Application start method
> Exception in thread "Thread-31" Failed to show docs
> java.lang.IllegalStateException: Not on FX application thread;
> currentThread = Thread-31
>          at
com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
>          at

com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
>          at
com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828)
>          at

com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624)
>          at

com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
>          at

com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
>          at
java.base/java.security.AccessController.doPrivileged(Native Method)
>          at

com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
>          at

com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
> java.lang.RuntimeException: Exception in Application start method
>          at

com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901)
>          at

com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196)
>          at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.IllegalStateException: Not on FX application
> thread; currentThread = Thread-6
>          at
com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
>          at

com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
>          at javafx.stage.Stage.(Stage.java:254)
>          at javafx.stage.Stage.(Stage.java:240)
>          at

com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845)
>          at

com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
>          at

[jfx17u] Integrated: 8280172: Create release notes for JavaFX 17.0.2

[Abhinay Agarwal]

On Wed, 19 Jan 2022 10:58:54 GMT, Abhinay Agarwal  wrote:

> Release Notes for 17.0.2

This pull request has now been integrated.

Changeset: 3aa459eb
Author:Abhinay Agarwal 
Committer: Kevin Rushforth 
URL:   
https://git.openjdk.java.net/jfx17u/commit/3aa459ebda3ffeccd5349a026e843d4489121ecd
Stats: 29 lines in 1 file changed: 29 ins; 0 del; 0 mod

8280172: Create release notes for JavaFX 17.0.2

Reviewed-by: kcr

-

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: JavaFX Launch Failure on Ubuntu from JNI

[Steve Hannah]

Thanks for the reply.

>  What are the JVM args you use for launching?

vm_args.version = JNI_VERSION_1_6;
  vm_args.options = options;
  vm_args.nOptions = numOptions;
  vm_args.ignoreUnrecognized = 1;

For options, I'm just using -Djava.class.path, though I have experimented
using -Djavafx.verbose=true, which doesn't tell me much more.  It just logs
warnings when it can't find the javafx nativelibs, in the JDK libs
directory - and reports that they are loaded from resource.

>  Are the JavaFX modules jlink'ed into the JDK or loaded via
--module-path?

They are included in the classpath.  I'm not using modules.

Best regards

Steve

On Wed, Jan 19, 2022 at 10:35 AM Kevin Rushforth 
wrote:

> Hard to say what's going on without more information. What are the JVM
> args you use for launching? Are the JavaFX modules jlink'ed into the JDK
> or loaded via --module-path? As a debugging aid, you might try setting
> the system property "javafx.verbose" to "true" before loading your
> MyApplication class.
>
> -- Kevin
>
>
> On 1/19/2022 9:40 AM, Steve Hannah wrote:
> > The following issue only seems to occur on Linux (Ubuntu 20.04.1), and
> only
> > when I try to launch the JVM from a custom C launcher using JNI.  It does
> > not occur when launching the JVM as a separate process using the "java"
> > binary.  It also does not occur on MacOS when using the same C launcher
> > using JNI.
> >
> > When I call MyApplication.launch(args). (where MyApplication extends the
> > JavaFX Application class), I get the following stack trace:
> >
> > Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl
> startup
> > Exception in thread "Thread-5" java.lang.IllegalStateException: This
> > operation is permitted on the event thread only; currentThread =
> > Thread-5
> >  at
> com.sun.glass.ui.Application.checkEventThread(Application.java:447)
> >  at com.sun.glass.ui.Application.setName(Application.java:200)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
> >  at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
> >  at
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
> > Exception in Application start method
> > Exception in thread "Thread-31" Failed to show docs
> > java.lang.IllegalStateException: Not on FX application thread;
> > currentThread = Thread-31
> >  at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
> >  at
> com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
> >  at
> com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
> >  at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
> >  at
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
> > java.lang.RuntimeException: Exception in Application start method
> >  at
> com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901)
> >  at
> com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196)
> >  at java.base/java.lang.Thread.run(Thread.java:829)
> > Caused by: java.lang.IllegalStateException: Not on FX application
> > thread; currentThread = Thread-6
> >  at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
> >  at
> com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
> >  at javafx.stage.Stage.(Stage.java:254)
> >  at javafx.stage.Stage.(Stage.java:240)
> >  at
> com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
> >  at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> >  at
> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
> >  at
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
> >
> >
> > I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1),
> > running on a few different JDK installs (all JDK11).  Above stacktrace is
> > from 17.0.1.

Re: JavaFX Launch Failure on Ubuntu from JNI

[Kevin Rushforth]

Hard to say what's going on without more information. What are the JVM 
args you use for launching? Are the JavaFX modules jlink'ed into the JDK 
or loaded via --module-path? As a debugging aid, you might try setting 
the system property "javafx.verbose" to "true" before loading your 
MyApplication class.


-- Kevin


On 1/19/2022 9:40 AM, Steve Hannah wrote:

The following issue only seems to occur on Linux (Ubuntu 20.04.1), and only
when I try to launch the JVM from a custom C launcher using JNI.  It does
not occur when launching the JVM as a separate process using the "java"
binary.  It also does not occur on MacOS when using the same C launcher
using JNI.

When I call MyApplication.launch(args). (where MyApplication extends the
JavaFX Application class), I get the following stack trace:

Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup
Exception in thread "Thread-5" java.lang.IllegalStateException: This
operation is permitted on the event thread only; currentThread =
Thread-5
 at com.sun.glass.ui.Application.checkEventThread(Application.java:447)
 at com.sun.glass.ui.Application.setName(Application.java:200)
 at 
com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
 at java.base/java.security.AccessController.doPrivileged(Native Method)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
 at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
Exception in Application start method
Exception in thread "Thread-31" Failed to show docs
java.lang.IllegalStateException: Not on FX application thread;
currentThread = Thread-31
 at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
 at 
com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
 at 
com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828)
 at 
com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
 at java.base/java.security.AccessController.doPrivileged(Native Method)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
 at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
java.lang.RuntimeException: Exception in Application start method
 at 
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901)
 at 
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196)
 at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.IllegalStateException: Not on FX application
thread; currentThread = Thread-6
 at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
 at 
com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
 at javafx.stage.Stage.(Stage.java:254)
 at javafx.stage.Stage.(Stage.java:240)
 at 
com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
 at java.base/java.security.AccessController.doPrivileged(Native Method)
 at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
 at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)


I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1),
running on a few different JDK installs (all JDK11).  Above stacktrace is
from 17.0.1.

 From the C application that launches the JVM, I have tried running directly
on the main thread, and also launching it in a fresh thread using pthreads
- but same issue.  I am running this inside an application written in Go
but the JNI code is all in C.

It appears as though JavaFX is unable to create its application thread for
some reason.  Does anyone have any suggestions on reasons why this would be
the case?  Are there some system properties that need to be there which
would have been bootstrapped by the "java" binary, but would not when the
JVM is launched via JNI?

Any suggestions appreciated.  I've been banging my head on this for a while
now.

Best regards

Steve

JavaFX Launch Failure on Ubuntu from JNI

[Steve Hannah]

The following issue only seems to occur on Linux (Ubuntu 20.04.1), and only
when I try to launch the JVM from a custom C launcher using JNI.  It does
not occur when launching the JVM as a separate process using the "java"
binary.  It also does not occur on MacOS when using the same C launcher
using JNI.

When I call MyApplication.launch(args). (where MyApplication extends the
JavaFX Application class), I get the following stack trace:

Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup
Exception in thread "Thread-5" java.lang.IllegalStateException: This
operation is permitted on the event thread only; currentThread =
Thread-5
at com.sun.glass.ui.Application.checkEventThread(Application.java:447)
at com.sun.glass.ui.Application.setName(Application.java:200)
at 
com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142)
at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
Exception in Application start method
Exception in thread "Thread-31" Failed to show docs
java.lang.IllegalStateException: Not on FX application thread;
currentThread = Thread-31
at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828)
at 
com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624)
at 
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
java.lang.RuntimeException: Exception in Application start method
at 
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901)
at 
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.IllegalStateException: Not on FX application
thread; currentThread = Thread-6
at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
at javafx.stage.Stage.(Stage.java:254)
at javafx.stage.Stage.(Stage.java:240)
at 
com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845)
at 
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)


I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1),
running on a few different JDK installs (all JDK11).  Above stacktrace is
from 17.0.1.

>From the C application that launches the JVM, I have tried running directly
on the main thread, and also launching it in a fresh thread using pthreads
- but same issue.  I am running this inside an application written in Go
but the JNI code is all in C.

It appears as though JavaFX is unable to create its application thread for
some reason.  Does anyone have any suggestions on reasons why this would be
the case?  Are there some system properties that need to be there which
would have been bootstrapped by the "java" binary, but would not when the
JVM is launched via JNI?

Any suggestions appreciated.  I've been banging my head on this for a while
now.

Best regards

Steve

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4]

[Jose Pereda]

On Wed, 19 Jan 2022 16:25:17 GMT, Martin Fox  wrote:

>> When a window is closed while handling performKeyEquivalent the same NSEvent 
>> might be passed to the new key window causing it to being processed twice. 
>> Long ago a fix was put in for this case; when the GlassWindow was closed a 
>> flag was set to ensure that we would return YES from performKeyEquivalent. 
>> To fix RT-39813 the closing of the window was deferred causing the flag to 
>> be set too late. This PR simply sets that flag when we schedule the close 
>> event instead of when the OS actually closes the window.
>> 
>> This is a spot-fix for a larger problem, namely that we have no way of 
>> knowing whether a performKeyEquivalent event was consumed or not. The 
>> changes for fixing that are in PR #694. The changes got bundled into that PR 
>> only because there's a lot of files involved and the exact same code paths 
>> are touched.
>> 
>> System test is included (I'm surprised, it really is possible to generate 
>> Cmd+Enter using a Robot). This is new territory for me so I have a manual 
>> test I can submit as a backup.
>
> Martin Fox has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Renamed test to match existing conventions along with minor cleanup.

Looks good

-

Marked as reviewed by jpereda (Committer).

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

Re: [jfx18] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases

[Kevin Rushforth]

On Wed, 19 Jan 2022 15:18:48 GMT, Kevin Rushforth  wrote:

> Fixed a test dependency issue in `build.gradle` that causes a compilation 
> failure when running `gradle test` if the `Assumptions` API from JUnit5 is 
> used. I added a test that fails to compile without the build fix and passes 
> with the fix.
> 
> This was first discovered when testing the patch for PR #715, which fails to 
> compile on my local macOS system. After applying this fix, I can compile and 
> run the test from that PR.

NOTE: this test fix is targeted to `jfx18`.

-

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

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3]

[Kevin Rushforth]

On Wed, 19 Jan 2022 16:38:58 GMT, Martin Fox  wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java
>>  line 53:
>> 
>>> 51: // When a key equivalent closes a window it can be passed
>>> 52: // to the new key window and processed twice.
>>> 53: public class DoubleShortcutProcessing {
>> 
>> When I launch the test with: 
>> 
>> sh gradlew -PUSE_ROBOT=true -PFULL_TEST=true :systemTests:test 
>> --tests=test.robot.javafx.scene.DoubleShortcutProcessing
>> 
>> I get the system dialog "Accessibility Access (Events)" with the message 
>> "'java' would like to control this computer using accessibility features."
>> 
>> After adding java to Security>accessibility, the test works fine.
>> 
>> Maybe this need to be added to the javadoc of the test.
>
> I wouldn't know what to write. On my system adding 'java' doesn't fix the 
> problem, the OS insists I have to add 'Terminal'. In general it's easier to 
> bump into this dialog and then go to System Preferences since the OS will 
> have added the executable to the list which is convenient for a file like 
> /usr/bin/java that's normally hidden.

This requirement is independent of this fix and applies to all robot tests. I 
do not think any additional documentation is needed here.

-

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

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3]

[Martin Fox]

On Tue, 18 Jan 2022 23:35:43 GMT, Jose Pereda  wrote:

>> Martin Fox has refreshed the contents of this pull request, and previous 
>> commits have been removed. The incremental views will show differences 
>> compared to the previous content of the PR. The pull request contains one 
>> new commit since the last revision:
>> 
>>   Re-instating fix for Cmd shortcut being handled by two windows
>
> tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java
>  line 53:
> 
>> 51: // When a key equivalent closes a window it can be passed
>> 52: // to the new key window and processed twice.
>> 53: public class DoubleShortcutProcessing {
> 
> When I launch the test with: 
> 
> sh gradlew -PUSE_ROBOT=true -PFULL_TEST=true :systemTests:test 
> --tests=test.robot.javafx.scene.DoubleShortcutProcessing
> 
> I get the system dialog "Accessibility Access (Events)" with the message 
> "'java' would like to control this computer using accessibility features."
> 
> After adding java to Security>accessibility, the test works fine.
> 
> Maybe this need to be added to the javadoc of the test.

I wouldn't know what to write. On my system adding 'java' doesn't fix the 
problem, the OS insists I have to add 'Terminal'. In general it's easier to 
bump into this dialog and then go to System Preferences since the OS will have 
added the executable to the list which is convenient for a file like 
/usr/bin/java that's normally hidden.

-

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

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v4]

[Martin Fox]

> When a window is closed while handling performKeyEquivalent the same NSEvent 
> might be passed to the new key window causing it to being processed twice. 
> Long ago a fix was put in for this case; when the GlassWindow was closed a 
> flag was set to ensure that we would return YES from performKeyEquivalent. To 
> fix RT-39813 the closing of the window was deferred causing the flag to be 
> set too late. This PR simply sets that flag when we schedule the close event 
> instead of when the OS actually closes the window.
> 
> This is a spot-fix for a larger problem, namely that we have no way of 
> knowing whether a performKeyEquivalent event was consumed or not. The changes 
> for fixing that are in PR #694. The changes got bundled into that PR only 
> because there's a lot of files involved and the exact same code paths are 
> touched.
> 
> System test is included (I'm surprised, it really is possible to generate 
> Cmd+Enter using a Robot). This is new territory for me so I have a manual 
> test I can submit as a backup.

Martin Fox has updated the pull request incrementally with one additional 
commit since the last revision:

  Renamed test to match existing conventions along with minor cleanup.

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/715/files
  - new: https://git.openjdk.java.net/jfx/pull/715/files/edebba96..4962a1fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=715=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=715=02-03

  Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/715.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715

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

[jfx18] RFR: 8280275: JUnit5 tests using Assumptions API fail to compile in some cases

[Kevin Rushforth]

Fixed a test dependency issue in `build.gradle` that causes a compilation 
failure when running `gradle test` if the `Assumptions` API from JUnit5 is 
used. I added a test that fails to compile without the build fix and passes 
with the fix.

This was first discovered when testing the patch for PR #715, which fails to 
compile on my local macOS system. After applying this fix, I can compile and 
run the test from that PR.

-

Commit messages:
 - 8280275: JUnit5 tests using Assumptions API fail to compile in some cases

Changes: https://git.openjdk.java.net/jfx/pull/720/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=720=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280275
  Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/720.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/720/head:pull/720

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

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3]

[Kevin Rushforth]

On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox  wrote:

>> When a window is closed while handling performKeyEquivalent the same NSEvent 
>> might be passed to the new key window causing it to being processed twice. 
>> Long ago a fix was put in for this case; when the GlassWindow was closed a 
>> flag was set to ensure that we would return YES from performKeyEquivalent. 
>> To fix RT-39813 the closing of the window was deferred causing the flag to 
>> be set too late. This PR simply sets that flag when we schedule the close 
>> event instead of when the OS actually closes the window.
>> 
>> This is a spot-fix for a larger problem, namely that we have no way of 
>> knowing whether a performKeyEquivalent event was consumed or not. The 
>> changes for fixing that are in PR #694. The changes got bundled into that PR 
>> only because there's a lot of files involved and the exact same code paths 
>> are touched.
>> 
>> System test is included (I'm surprised, it really is possible to generate 
>> Cmd+Enter using a Robot). This is new territory for me so I have a manual 
>> test I can submit as a backup.
>
> Martin Fox has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR. The pull request contains one new 
> commit since the last revision:
> 
>   Re-instating fix for Cmd shortcut being handled by two windows

I filed [JDK-8280275](https://bugs.openjdk.java.net/browse/JDK-8280275) to 
track the test failure. I'll submit a PR against jfx18 shortly.

-

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

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v4]

[Kevin Rushforth]

On Wed, 19 Jan 2022 14:16:14 GMT, Abhinay Agarwal  wrote:

>> Release Notes for 17.0.2
>
> Abhinay Agarwal has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Remove build and test changes

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: [jfx18] RFR: 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage [v3]

[Kevin Rushforth]

On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox  wrote:

>> When a window is closed while handling performKeyEquivalent the same NSEvent 
>> might be passed to the new key window causing it to being processed twice. 
>> Long ago a fix was put in for this case; when the GlassWindow was closed a 
>> flag was set to ensure that we would return YES from performKeyEquivalent. 
>> To fix RT-39813 the closing of the window was deferred causing the flag to 
>> be set too late. This PR simply sets that flag when we schedule the close 
>> event instead of when the OS actually closes the window.
>> 
>> This is a spot-fix for a larger problem, namely that we have no way of 
>> knowing whether a performKeyEquivalent event was consumed or not. The 
>> changes for fixing that are in PR #694. The changes got bundled into that PR 
>> only because there's a lot of files involved and the exact same code paths 
>> are touched.
>> 
>> System test is included (I'm surprised, it really is possible to generate 
>> Cmd+Enter using a Robot). This is new territory for me so I have a manual 
>> test I can submit as a backup.
>
> Martin Fox has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR. The pull request contains one new 
> commit since the last revision:
> 
>   Re-instating fix for Cmd shortcut being handled by two windows

The fix looks good to me. It looks like we have a build dependency problem with 
the new JUnit5 Assumptions API. I get the following compilation error on my 
system when trying to run the system tests:


gradle --info -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests 
DoubleShortcutProcessing
...
> Task :systemTests:compileTestJava
tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java:64:
 error: cannot access TestAbortedException
Assumptions.assumeTrue(PlatformUtil.isMac());
  ^
  class file for org.opentest4j.TestAbortedException not found


The following fixes it, although the fact that this is needed at test 
compilation time seems like an unfortunate choice on the part of JUnit.


--- a/build.gradle
+++ b/build.gradle
@@ -1969,7 +1969,7 @@ allprojects {
 testRuntimeOnly group: "org.junit.platform", name: 
"junit-platform-commons", version: "1.8.1"
 testRuntimeOnly group: "org.junit.platform", name: 
"junit-platform-engine", version: "1.8.1"
 testRuntimeOnly group: "org.junit.vintage", name: 
"junit-vintage-engine", version: "5.8.1"
-testRuntimeOnly group: "org.opentest4j", name: "opentest4j", version: 
"1.2.0"
+testImplementation group: "org.opentest4j", name: "opentest4j", 
version: "1.2.0"


It seems odd that this doesn't fail in the GitHub action run, since it fails 
for me even running `gradle test` (the systemTests project is compiled, but not 
executed, even when `FULL_TEST` is not set to true).

I'd prefer this dependency issue to be fixed by a separate bug, which I will 
file today.

-

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

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v4]

[Abhinay Agarwal]

> Release Notes for 17.0.2

Abhinay Agarwal has updated the pull request incrementally with one additional 
commit since the last revision:

  Remove build and test changes

-

Changes:
  - all: https://git.openjdk.java.net/jfx17u/pull/28/files
  - new: https://git.openjdk.java.net/jfx17u/pull/28/files/229bcb00..45b41200

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx17u=28=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx17u=28=02-03

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v3]

[Kevin Rushforth]

On Wed, 19 Jan 2022 13:06:14 GMT, Abhinay Agarwal  wrote:

>> Release Notes for 17.0.2
>
> Abhinay Agarwal has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Add security fix

The latest addition looks good. Per the above discussion, you should remove the 
"List of Task" section.

-

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2]

[Kevin Rushforth]

On Wed, 19 Jan 2022 12:48:32 GMT, Abhinay Agarwal  wrote:

>> doc-files/release-notes-17.0.2.md line 17:
>> 
>>> 15: [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638)|Update 
>>> copyright header for files modified in 2021|other
>>> 16: [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413)|FX: 
>>> Update copyright year in docs, readme files to 2022|other
>>> 17: [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396)|Define 
>>> version in .jcheck/conf|other
>> 
>> We normally exclude `Task`s along with build and test changes from the 
>> release notes.
>
> I had added a 
> [comment](https://github.com/openjdk/jfx17u/pull/28#discussion_r787632463), 
> asking about the same. To confirm, if the parent or the backport issue has 
> any [build and test related 
> labels](https://github.com/openjdk/jfx/pull/414#issuecomment-789709510), it 
> should be skipped. Is my understanding correct?

I don't see a comment asking about it, but yes, your understanding is correct. 
The release notes should include bugs and enhancements (or backports of same) 
without build, test, or cleanup labels.

-

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v3]

[Abhinay Agarwal]

> Release Notes for 17.0.2

Abhinay Agarwal has updated the pull request incrementally with one additional 
commit since the last revision:

  Add security fix

-

Changes:
  - all: https://git.openjdk.java.net/jfx17u/pull/28/files
  - new: https://git.openjdk.java.net/jfx17u/pull/28/files/267df8a1..229bcb00

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx17u=28=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx17u=28=01-02

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2]

[Abhinay Agarwal]

On Wed, 19 Jan 2022 12:18:40 GMT, Kevin Rushforth  wrote:

>> Abhinay Agarwal has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Fix formatting
>
> doc-files/release-notes-17.0.2.md line 17:
> 
>> 15: [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638)|Update 
>> copyright header for files modified in 2021|other
>> 16: [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413)|FX: 
>> Update copyright year in docs, readme files to 2022|other
>> 17: [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396)|Define 
>> version in .jcheck/conf|other
> 
> We normally exclude `Task`s along with build and test changes from the 
> release notes.

I had added a 
[comment](https://github.com/openjdk/jfx17u/pull/28#discussion_r787632463), 
asking about the same. To confirm, if the parent or the backport issue has any 
[build and test related 
labels](https://github.com/openjdk/jfx/pull/414#issuecomment-789709510), it 
should be skipped. Is my understanding correct?

-

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: Aw: Strange test failures: validation of PGGroup children failed

[Jeanette Winzenburg]

Zitat von Marius Hanl :


I think I had the same issues some days ago. What helped was to delete all
the 'build' or 'target' or 'out' folders - so basically all the folders
with the compiled files.


thanks for the suggestion - didn't help, unfortunately

wondering what is "javafx.graphics@19-internal" - doesn't it sound  
like some mis-configuration somewhere? (in Eclipse it's the same error  
message, but without the @19-internal).


Will simply ignore it for now (working fine if the test is passing and  
that's what we are after in the end :), nevertheless itching ..





    GESENDET: Dienstag, 18. Januar 2022 um 15:46 Uhr
VON: "Jeanette Winzenburg" 
AN: "openjfx-dev" 
BETREFF: Strange test failures: validation of PGGroup children failed

Just stumbled across it while reviewing PR 719
(https://github.com/openjdk/jfx/pull/716)

- added the new test method to see it fail (which it does)
- run all control tests throws the error below in _unrelated_ tests
(the one below is from TableCellTest, that is the same test the new
failing method resides in, but seeing similar in other tests that use
Toolkit.firePulse)

Still happens after a clean build from gradle (clean, sdk, :controls:test).

Any idea what might be the reason?

java.lang.AssertionError: validation of PGGroup children failed
at
javafx.graphics@19-internal/javafx.scene.Parent.validatePG(Parent.java:243)
at
javafx.graphics@19-internal/javafx.scene.Parent.doUpdatePeer(Parent.java:201)
at
javafx.graphics@19-internal/javafx.scene.Parent$1.doUpdatePeer(Parent.java:109)
at
javafx.graphics@19-internal/com.sun.javafx.scene.ParentHelper.updatePeerImpl(ParentHelper.java:78)
at
javafx.graphics@19-internal/com.sun.javafx.scene.layout.RegionHelper.updatePeerImpl(RegionHelper.java:72)
at
javafx.graphics@19-internal/com.sun.javafx.scene.NodeHelper.updatePeer(NodeHelper.java:103)
at javafx.graphics@19-internal/javafx.scene.Node.syncPeer(Node.java:715)
at
javafx.graphics@19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2397)
at
javafx.graphics@19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406)
at
javafx.graphics@19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406)
at
javafx.graphics@19-internal/javafx.scene.Scene$ScenePulseListener.syncAll(Scene.java:2406)
at
javafx.graphics@19-internal/javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2373)
at
javafx.graphics@19-internal/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2529)
at
javafx.graphics@19-internal/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:405)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:389)
at
javafx.graphics@19-internal/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:404)
at
javafx.graphics@19-internal/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:434)
at
test.javafx.scene.control.TableCellTest.testEditCancelEventAfterModifyItems(TableCellTest.java:557)

 

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2]

[Kevin Rushforth]

On Wed, 19 Jan 2022 11:30:10 GMT, Abhinay Agarwal  wrote:

>> Release Notes for 17.0.2
>
> Abhinay Agarwal has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Fix formatting

The list of bugs fixed looks correct, with the addition of the following 
security fix:


JDK-8272546 (not public) | Better TrueType font loading | graphics


See 
[release-notes-17.md](https://github.com/openjdk/jfx17u/blob/master/doc-files/release-notes-17.md#list-of-security-fixes)
 for an example of how we include security fixes.

Additionally, one comment left inline below.

doc-files/release-notes-17.0.2.md line 17:

> 15: [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638)|Update 
> copyright header for files modified in 2021|other
> 16: [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413)|FX: 
> Update copyright year in docs, readme files to 2022|other
> 17: [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396)|Define 
> version in .jcheck/conf|other

We normally exclude `Task`s along with build and test changes from the release 
notes.

-

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2 [v2]

[Abhinay Agarwal]

> Release Notes for 17.0.2

Abhinay Agarwal has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix formatting

-

Changes:
  - all: https://git.openjdk.java.net/jfx17u/pull/28/files
  - new: https://git.openjdk.java.net/jfx17u/pull/28/files/824c5fcd..267df8a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx17u=28=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx17u=28=00-01

  Stats: 23 lines in 1 file changed: 0 ins; 2 del; 21 mod
  Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28

PR: https://git.openjdk.java.net/jfx17u/pull/28

Re: [jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2

[Abhinay Agarwal]

On Wed, 19 Jan 2022 10:58:54 GMT, Abhinay Agarwal  wrote:

> Release Notes for 17.0.2

doc-files/release-notes-17.0.2.md line 18:

> 16: | [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638) | 
> Update copyright header for files modified in 2021  | other|
> 17: | [JDK-8274413](https://bugs.openjdk.java.net/browse/JDK-8274413) | FX: 
> Update copyright year in docs, readme files to 2022 | other|
> 18: | [JDK-8279396](https://bugs.openjdk.java.net/browse/JDK-8279396) | 
> Define version in .jcheck/conf  | other|

Hi @kevinrushforth ,

Can you confirm if issues like this needs to be in the release note. The issue 
itself is labelled as `noreg-cleanup`, however, the backport issue for 
openjfx17.0.1 doesn't have any such label.

-

PR: https://git.openjdk.java.net/jfx17u/pull/28

[jfx17u] RFR: 8280172: Create release notes for JavaFX 17.0.2

[Abhinay Agarwal]

Release Notes for 17.0.2

-

Commit messages:
 - 8280172: Create release notes for JavaFX 17.0.2

Changes: https://git.openjdk.java.net/jfx17u/pull/28/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=28=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280172
  Stats: 33 lines in 1 file changed: 33 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx17u/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/28/head:pull/28

PR: https://git.openjdk.java.net/jfx17u/pull/28