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.
Related
I faced this issue many a times while working with a new setup or after a Java upgrade. Logical solution for this? Except replacing jvm.dll file?
Never realized, but the solution is quite easy. As per my understanding:
Observations:
If you are using a 64bit Windows system, then you would notice that there are two Program Files folder in your C:/ Drive.
That means, Program Files, which contains 64-bit programs and applications, and. Program Files (x86), which contains 32-bit programs and applications.
Now if you are using a 64bit system, then it is easy and recommended that you use softwares as well of 64bit. So your Path in System variables should contain the path details of your Java 64bit.
Now coming back to the original problem, here if we are on 64Bit Microsoft Windows system and wish to use 64bit Software (Eclipse for example), then let us set the Path for the 64bit Java.
Then make a simple test on command prompt.
-cmd
-java -version
Shows the 64bit Java VM is set to path.
Now Open your Eclipse and it do not show the Error.
Always remember that we should use:
64 bit OS
64 bit Java (with Path set for 64 bit Java)
64 bit Eclipse.
Hello im trying to use in a Project a dll generated with JNI.
i generated a 64 Bit dll but my project says %1 is not a valid win32 application
So i decided to generate a new DLL, but this time 32 Bit. I changed the Settings in my Visual Studio like i found i other posts, Configuration to Win32 and Target Machine to MachineX86.
this all works fine but when i try to launch the project with this DLL i get the same error. I checked the DLL with Dependency Walker and found out the DLL is 32Bit, but the included DLL's are 64 Bit.
So you guys are my last hope. Do you have any ideas ?
Notes: i can't change to Linux atm.
Visual Studio 2012
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
just read it but i already found my error, the problem was that eclipses changes it's installed JRE's when you switch workspace.
so in my testprogramm where i developed my 64bit libary worked. but not in the real project, where the installed JRE was a different one.
so if anyone has the same problem don't forget to check this
Please check your system PATH. Windows will attempt to load the first DLL it finds that matches the DLL's name. Windows doesn't check if the DLL is 32 or 64-bit, it will attempt to load it.
If you built a 32-bit DLL, then you're responsible for making sure that any dependent DLL is also 32-bit, and that Windows finds those 32-bit DLL's first.
I have a java applet, which doesn't run on 64bit systems (browsers & OS are 64Bit) but works perfectly fine on 32bit Client systems. Why the applet fails to execute on 64Bit client system ?
There is no such thing as 32-bit Java applet.
Java sources are compiled into byte code which does not have a "property" of 32 bit or 64 bit. Only the JVM has variants of 32 bit or 64 bit.
So as long as your applet only contains Java code (and no native libraries), it should run on both 32 bit and 64 bit JVM's no matter what you used to compile your sources.
1: If the applet is pure Java (i.e. no native code), then it does not matter "for which" CPU it was compiled, because there's no machine code. Java bytecode is fully portable — it only requires that you have a JVM not older that was the target while compiling.
2: Your error is about missing "Application-Name manifest attribute" as your log says, this is not related to CPU architecture, and this applet won't work on x86_64, too.
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.