1

I had a 64-bit system to build a java project. For now I'm stuck with a 32-bit machine. Will the bytecode be any different using javac x32 versus javac x64. i.e. I need to send a bug fix and I'm not sure I can send a jar file compiled with javac x32 if all the rest of the jars where compiled with x64.

Found this but, I'm still not quite sure.

java-32-bit-vs-64-bit-compatibility

Community
  • 1
  • 1
code-gijoe
  • 6,949
  • 14
  • 67
  • 103
  • 2
    The answer in the link you provided is pretty clear - what are your concerns? The byte code is just platform independent... – home Feb 22 '12 at 17:59
  • My concern is I have some dll/so files which are platform dependent. So why bother having a 64-bit compiler? – code-gijoe Feb 22 '12 at 18:14
  • So it is not just Java (byte) code you have to deploy? Please update your question accordingly! – home Feb 22 '12 at 18:16
  • My fixes are in pure JAVA. But I distributed some x64 dlls with it. This will not be touched in any way. – code-gijoe Feb 22 '12 at 18:18
  • Now it may become fairly complex - no one can answer your question without code analysis. Consider a full integration/system test if you're not sure what you really changed. – home Feb 22 '12 at 18:21
  • I actually do know exactly what is being changed. 2 lines of code in a project which has pretty much nothing to do with the x64 dlls – code-gijoe Feb 22 '12 at 18:32

2 Answers2

4

It should work perfectly fine as was mentioned in the answer you linked Java Bytecode is completely platform independant

Ross
  • 112
  • 1
  • 17
  • Where are the 64-bit dependencies handled then? I have some low level image manipulation (C++ dlls) which are dynamically loaded. How does java cross-talk to 64 bit dll? I'm assuming it will just not work under x32 but will behave perfectly fine in x64. – code-gijoe Feb 22 '12 at 18:16
  • The 64-bit dependencies are all handled within the JVM. The one exception here is that DLLs -- including native code DLLs, cannot cross platform boundaries. If you build a jar file, and include a native DLL for one platform but not the other, it can only use those native functions on that platform. This would be an exceptional case. Pure java code has no x64/x86 dependencies of its own; the byte codes run the same in any JVM -- even completely different hardware. – Bob Kerns Oct 23 '12 at 00:59
1

Like the link and everyone else said: It will be fine.

What may be confusing you is the difference between the JIT compiler and the javac compiler. The JIT compiler is part of the virtual machine - unlike javac - and has different default settings on 32- and 64-bit Windows machines. This will effect performance like execution speed and memory usage when bytecode - compiled by javac - is run, but it doesn't effect compatibility of code compiled by javac. The output of javac with will on any compliant JVM.

Looking at your comments, I think this info might help you, too: Java code invokes .dll/.so s simply with a call to a method with the native modifier, as in public native byte[] doFoo(byte[] img);. Typically, these methods have behavior that is specified to be the same across all systems, and some behavior that is unspecified (see FileChannel). Unless the project you delivered a fix for is really weird, Java almost always is system-agnostic, meaning Java code only deals with system-independent behavior. You should rarely see Java source code that does different things on different system. If you only wrote Java code, your fix should work across all systems that the project is deployed to. But there's no guarantee. Look at the documentation for any classes and methods you used to make sure they fully abstract the operating system from the Java source code.

Mutant Platypus
  • 145
  • 1
  • 8