This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
On Windows7 64bit, running: Product Version: NetBeans IDE 7.0 (Build 201104080000) Java: 1.6.0_25; Java HotSpot(TM) 64-Bit Server VM 20.0-b11 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb) Userdir: C:\nb-test\userdir1 Installed plugin from internal UC as Petr Somol stated. Created simple JavaFX class, ran, got the error below. Tried installing stand-alone JavaFX SDK as well and that didn't fix the problem. run: Error: failed to msvcr100.dll java.lang.UnsatisfiedLinkError: C:\nb-test\userdir1\lib\javafx2-win\bin\msvcr100.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform *** Fallback to Prism SW pipeline java.lang.UnsatisfiedLinkError: C:\nb-test\userdir1\lib\javafx2-win\bin\mat.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1807) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703) at java.lang.Runtime.load0(Runtime.java:770) at java.lang.System.load(System.java:1003) at com.sun.glass.utils.NativeLibLoader.loadLibraryFullPath(NativeLibLoader.java:146) at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:85) at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:30) at com.sun.glass.ui.Platform$1.run(Platform.java:32) at java.security.AccessController.doPrivileged(Native Method) at com.sun.glass.ui.Platform.DeterminePlatform(Platform.java:30) at com.sun.glass.ui.PlatformFactory.getPlatformFactory(PlatformFactory.java:19) at com.sun.glass.ui.Application.Run(Application.java:34) at com.sun.javafx.tk.quantum.QuantumToolkit.startup(QuantumToolkit.java:233) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:30) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:64) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:16) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:42) at java.lang.Thread.run(Thread.java:662) BUILD STOPPED (total time: 16 seconds)
Created attachment 108286 [details] log file
Looks related to http://javafx-jira.kenai.com/browse/RT-12198
Possible workaround: when launching the application pass system property java.library.path List of paths to search when loading libraries according to the 32 or 64 nature of the JVM configured in the platform manager (if determination of this is possible before launching). We could pack the FX lib in a following way: lib/jfxr.jar lib/32/bin/ -- 32 bit dlls lib/64/bin/ -- 64 bit dlls and put the value "./32/bin" or "./64/bin" respectively as the value of the system property (or compute the full path to those instead of having dot as the first element in the path). The fx code loading the dlls as ../bin/<something> might work in such case (going from 32/bin back to 32/bin) if such code is used n the fx code. To find out the version of the running JVM one can use (copy pasted from googling around): Sun has a Java System property to determine the bitness of the JVM: 32 or 64: sun.arch.data.model=32 // 32 bit JVM sun.arch.data.model=64 // 64 bit JVM You can use System.getProperty("sun.arch.data.model") to determine if its 32/64 from the program This should be possible to find out even in ant (provided that it works).
You are right with the proposed structure however this scenario must be supported by NativeLoader class inside FX Runtime. The workaround passing java.library.path does not work for me as the NativeLoader makes its own decision how to load the DLLs. Advantage of the proposed fix in http://javafx-jira.kenai.com/browse/RT-12198 is transparent execution of the applications on 64bit systems - no matter if actual executing JRE is 32bit or 64bit.
Actually this is fixed by Adam's workaround and works in our build #168 done by Petr. Can we close it?
Petre, can we close this report? The corresponding JIRA issue has been marked as fixed so I think we can close this one as well, ok?
Petr confirmed. Resolving issue.