And to elaborate, Java is compiled into byte code that is interpreted by the JVM. There is no "32 bit" or "64 bit" inside it. There's not even "Windows" or "Linux" in it.
A few things to be careful for:
- native libraries (JNI); unlike Java byte code, these are both platform and architecture specific. You will need to rewrite / recompile these.
- file paths; Windows 7 no longer uses "C:\Documents and Settings" but "C:\Users" instead. 64 bit Windows has both "C:\Program Files" for 64 bit applications and "C:\Program Files (x86)" for 32 bit applications; 32 bit Windows only has "C:\Program Files". And Linux has a completely different file structure altogether.
- explicit use of "\n" or "\r\n" for line breaks, "\" or "/" for file separators (although Java on Windows also supports / with java.io.File), ";" or ":" for path separators, etc. You can use a few of the static fields of java.io.File for most of these, and System.getProperty(...) for the others. With the new printf methods you can also use "%n" for the platform specific line break.
One more note: object references ("pointers") take 4 bytes in 32-bit JDK, but 8 bytes in 64-bit JDK. Running your application in 64bit JDK will therefore increase its memory requirements quite significantly (by 30-50%), since Java generally uses a lot of pointers (just about everything in Java is an object).
On the other hand, you should be able to allocate a lot more of memory to 64bit JDK, thus more than compensating for the increased memory consumption. However, I personally use Windows XP x64 and was not able to allocate more than 2 GB even to 64bit instance (JRE6, 8 GB physical memory, 4 GB free) and don't know why; I don't pursue it as of now, since due to JNI I'm locked to 32 bits in my environment anyway. But curiosity remains.
You might also be interested in this official article. Edit: the document is rather dated, but I guess that what it has to say about 64 bits still holds.
Martin Vajsar wrote:However, I personally use Windows XP x64 and was not able to allocate more than 2 GB even to 64bit instance (JRE6, 8 GB physical memory, 4 GB free) and don't know why;
Is the JVM also 64 bit?
Yes, at that time I've tried to run 64 bit java.exe (confirmed it was 64 bit via Process Explorer) with command line argument -Xmx4096m and still could not allocate more than approximately 2 GB (actually it was around 1800 MB, this value was taken from Runtime.getRuntime().maxMemory()).
However, I've tried it anew and now I'm able to allocate more memory (Runtime.getRuntime().maxMemory() says 3640 MB for -Xmx4096m). Since I sometimes update to newer JRE, I assume this was fixed in meantime. It's several months since I tried last time and I had 1.6.0_13 or so. Now I have 1.6.0_17-b04.
Sorry for posting outdated info. I might try to install older JRE and retry, just out of curiosity; I'll post back here if I find time to do it.
We are running 64 bit java on windows & AIX on at least 50 testing servers since mid-2009.... of cource they are all allocated with more than 2 GB memory. That too on Java 1.5 ... So don't think there is any issue in allocating more than 2 GB in 64 bit JVMs.... We have tried both Sun (oracle) & IBM jvms ...
But the JVM for AIX is probably significantly different than the JVM for Windows PCs with Intel hardware. So that it works on AIX doesn't say a lot about that it will work on Windows / Intel - although I'd expect that it should be possible to allocate more than 2 GB RAM when you use the 64-bit JVM on 64-bit Windows (provided the computer has enough RAM installed).
As I've initiated this discussion, I sort of felt obliged to look into the issue
I downloaded and installed 64 bit versions of JRE 1.6.0_05, 1.6.0_10 and 1.6.0_13, and in all of them was able to allocate more than 2 GB on my notebook, where I have Windows XP x64 too.
However, I originally did the test on my computer at work and will try it tomorrow there, it has a little bit different configuration. I'm rather sure the problem was real, I've certainly spent quite a few hours on it.
I don't actually remember exact version of JRE I had at that time (and I'm not going to try all of them), and also quite a lot of Microsoft's patches were automatically downloaded and installed, so the problem might not be reproducible.