Take the 2-minute tour ×

How can I tell if the JVM my application runs in is 32 bit or 64-bit? Specifically, what function or preference do I access to detect this within the program?

share|improve this question
Just out of curiosity, why would you need to know the natural size of the system? Details such as this are abstracted away in Java, so you shouldn't (in theory, at least) have to know them. –  Patrick Niedzielski Jan 14 '10 at 4:29
It lets me roughly estimate the memory requirements for objects due to pointers. Curiosity too -- seemed like there should be a way, but I'd never heard of it. –  BobMcGee Jan 14 '10 at 18:33
This "detail" is not abstracted away when interacting with the Java Native Interface. 32-bit DLLs can't be loaded with a 64-bit JVM (and vice versa). So this is quite essential information for anyone using JNI. It's a pity that there seems to be no portable way to obtain this info. One way is to first try loading a 32-bit version of the DLL, and if it fails, try the 64-bit version, etc. Ugly! –  Joonas Pulakka Apr 30 '10 at 7:17
Another situation where discerning between 32 or 64 bit JVMs is important is for mapped files. On 32 bit systems only 2GB can be mapped, so it's important to map and unmap file segments accordingly so that this limit is not exceeded, while on 64 bit jvms the limit is much, much, much higher. –  Simone Gianni Sep 9 '12 at 21:07
@simonegianni wouldn't that make such a mapping the perfect test? –  Thorbjørn Ravn Andersen Jul 9 '13 at 22:32
show 1 more comment

7 Answers

up vote 129 down vote accepted

Sun has a Java System property to determine the bitness of the JVM: 32 or 64:

sun.arch.data.model=32 // 32 bit JVM
sun.arch.data.model=64 // 64 bit JVM

You can use


to determine if its 32/64 from the program.

From the sun.docs:

When writing Java code, how do I distinguish between 32 and 64-bit operation?

There's no public API that allows you to distinguish between 32 and 64-bit operation. Think of 64-bit as just another platform in the write once, run anywhere tradition. However, if you'd like to write code which is platform specific (shame on you), the system property sun.arch.data.model has the value "32", "64", or "unknown".

The only good reason is if your java code is dependent upon native libraries and your code needs to determine which version (32 or 64bit) to load on startup.

share|improve this answer
I wouldn't expect to find sun.* system properties with an IBM JVM. In other words, it's not portable. –  Pascal Thivent Jan 14 '10 at 23:19
How can you tell from the command line? If you are running 32-bit or 64-bit? Just curious. –  Matthew Doucette Feb 2 '12 at 20:33
Why is the accepted answer Sun-dependent? "os.arch" will accomplish the same thing without having to use proprietary sun packages. –  b1naryatr0phy May 24 '12 at 10:38
@b1naryatr0phy, does os.arch report on the Operating System, or the JVM? I often run 32-bit JVM on my 64-bit workstation, for development purposes. –  skiphoppy Aug 8 '12 at 17:19
This property is supported on IBM JVMs, but not on GCJ. See stackoverflow.com/questions/807263/… –  Emmanuel Bourg Nov 9 '12 at 13:13
show 2 more comments

You can try on the command line:

java -d64 -version




share|improve this answer
Although this is good to know, it's not useful b/c I need to run it from outside the program or use java options to start a new process. –  BobMcGee Jan 14 '10 at 5:06
Note: The -d64 flag does not work on Windows. –  Eddie Mar 9 '11 at 22:44
The -d64 flag works in Windows 7. –  Joshua Burns Oct 20 '11 at 16:48
I am on Windows 7, and I get 'unrecognized option' error from java -d32 -version and also from java -d64 -version. –  EMS Apr 20 '12 at 20:29
try -D64 instead of -d64 –  Todd Mar 21 '13 at 15:54
show 4 more comments

on WindowsNT you just type java -version in your console

and if a 64bit version is running, you'll get a message like


share|improve this answer
add comment

Update Again:

I installed 32-bit JVM and retried it again, looks like the following does tell you JVM bitness, not OS arch:

# on a 64-bit Linux box:
# "x86" when using 32-bit JVM
# "xmd64" when using 64-bit JVM

This was tested against both SUN and IBM JVM (32 and 64-bit). Clearly, the system property is not just the operating system arch.

share|improve this answer
This gives Operating system architecture info. If I'm not wrong, this need not be same of JVM bitness. –  codaddict Jan 14 '10 at 3:52
Yeah. It gives x86, etc. Not quite the same thing, since I'm not sure if it gives "x64" for x86-64 running in 64-bit rather than 32-bit. –  BobMcGee Jan 14 '10 at 4:11
@codaddict, looks like it is JVM bitness indeed. –  bryantsai Jan 14 '10 at 23:14
@codaddict That is completely false (and I have no idea why six ppl have voted that comment up.) "os.arch" is designed to return the JVM version. Test it out for yourself and god help you if you're actually relying on this for OS detection. –  b1naryatr0phy May 24 '12 at 10:36
os.arch has many possible values, it's difficult to tell if it's 32 or 64 bits. See lopica.sourceforge.net/os.html –  Emmanuel Bourg Nov 9 '12 at 13:15
show 2 more comments

Complementary info:

On a running process you may use (at least with some recent Sun JDK5/6 versions):

$ /opt/java1.5/bin/jinfo -sysprops 14680 | grep sun.arch.data.model
Attaching to process ID 14680, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.5.0_16-b02
sun.arch.data.model = 32

where 14680 is PID of jvm running the application. "os.arch" works too.

Also other scenarios are supported:

jinfo [ option ] pid
jinfo [ option ] executable core
jinfo [ option ] [server-id@]remote-hostname-or-IP 

However consider also this note:

"NOTE - This utility is unsupported and may or may not be available in future versions of the JDK. In Windows Systems where dbgent.dll is not present, 'Debugging Tools for Windows' needs to be installed to have these tools working. Also the PATH environment variable should contain the location of jvm.dll used by the target process or the location from which the Crash Dump file was produced."

share|improve this answer
add comment

On Linux, you can get ELF header information by using either of the following two commands:

file {YOUR_JRE_LOCATION_HERE}/bin/java

o/p: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, not stripped


readelf -h {YOUR_JRE_LOCATION_HERE}/bin/java | grep 'Class'

o/p: Class: ELF64

share|improve this answer
add comment

I just add sqljdbc_auth.dll x86 and it works.

share|improve this answer
add comment

Your Answer


