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