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