Re: NativeLibLoader - installLibraryFromResource - RuntimeImage

Fri, 27 Jul 2018 08:40:48 -0700
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 
<[email protected] <mailto:[email protected]>> 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 
<[email protected] 
<mailto:[email protected]><mailto:[email protected]>> 
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 <[email protected] 
<mailto:[email protected]>

   <mailto:[email protected]>> 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

       <[email protected] 
<mailto:[email protected]><mailto:[email protected]>> 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 <[email protected] 
<mailto:[email protected]>

   <mailto:[email protected]>> 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

       <[email protected] 
<mailto:[email protected]><mailto:[email protected]>> 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