'Re: Running JavaFX-11 applications from within Eclipse fails'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Running JavaFX-11 applications from within Eclipse fails
From:       Tom Schindl <tom.schindl () bestsolution ! at>
Date:       2018-11-12 12:32:30
Message-ID: 8fec3b14-d310-debb-476d-c99de207115d () bestsolution ! at
[Download RAW message or body]

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 <nlisker@gmail.com
> <mailto:nlisker@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.schindl@bestsolution.at <mailto:tom.schindl@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.pereda@gluonhq.com <mailto:jose.pereda@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.rushforth@oracle.com <mailto:kevin.rushforth@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.schindl@bestsolution.at <mailto:tom.schindl@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


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic