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.

Bug 198599 - 64 bit JVMs not supported by NetBeans modules for JavaFX 2.0
Summary: 64 bit JVMs not supported by NetBeans modules for JavaFX 2.0
Alias: None
Product: javafx
Classification: Unclassified
Component: Deployment (show other bugs)
Version: 7.0.1
Hardware: PC Other
: P2 normal (vote)
Assignee: Anton Chechel
Depends on:
Blocks: 199283
  Show dependency tree
Reported: 2011-05-13 21:19 UTC by John Jullion-ceccarelli
Modified: 2011-06-30 13:51 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

log file (40.79 KB, application/octet-stream)
2011-05-13 21:40 UTC, John Jullion-ceccarelli

Note You need to log in before you can comment on or make changes to this bug.
Description John Jullion-ceccarelli 2011-05-13 21:19:42 UTC
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.

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(
	at java.lang.ClassLoader.loadLibrary(
	at java.lang.Runtime.load0(
	at java.lang.System.load(
	at Method)
	at com.sun.javafx.application.PlatformImpl.startup(
	at com.sun.javafx.application.LauncherImpl.launchApplication1(
	at com.sun.javafx.application.LauncherImpl.access$000(
	at com.sun.javafx.application.LauncherImpl$
BUILD STOPPED (total time: 16 seconds)
Comment 1 John Jullion-ceccarelli 2011-05-13 21:40:28 UTC
Created attachment 108286 [details]
log file
Comment 2 David Strupl 2011-05-13 22:14:19 UTC
Looks related to
Comment 3 David Strupl 2011-05-14 20:09:24 UTC
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/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: // 32 bit JVM // 64 bit JVM

You can use


to determine if its 32/64 from the program

This should be possible to find out even in ant (provided that it works).
Comment 4 Adam Sotona 2011-05-16 07:45:29 UTC
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 is transparent execution of the applications on 64bit systems - no matter if actual executing JRE is 32bit or 64bit.
Comment 5 Anton Chechel 2011-06-28 13:23:05 UTC
Actually this is fixed by Adam's workaround and works in our build #168 done by Petr.
Can we close it?
Comment 6 David Strupl 2011-06-28 14:44:41 UTC
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?
Comment 7 Anton Chechel 2011-06-30 13:51:59 UTC
Petr confirmed. Resolving issue.