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.
Related
Apologies in advance. I know this is a basic question.
I am new to server administration. I am administering a server where the users do Java development.
They have a Java-based application and do development in Eclipse. Eclipse is 32-bit. The OS is 64-bit.
I recently updated the JDK and JRE on the server. I have both the 64-bit and 32-bit of each installed.
Eclipse ran into an error where it couldn't start after I had updated to the new JRE and JDK. So I took some advice online and updated the -vm path in the Eclipse .INI file to point to the new 32-bit JRE path. It now works.
I have two main questions:
Will updating the JRE and JDK EVER cause an issue with development, or as long as they can open up Eclipse and use at least one version of the JRE or JDK, they will be fine? I guess my fear is that they are going to develop in a certain version and the next version will cause issues down the line.
They develop in 32-bit Eclipse (not sure why they chose 32-bit) but their application runs with 64-bit Java (that is where the path points to for that installation). If something is developed in 32-bit Eclipse can it run with 64-bit Java? Side question: is there a certain advantage with developing with 32-bit Eclipse on a 64-bit system or is it personal choice?
Thanks a lot and cheers!
I guess my fear is that they are going to develop in a certain version and the next version will cause issues down the line.
Java 6 and 7 are end of life; Java 8 code should still be run when Java 9+ rolls out. I've not been aware of any backwards compatibility issues in recent years, it's only forward compatibility that doesn't work (running Java 8 compiled libraries with JRE 7).
They develop in 32-bit Eclipse (not sure why they chose 32-bit) but their application runs with 64-bit Java
The IDE and code run in separate processes. There's no harm in using the 64bit JDK with 32bit editor.
Eclipse 32 bits running on 64 bits JVM
Should I use Eclipse 32bits or 64bits on my new machine?
Will updating the JRE and JDK EVER cause an issue with development...
I believe it technically could render what you developed "obsolete" if you're initially using one JDK with some specs and change for another one with specs that are not "compatible" with what you built so far. By specs, I mean the libraries, tools, etc that the JDK contains. But I would say it would be unlikely that such problems occur. It personally never happened to me. I'd like to have someone with more knowledge give more details though and validate what I'm saying or correct me if I'm wrong.
If something is developed in 32-bit Eclipse can it run with 64-bit
Java?
To my knowledge, there are not related things. In my mind, Eclipse is just your IDE and it allows you to build/compile code using specific JDK (32 or 64 bits). As a matter of fact, you don't even need eclipse to build code but you definitely need a JDK: it's the JDK that give you the tools to compile code that "targets" a specific JRE/JVM and Eclipse is using the tools your JDK provide.
So yes, you can use eclipse 32 bits to build code for a 64 bits JRE.
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.
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 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.