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.
Related
I just create a simple GUI java program in my ubuntu. I want to make JAR file from my ubuntu that can be executed on a 32 bit or a 64 bit windows. I have java8 installed in my ubuntu and i'm using netbeans as an IDE. is it really possible to compile a 32 bit jar file in a 64 bit OS.?
Compiled java class files are platform independent, so they will run on both x32 and x64 machines. The JVM is the one that defines used architecture.
Jar files have no 32-bit or 64-bit distinction. The JRE that runs them can be 32-bit or 64-bit, but that has nothing to do with the Java bytecode.
If you're not using any native code, then your jar file will work just fine on both platforms.
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.
I export try.jar file using 32 bit java libraries. On the client site, I have 64 bit java libraries. Can try.jar behave 64 bit executable?
For example, I have
Runtime rt = Runtime.getRuntime();
s = rt.exec("someExecutable");
the someExecutable binary is in 64 bit and using this code with 32 bit java libraries seems to be not working.
My soln' to this problem is to export try.jar using 32 bit java libraries (because my enviroment is in 32 bit) and run try.jar using 64 bit libraries in the client site.
Is this approach correct or any other suggestions?
when I run someExecutable directly (no java involved) which is 64 bit on the client site It works fine (client site is also 64 bit.).
But when I use s = rt.exec("someExecutable"); It doesnt work. the java libraries (jre executables downloaded over java.sun.com) are now 32 bit at both client and development sites.
Do my problem resolve if I install 64 bit libs to client site but not on development site??
Java librairies aren't the problem here. If you want to exec someExecutable, this program must be in 32 bits for a 32bit environment.
Java libraries aren't 32 or 64 bit, they are in Java ByteCode. So they can be executed on any JVM 64 or 32 the exact same way.
You will need a someExecutable binary available on the operating system architecture you wish to run your program on.
This isn't actually anything to do with Java - all Java is doing is going to the underlying operating system and trying to run the command in the String you pass to Runtime.exec().
What's the problem you get when do that?, if you're using 100% java code, JRE should transparents all other things.