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.
Summary: | 64 bit JVMs not supported by NetBeans modules for JavaFX 2.0 | ||
---|---|---|---|
Product: | javafx | Reporter: | John Jullion-ceccarelli <johnjullion> |
Component: | Deployment | Assignee: | Anton Chechel <manowar> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dstrupl, manowar, psomol |
Priority: | P2 | ||
Version: | 7.0.1 | ||
Hardware: | PC | ||
OS: | Other | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 199283 | ||
Attachments: | log file |
Description
John Jullion-ceccarelli
2011-05-13 21:19:42 UTC
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. |