Java Bitness

It's been 5 years since the first time I wrote about 32-64 bits. Last week because of a small Java development at work I became aware of the differences between the Java Platform and .Net in their approach to the 32/64 bits management.

The first and quite noteworthy difference is that in the .Net world when you install the .Net framework in a 64 bits machine you get installed both a 64 and 32 version, while that in the Java Platform you have different downloads/installations for the 32 and 64 JRE's and JDK's. Of course you can install them side by side, but well, at a global level you have to decide which one is the default (I mean by this the one added to the PATH and the JAVAHOME).

As we know a normal .Net (I'm not talking about the kind of ngen scenarios) and JVM applications get compiled to bytecodes for a Virtual Machine. These bytecodes and VM's are high level enough to abstract us from the 32 or 64 bits architecture underneath, so in theory our .Net or Java applications should run the same on a 32 or 64 environment (performance differences aside). This is true unless that we are loading in our process native components (dll's/so's or COM components) via P/Invoke or JNI. In that case, as I explain in my first linked post, our application will have to stick to the bitness of that component, as a process and the dll's it loads have to be of the same bitness. So it seems necessary to be able to indicate to the OS that our application needs to run under a certain bitness or that it does not care.

In .Net when you compile your application you specify in the resulting .exe or .dll (in the PE header) if it needs to run as 32, 64 or as any (the anyCPU setting), and the OS will do accordingly creating a 32 or 64 bits process. So if you don't use native components or you don't have specific performance needs, you'll compile as anyCPU and the application will run as 32 or 64 depending on the OS. In the Java Platform (I'm talking about any language that can be compiled for a JVM: Java, Scala, Groovy...) the .class files generated when compiling your JVM language lack of any 32 or 64 bits flag. This means that it's your responsability to start a JVM with the correct bitness. So if you use a .bat to launch it, you'll have to point there to the Java.exe corresponding to the 32 or 64 JRE.

I prefer the .Net approach, it feels more clear to me to have the bitness indicator directly in the file that contains the compiled code than having it in a launcher .bat that somehow needs to point to the right JRE (which is not so easy, cause as I said above, the java.exe in your PATH could be pointing to the JRE with the wrong bitness.