I am new to JOGL. I use Eclipse and I imported JOGL jar and dll (yes, Windows OS). But, when I was searching for JOGL libraries, I downloaded 32 bit version. I have 64 bit OS, but since I can run 32 bit apps I thought it will still be more suitable. But compiler is complaining: Can't load IA 32-bit .dll on a AMD 64-bit platform
Well, first, I thought Java itself is NOT separated by architecture. Yes, I know I am using native libraries to link into Windows OpenGL interface (API), but I just want to include these code snippets into java bytecode, so why compiler cant let me use 32 bit ones? Thanks.
Since you have a 64-bit OS, you installed the 64-bit JVM. The 64-bit JVM cannot use the 32-bit DLLs, so you'll need to either download the 64-bit ones, or alternatively, install the 32-bit JVM on your system and set Eclipse to use that JVM instead.
64bit JVM cannot load 32bit libraries. You need to start 32b JVM to make it work (or get 64b dlls).
Related
I want to load native library to Java program, which is fine but I don't know which architecture should I load. If I'm running on x64 and I have a x64 JVM I will load 64 bit library but If I will run on x86 JVM on x64 what I should load ? It should be based on OS or JVM ?
Thank you
The "bitness" of the native library must be the same as that of the JVM.
If you are using a 32-bit JVM, you need a 32-bit native library (no matter if the OS is 32-bit or 64-bit).
If you are using a 64-bit JVM, you need a 64-bit native library.
I have been working in Java for past 8 months. Currently I am using JNA to load a third party DLL and it works fine on 32bit WinXP and 32bit Win7 machines.
On a 64bit Win7 machine, this third party dll is present under C:\Program Files(x86), I assume this means its a 32 bit DLL. So, here is the configuration I used so far,
Win7 machine - 64 bit,
Third party dll - 32 bit (as per above mentioned assumption),
JRE - tried with both 32bit and 64bit
But I get the following - "error: java.lang.UnsatisfiedLinkError: Unable to load library 'Wrapper': The specified module could not be found."
Please let me know if JNA supports loading a 32bit DLL, using a 32 bit JRE on a 64bit machine. Also, if this 32bit DLL has dependencies on other 32 & 64 bit DLLs would JNA still support it.
I am going to use procexp to find out if I am missing any dependencies. I will update this post accordingly.
Please provide your expert advise. Thanks in advance !
JNA does support loading 32 bit DLLs on a 64bit machine. But we need a 32 bit JVM to do this.
I was using Platform.is64Bit() to determine the path of the DLL. I learnt that this method returns the configuration of the JVM and not the OS.
So, in my case when I was using 32bit VM on 64bit machine, the path to the DLL was wrong.
Earlier this year I code Java GUI to work in Matlab environment for image acquisition purposes. I was able to call Java_Gui.jar inside the matlab, as well as to use some of the classes from the .jar file. The GUI was tested on WinXP 32bit, and Matlab2006b and Matlab 2008a. Matlab code for calling Java classes:
clc,clear all,close all
javaaddpath('C:\Users\...\JavaGUI.jar');
JavaGUI.main([]);
pause(1)
JavaGUI.main2();
However, when tried same program with Win7 on 64bit and Matlab2011a the familiar problem occurred:
??? Java exception occurred:
java.lang.UnsatisfiedLinkError: no sserial in java.library.path
Any idea why is this happening? Maybe I should compile my jar file on 64bit version?
The code is still working on 32bit Win, just checked it.
ANSWER: Works with 32-bit version of Matlab on 64-bit Windows 7!
Probably your JAR uses JNI.
JNI won't be able to load into a process of a different bitness than the DLL containing the native portions. You'd need a 64-bit version of the library (the Java code is no different, the native DLLs are) in that case.
The problem is that you are using a library in java that makes calls to a native library for which you need the 64-bit version in order to run it in the 64 bit JRE. You need to either switch to a 32 bit version of Matlab, or track down the library that makes native calls to sserial and update to the 64 bit version for 64 bit systems.
I would know if is possible compile a java desktop application in 32bit application
from Windows 7 64bit using Netbeans.
Thx you for HELP.
You don't have to build java code for 32-bit or 64-bit platforms. The code is compiled to byte code which is run by JVM. You can use 32-bit or 64-bit JVM to run your java code.
The only exception is native libraries that you might be using in your code. If there are any then you will have to manually compile those for the respective platform. Otherwise the java code is totally portable across 32-bit and 64-bit platforms.
Write once and run everywhere :-)
Java doesn't build 32-bit or 64-bit applications - bytecode is portable across architectures.
If you rely on any native libraries, you'd have to potentially ship both versions of those - but the actual Java code won't need to be recompiled.
I have installed 64 bits RHEL. I have following questions regarding ant.jar for the system.
I was not able to find ant.jar build with 64 bit JVM from the apache website. Do I have to build it form the source code, if I intend to run the jar on 64 bit JVM?
Would it speed up the build process if I use ant.jar build with 64 bit JVM and run it on 64 bit JVM?
You do not need a special 64 bit build of a pure Java application such as Ant. The ant.jar will run equally on a 32 bit or 64 bit JVM.
The only cases where you would definitely need to run a 64 bit version of a Java application are:
when the application includes native code libraries; i.e. the application is not pure Java, or
when the Java application has been compiled directly to native code; e.g. using gcj.
(It is possible that a poorly written application will be operating system dependent. For example, someone could hard code an application to use OS-specific line separators or pathnames, or to rely on specific OS-specific external commands. But the chances are that even this won't make the application dependent on the OS memory model.)
No, java bytecode is java bytecode, it doesn't matter whether it was built with a 32-bit or 64-bit JDK.
For the same reason, it doesn't matter which operating system it was built on either. For example: a jar built with a 32-bit JDK on 32-bit Microsoft Windows should run just fine on a 64-bit JRE on 64-bit RHEL.