NativeLibLoader - installLibraryFromResource - RuntimeImage

Kevin Rushforth kevin.rushforth at oracle.com
Fri Jul 27 15:38:25 UTC 2018


> Unless you want to maintain a LTS release of OpenJFX in addition to 
> the “current” version?

I think that's what Johan was talking about with Gluon's "JavaFX 
Enterprise support".

-- Kevin


On 7/27/2018 8:07 AM, Scott Palmer wrote:
>
>> On Jul 27, 2018, at 10:49 AM, Kevin Rushforth 
>> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>>
>> Those are all excellent points. This suggests we might want to adopt 
>> a general policy of "the current OpenJFX dev works with the latest 
>> released OpenJDK plus the current OpenJDK under development" is the 
>> better way to go. Otherwise it will be several years before OpenJFX 
>> can adopt, say, a new JDK 12 or JDK 13 feature.
>>
>> I note that this matches the model and spirit of the OpenJDK 
>> development. If you want to get the latest and greatest features, use 
>> the latest feature release. If you want stability, use a supported 
>> LTS release. Makes sense to me.
>
>
> Which can be much easier said than done.  I generally like to live 
> near the bleeding edge… I *want to switch*, but we are still stuck on 
> Java 8 (like I suspect most companies are) because of the very 
> significant development effort to move to Java 9 or beyond.  Java 9 
> module's access controls were one thing, Java 11’s removal of some 
> modules and development tools further broke the world.  Not to mention 
> that good module support in the tool chain is still not available. We 
> are waiting for the dust to settle, we need to wait for many 
> dependencies and tools to catch up and become Java 11 compatible, then 
> we have to try to migrate our own code and hope that all the 
> dependency upgrades didn’t break things.  Basically we won’t even be 
> able to start to migrate our code beyond Java 8 until next year (when 
> Java 8 LTS ends).
>
> I’ve already spent days trying to get code to build with Java 11 
> (unsuccessfully). It’s the first time in the history of Java that I 
> haven’t been able to upgrade the JRE with trivial effort.  Usually the 
> only thing holding me back was waiting for Proguard to support the new 
> class version. (And I could at least develop and test without 
> obfuscation until it was ready.)
>
> I am hoping that once we make the leap from Java 8 to Java 11, that 
> further updates will be less painful.  If so, then I could agree that 
> the latest OpenJFX can use the latest released JRE.
>
> Unless you want to maintain a LTS release of OpenJFX in addition to 
> the “current” version?
>
> Scott
>
>
>>
>> -- Kevin
>>
>>
>> On 7/27/2018 7:35 AM, Johan Vos wrote:
>>> I think we have to distinguish between the technical work done by 
>>> OpenJFX and the distributions/support offered by companies; similar 
>>> to the technical work in OpenJDK and the distributions/support 
>>> offered by Oracle and others.
>>>
>>> The technical work done here should imo be able to use all 
>>> functionality offered by the latest released JDK (11/12/...)
>>>
>>> I don't think there is a good reason on why the head-development of 
>>> OpenJFX can not use the latest JDK release. If developers/companies 
>>> want to switch to the latest and greatest OpenJFX release, they can 
>>> also upgrade to the latest released OpenJDK.
>>>
>>> And if there are company rules preventing this, well, that is a 
>>> reason to consider commercial support.
>>> I don't like to use my commercial hat in this list, but this is why 
>>> we have JavaFX Enterprise support with Gluon: 
>>> https://gluonhq.com/commercial-support-for-javafx/
>>> Also, not that it is relevant on this list, but the revenues from 
>>> commercial enterprise support allow us to spend resources on working 
>>> on OpenJFX.
>>>
>>> - Johan
>>>
>>> On Fri, Jul 27, 2018 at 4:12 PM Kevin Rushforth 
>>> <kevin.rushforth at oracle.com 
>>> <mailto:kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com>> 
>>> wrote:
>>>
>>>    Hi Steve,
>>>
>>>
>>>>    I don't know if this discussion already comes up but I didn't
>>>>    found any related answers.
>>>>    Is there a self-defined goal about the compability of versions
>>>>    OpenJFX and the OracleJDK LTS versions?
>>>>    E.g. OpenJFX will be compatible to OracleJDK 11 until the next
>>>>    LTS version of Oracle will be released
>>>
>>>    That's an excellent question. While I might expect OpenJFX 12 to
>>>    stop running on JDK 10 at some point (JDK 10 is EOLed by JDK 11,
>>>    and dropping support for it would allow us to get rid of the old
>>>    swing interop implementation and build logic), having it run on
>>>    JDK 11 is a requirement: At a minimum we will need to run on the
>>>    latest released version at any point, since we are no longer
>>>    bundled. Beyond that, it's up for discussion among the OpenJFX
>>>    community: I can see value in allowing, say, OpenJFX 13 or 14 to
>>>    continue to run with JDK 11 LTS, but there is also a cost to doing
>>>    so, both in terms of testing and also in either avoiding new JDK
>>>    features or using reflection or other techniques to optionally use
>>>    them.
>>>
>>>    What do others think?
>>>
>>>
>>>    -- Kevin
>>>
>>>
>>>
>>>    On 7/27/2018 6:43 AM, Steve Hruda wrote:
>>>>    Hi Kevin,
>>>>    at the moment it's not really a use-case. I didn't used the jmods
>>>>    because I test if the maven artifacts could easier our life in
>>>>    case of maintaining different product versions.
>>>>    I love the easy distribution of the maven artifacts across
>>>>    different machines (developers & build servers).
>>>>
>>>>    But so far I'm not sure if I the maven artifacts bring me a real
>>>>    benefit compared to the jmod's.
>>>>
>>>>    Off-Topic:
>>>>    I don't know if this discussion already comes up but I didn't
>>>>    found any related answers.
>>>>    Is there a self-defined goal about the compability of versions
>>>>    OpenJFX and the OracleJDK LTS versions?
>>>>    E.g. OpenJFX will be compatible to OracleJDK 11 until the next
>>>>    LTS version of Oracle will be released
>>>>
>>>>    Best Regards,
>>>>    Steve
>>>>    Kevin Rushforth <kevin.rushforth at oracle.com 
>>>> <mailto:kevin.rushforth at oracle.com>
>>>>    <mailto:kevin.rushforth at oracle.com>> schrieb am Do., 26. Juli
>>>>    2018, 14:42:
>>>>
>>>>        Hi Steve,
>>>>
>>>>        Seems it will be an easy bug for Johan to fix, but I'm
>>>>        curious about how
>>>>        you created your custom image. The jmods are more suitable
>>>>        for that
>>>>        approach, since their purpose is to be used with jlink to
>>>>        create a
>>>>        custom image, in which case the native libraries will be
>>>>        linked into the
>>>>        image. Maybe I'm missing some use case, though.
>>>>
>>>>        -- Kevin
>>>>
>>>>
>>>>        On 7/26/2018 2:46 AM, Johan Vos wrote:
>>>>        > Hi Steve,
>>>>        >
>>>>        > That looks like a bug. The libPrefix and libSuffix are
>>>>        indeed not set in
>>>>        > cases where usingModules is true, which is only the case
>>>>        when the jrt
>>>>        > protocol is used.
>>>>        > It seems to me the prefix/suffix should always be computed.
>>>>        It doesn't look
>>>>        > right that they are computed inside the
>>>>        loadLibraryFullPath. But it looks
>>>>        > even worse that the "reallib" is calculated based on
>>>>        statements that might
>>>>        > not be reached, where it could have used
>>>>        System.mapLibraryName()
>>>>        >
>>>>        > I'll create an issue and a PR to fix this.
>>>>        >
>>>>        > Thanks for reporting,
>>>>        >
>>>>        > - Johan
>>>>        >
>>>>        >
>>>>        > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda
>>>>        <steve.hruda at gmail.com 
>>>> <mailto:steve.hruda at gmail.com><mailto:steve.hruda at gmail.com>> wrote:
>>>>        >
>>>>        >> Hi,
>>>>        >> I created a custom runtime image (windows x64) for my
>>>>        JavaFX application
>>>>        >> and used the OpenJFX 11-ea+19 maven artifacts.
>>>>        >>
>>>>        >> I get the following exception if I try to execute my
>>>>        application:
>>>>        >>
>>>>        >> 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
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222)
>>>>        >>          at
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
>>>>        >>          at
>>>>        >>
>>>>        java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>        >> Method)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>        >>          at
>>>>        java.base/java.lang.reflect.Method.invoke(Method.java:564)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941)
>>>>        >> Caused by: java.lang.RuntimeException: Error initializing
>>>>        QuantumRenderer:
>>>>        >> no suitable pipeline found
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
>>>>        >>          at java.base/java.lang.Thread.run(Thread.java:844)
>>>>        >> Exception in thread "main"
>>>>        java.lang.reflect.InvocationTargetException
>>>>        >>          at
>>>>        >>
>>>>        java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>        >> Method)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>        >>          at
>>>>        java.base/java.lang.reflect.Method.invoke(Method.java:564)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941)
>>>>        >> Caused by: java.lang.RuntimeException: No toolkit found
>>>>        >>          at
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
>>>>        >>          ... 5 more
>>>>        >>
>>>>        >>
>>>>        >> -Djavafx.verbose=true shows that JavaFX isn't able to load
>>>>        the native libs
>>>>        >> from the javafx-graphics jar.
>>>>        >>
>>>>        >>
>>>>        >> I debugged the NativeLibLoader and 
>>>> loadLibraryFromResource and
>>>>        >> installLibraryFromResource will be executed which is ok.
>>>>        But the
>>>>        >> *reallib *value for
>>>>        >> all dll's is wrong because of the empty *libSuffix*.
>>>>        >>
>>>>        >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is
>>>>        >> */api-ms-win-core-console-l1-1-0* and not
>>>>        >> */api-ms-win-core-console-l1-1-0.dll*
>>>>        >>
>>>>        >> Is it intentional that *libPrefix *& *libSuffix *will not
>>>>        be set in case of
>>>>        >> the jrt protocol ?
>>>>        >>
>>>>        >>
>>>>        >>
>>>> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >>
>>>> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >> Best Regards,
>>>>        >> Steve
>>>>        >>
>>>>
>>>>
>>>>    Kevin Rushforth <kevin.rushforth at oracle.com 
>>>> <mailto:kevin.rushforth at oracle.com>
>>>>    <mailto:kevin.rushforth at oracle.com>> schrieb am Do., 26. Juli
>>>>    2018, 14:42:
>>>>
>>>>        Hi Steve,
>>>>
>>>>        Seems it will be an easy bug for Johan to fix, but I'm
>>>>        curious about how
>>>>        you created your custom image. The jmods are more suitable
>>>>        for that
>>>>        approach, since their purpose is to be used with jlink to
>>>>        create a
>>>>        custom image, in which case the native libraries will be
>>>>        linked into the
>>>>        image. Maybe I'm missing some use case, though.
>>>>
>>>>        -- Kevin
>>>>
>>>>
>>>>        On 7/26/2018 2:46 AM, Johan Vos wrote:
>>>>        > Hi Steve,
>>>>        >
>>>>        > That looks like a bug. The libPrefix and libSuffix are
>>>>        indeed not set in
>>>>        > cases where usingModules is true, which is only the case
>>>>        when the jrt
>>>>        > protocol is used.
>>>>        > It seems to me the prefix/suffix should always be computed.
>>>>        It doesn't look
>>>>        > right that they are computed inside the
>>>>        loadLibraryFullPath. But it looks
>>>>        > even worse that the "reallib" is calculated based on
>>>>        statements that might
>>>>        > not be reached, where it could have used
>>>>        System.mapLibraryName()
>>>>        >
>>>>        > I'll create an issue and a PR to fix this.
>>>>        >
>>>>        > Thanks for reporting,
>>>>        >
>>>>        > - Johan
>>>>        >
>>>>        >
>>>>        > On Thu, Jul 26, 2018 at 11:03 AM Steve Hruda
>>>>        <steve.hruda at gmail.com 
>>>> <mailto:steve.hruda at gmail.com><mailto:steve.hruda at gmail.com>> wrote:
>>>>        >
>>>>        >> Hi,
>>>>        >> I created a custom runtime image (windows x64) for my
>>>>        JavaFX application
>>>>        >> and used the OpenJFX 11-ea+19 maven artifacts.
>>>>        >>
>>>>        >> I get the following exception if I try to execute my
>>>>        application:
>>>>        >>
>>>>        >> 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
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222)
>>>>        >>          at
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
>>>>        >>          at
>>>>        >>
>>>>        java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>        >> Method)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>        >>          at
>>>>        java.base/java.lang.reflect.Method.invoke(Method.java:564)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941)
>>>>        >> Caused by: java.lang.RuntimeException: Error initializing
>>>>        QuantumRenderer:
>>>>        >> no suitable pipeline found
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
>>>>        >>          at java.base/java.lang.Thread.run(Thread.java:844)
>>>>        >> Exception in thread "main"
>>>>        java.lang.reflect.InvocationTargetException
>>>>        >>          at
>>>>        >>
>>>>        java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>        >> Method)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>        >>          at
>>>>        java.base/java.lang.reflect.Method.invoke(Method.java:564)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:941)
>>>>        >> Caused by: java.lang.RuntimeException: No toolkit found
>>>>        >>          at
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:263)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:157)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>>        javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
>>>>        >>          at
>>>>        >>
>>>>        >>
>>>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
>>>>        >>          ... 5 more
>>>>        >>
>>>>        >>
>>>>        >> -Djavafx.verbose=true shows that JavaFX isn't able to load
>>>>        the native libs
>>>>        >> from the javafx-graphics jar.
>>>>        >>
>>>>        >>
>>>>        >> I debugged the NativeLibLoader and 
>>>> loadLibraryFromResource and
>>>>        >> installLibraryFromResource will be executed which is ok.
>>>>        But the
>>>>        >> *reallib *value for
>>>>        >> all dll's is wrong because of the empty *libSuffix*.
>>>>        >>
>>>>        >> e.g. the reallib value of *api-ms-win-core-console-l1-1-0* is
>>>>        >> */api-ms-win-core-console-l1-1-0* and not
>>>>        >> */api-ms-win-core-console-l1-1-0.dll*
>>>>        >>
>>>>        >> Is it intentional that *libPrefix *& *libSuffix *will not
>>>>        be set in case of
>>>>        >> the jrt protocol ?
>>>>        >>
>>>>        >>
>>>>        >>
>>>> https://github.com/javafxports/openjdk-jfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L308
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >>
>>>> https://github.com/javafxports/openjdkjfx/blob/c168ab56accd7e74d53737bc0832495dbc318e52/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java#L338
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >>
>>>>        >> Best Regards,
>>>>        >> Steve
>>>>        >>
>



More information about the openjfx-dev mailing list