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.
Related
I have a Java project running under windows. It uses several native functions from a .DLL file via JNI. Everything works well under 32bit windows.
In order to support 64bit windows, I need to deal with the following questions first:
Can I load a 32bit DLL under 32bit VM in 64bit windows?
Can I load a 32bit DLL under 64bit VM in 64bit windows?
Can I load a 64bit DLL under 32bit VM in 64bit windows?
How can I know which DLL file to load?
Thank you very much!
A 64-bit OS can run a 32-bit or 64-bit application.
A 32-bit application can only load 32-bit DLL or shared libraries.
A 64-bit application can only load 64-bit DLL or shared libraries.
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 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).
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.