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>
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>:
> >
> > 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>
> > 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
> >>>
> >>> 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
> >>>>
> >>
> >>
> >
> > --
>
>
