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.

-- 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.rushfo...@oracle.com <mailto:kevin.rushfo...@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.rushfo...@oracle.com
    <mailto:kevin.rushfo...@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.hr...@gmail.com <mailto:steve.hr...@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.rushfo...@oracle.com
    <mailto:kevin.rushfo...@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.hr...@gmail.com <mailto:steve.hr...@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
        >>



Reply via email to