Hi,

I never used the relative version but can confirm that you have to set
the library path to the built DLLs

Tom

On 12.11.18 11:41, Nir Lisker wrote:
> I managed to solve my problem. It's actually looking for the dlls, so using
> 
> -Djava.library.path="...\rt\modules\javafx.graphics\build\module-lib"
> 
> will start the application properly. If anyone can confirm this problem
> and solution I'll add this step to the wiki.
> 
> On Wed, Nov 7, 2018 at 6:21 PM Nir Lisker <nlis...@gmail.com
> <mailto:nlis...@gmail.com>> wrote:
> 
>     I have a related problem when developing JavaFX in Eclipse and Win10
>     that started in 11.
> 
>     I created a modular project and in its build configuration (in
>     Eclipse) I added the JavaFX base and graphics projects (that point
>     to rt\modules\...) and OpenJDK11 to the module path.
>     In the module-info file I required the JavaFX modules and exported
>     my package.
> 
>     Compilation is fine, but during runtime (with -Dprism.verbose=true)
>     I get an error:
> 
>     Prism pipeline init order: d3d sw 
>     Using Double Precision Marlin Rasterizer
>     Using dirty region optimizations
>     Not using texture mask for primitives
>     Not forcing power of 2 sizes for textures
>     Using hardware CLAMP_TO_ZERO mode
>     Opting in for HiDPI pixel scaling
>     Prism pipeline name = com.sun.prism.d3d.D3DPipeline
>     Loading D3D native library ...
>     // Error here: //
>     GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline
>     java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path:
>     [see below]
>     at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
>     at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
>     at java.base/java.lang.System.loadLibrary(System.java:1867)
>     at
>     
> javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:150)
>     at
>     
> javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
>     at
>     
> javafx.graphics/com.sun.prism.d3d.D3DPipeline.lambda$0(D3DPipeline.java:48)
>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>     at
>     
> javafx.graphics/com.sun.prism.d3d.D3DPipeline.<clinit>(D3DPipeline.java:44)
>     at java.base/java.lang.Class.forName0(Native Method)
>     at java.base/java.lang.Class.forName(Class.java:315)
>     at
>     
> javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
>     at
>     
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
>     at
>     
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
>     at java.base/java.lang.Thread.run(Thread.java:834)
>     *** Fallback to Prism SW pipeline
>     Prism pipeline name = com.sun.prism.sw.SWPipeline
>     GraphicsPipeline.createPipeline failed for com.sun.prism.sw.SWPipeline
>     java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path:
>     [see below]
>     at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
>     at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
>     at java.base/java.lang.System.loadLibrary(System.java:1867)
>     at
>     
> javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:150)
>     at
>     
> javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
>     at
>     javafx.graphics/com.sun.prism.sw.SWPipeline.lambda$0(SWPipeline.java:42)
>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>     at
>     javafx.graphics/com.sun.prism.sw.SWPipeline.<clinit>(SWPipeline.java:41)
>     at java.base/java.lang.Class.forName0(Native Method)
>     at java.base/java.lang.Class.forName(Class.java:315)
>     at
>     
> javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
>     at
>     
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
>     at
>     
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
>     at java.base/java.lang.Thread.run(Thread.java:834)
>     Graphics Device initialization failed for :  d3d, sw
>     Error initializing QuantumRenderer: no suitable pipeline found
>     // ...
> 
>     The paths listed at the end are those from %PATH% and none point to
>     the development modules. So, I added to the runtime VM args in the
>     launch configuration:
> 
>     -Djava.library.path="...\rt\modules\javafx.graphics\bin"
>     and I also tried with
>     "...\rt\modules\javafx.graphics\bin\com\sun\prism\d3d" because this
>     is where com.sun.prism.d3d.D3DPipeline is.
> 
>     I get the same error. Did anyone encounter this?
> 
>     - Nir
> 
>     On Sun, Nov 4, 2018 at 6:40 PM Tom Schindl
>     <tom.schi...@bestsolution.at <mailto:tom.schi...@bestsolution.at>>
>     wrote:
> 
>         I think the more general problem is that they don‘t run on the
>         module-path - in the m2e case this because the modules are
>         transitive deps and those are not supported properly
> 
>         Tom
> 
>         Von meinem iPhone gesendet
> 
>         > Am 04.11.2018 um 16:17 schrieb José Pereda
>         <jose.per...@gluonhq.com <mailto:jose.per...@gluonhq.com>>:
>         >
>         > I've just noticed that this issue happens not only with Maven
>         but also with
>         > Gradle projects (Gradle + Eclipse 2018-09 + Windows with
>         Oracle JDK 1.8),
>         > running gradle tasks from Eclipse.
>         >
>         > The same proposed workaround can be applied to the build file:
>         >
>         > run {
>         >
>         >    systemProperty "java.library.path", "C:\tmp"
>         >
>         > }
>         >
>         >
>         >
>         >
>         > On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth
>         <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>
>         > wrote:
>         >
>         >>
>         >>> Renaming the native libraries in JavaFX would probably solve
>         this, but
>         >> that
>         >>> seems the wrong solution to me.
>         >>
>         >> Yes, it seems like a workaround rather than a fix...
>         >>
>         >> -- Kevin
>         >>
>         >>
>         >>> On 10/21/2018 10:45 AM, Johan Vos wrote:
>         >>> Hi Tom,
>         >>>
>         >>> Nice workaround, but what do you think needs to be done to
>         fix it? Can
>         >> the
>         >>> java.library.path somehow be changed in a plugin or so?
>         >>> Renaming the native libraries in JavaFX would probably solve
>         this, but
>         >> that
>         >>> seems the wrong solution to me.
>         >>>
>         >>> - Johan
>         >>>
>         >>> On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl
>         <tom.schi...@bestsolution.at <mailto:tom.schi...@bestsolution.at>
>         >>>
>         >>> wrote:
>         >>>
>         >>>> Hi,
>         >>>>
>         >>>> I just wanted to make you aware that if you run a JavaFX-11
>         application
>         >>>> from within Eclipse it is very likely that you'll get an
>         error like
>         >> this.
>         >>>>
>         >>>>> Exception in thread "WindowsNativeRunloopThread"
>         >>>> java.lang.NoSuchMethodError: <init>
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
>         >>>> Method)
>         >>>>>     at
>         >>>>
>         javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>         >>>>>     at
>         >>>>
>         javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>         >> Method)
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>         >>>>>     at java.base/java.lang.Thread.run(Thread.java:834)
>         >>>>> Exception in thread "JavaFX Application Thread"
>         >>>> java.lang.NullPointerException
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>         >>>>>     at
>         >>>>
>         javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>         >> Method)
>         >>>>>     at
>         >>>>
>         >>
>         
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>         >>>>>     at java.base/java.lang.Thread.run(Thread.java:834)
>         >>>> Scary right! The reason is that JavaFX-11 is loading the
>         wrong glass.dll
>         >>>> because Eclipse sets a java.library.path who also contains the
>         >>>> JVM-Directories used to launch your Eclipse IDE.
>         >>>>
>         >>>> The simple work-around is to add
>         >>>> -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
>         >>>> configuration.
>         >>>>
>         >>>> Small tiny question on the side: Wouldn't it make sense to
>         version our
>         >>>> .dlls somehow to match the release eg glass-11.dll?
>         >>>>
>         >>>> Tom
>         >>>>
>         >>>> --
>         >>>> Tom Schindl, CTO
>         >>>> BestSolution.at EDV Systemhaus GmbH
>         >>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>         >>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>         >>>>
>         >>
>         >>
>         >
>         > --
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Reply via email to