How do I detect which kind of JRE is installed -- 32bit vs. 64bit

Asked 30/4, 2009 at 14:41 Answered 24/5, 2016 at 14:6

During installation with an NSIS installer, I need to check which JRE (32bit vs 64bit) is installed on a system. I already know that I can check a system property "sun.arch.data.model", but this is Sun-specific. I'm wondering if there is a standard solution for this.

Euratom answered 30/4, 2009 at 14:41 Comment(0)

The JVM architecture in use can be retrieved using the "os.arch" property:

System.getProperty("os.arch");

The "os" part seems to be a bit of a misnomer, or perhaps the original designers did not expect JVMs to be running on architectures they weren't written for. Return values seem to be inconsistent.

The NetBeans Installer team are tackling the issue of JVM vs OS architecture. Quote:

x64 bit : Java and System

Tracked as the Issue 143434.

Currently we using x64 bit of JVM to determine if system (and thus Platform.getHardwareArch()) is 64-bit or not. This is definitely wrong since it is possible to run 32bit JVM on 64bit system. We should find a solution to check OS real 64-bitness in case of running on 32-bit JVM.

for Windows it can be done using WindowsRegistry.IsWow64Process()

for Linux - by checking 'uname -m/-p' == x86_64

for Solaris it can be done using e.g. 'isainfo -b'

for Mac OSX it can't be done using uname arguments, probably it can be solved by creating of 64-bit binary and executing on the platform... (unfortunately, this does not work:( I've created binary only with x86_64 and ppc64 arch and it was successfully executed on Tiger..)

for Generic Unix support - it is not clear as well... likely checking for the same 'uname -m/-p' / 'getconf LONG_BIT' and comparing it with some possible 64-bit values (x86_64, x64, amd64, ia64).

Sample properties from different JVMs all running on 64bit Ubuntu 8.0.4:

32bit IBM 1.5:

java.vendor=IBM Corporation
java.vendor.url=http://www.ibm.com/
java.version=1.5.0
java.vm.info=J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20061001 (JIT enabled)
J9VM - 20060915_08260_lHdSMR
JIT  - 20060908_1811_r8
GC   - 20060906_AA
java.vm.name=IBM J9 VM
java.vm.specification.name=Java Virtual Machine Specification
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.vendor=IBM Corporation
java.vm.version=2.3
os.arch=x86
os.name=Linux
os.version=2.6.24-23-generic
sun.arch.data.model=32

64bit Sun 1.6:

java.vendor=Sun Microsystems Inc.
java.vendor.url=http://java.sun.com/
java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi
java.version=1.6.0_05
java.vm.info=mixed mode
java.vm.name=Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.name=Java Virtual Machine Specification
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.vendor=Sun Microsystems Inc.
java.vm.version=10.0-b19
os.arch=amd64
os.name=Linux
os.version=2.6.24-23-generic
sun.arch.data.model=64

64bit GNU 1.5:

java.vendor=Free Software Foundation, Inc.
java.vendor.url=http://gcc.gnu.org/java/
java.version=1.5.0
java.vm.info=GNU libgcj 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
java.vm.name=GNU libgcj
java.vm.specification.name=Java(tm) Virtual Machine Specification
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.vendor=Free Software Foundation, Inc.
java.vm.version=4.2.4 (Ubuntu 4.2.4-1ubuntu3)
os.arch=x86_64
os.name=Linux
os.version=2.6.24-23-generic

(The GNU version does not report the "sun.arch.data.model" property; presumably other JVMs don't either.)

Visual answered 30/4, 2009 at 18:12 Comment(0)

I'm using NSIS and Launch4j to wrap a Java Desktop app. So I need not only to detect any JRE, but the one Launch4j will find with its search algorithm. The only approach that made sense is to run a short Java program within the NSIS installer. Here's the Java:


    public class DetectJVM {
        private static final String keys [] = {
            "sun.arch.data.model",
            "com.ibm.vm.bitmode",
            "os.arch",
        };
        public static void main (String [] args) {
            boolean print = args.length > 0 && "-print".equals(args[0]);
            for (String key : keys ) {
                String property = System.getProperty(key);
                if (print) System.out.println(key + "=" + property);
                if (property != null) {
                    int errCode = (property.indexOf("64") >= 0) ? 64 : 32;
                    if (print) System.out.println("err code=" + errCode);
                    System.exit(errCode);
                }
            }
        }
    }

Wrap this with Launch4J. Use the GUI header type but also set to true. Otherwise the error code will be lost. (I put all this in my Netbeans Ant build script.

Here's the matching NSIS code that uses it:


File ... ; unpack files including detectjvm.exe.
ClearErrors
ExecWait '"$INSTDIR\detectjvm.exe"' $0
IfErrors DetectExecError
IntCmp $0 0 DetectError DetectError DoneDetect
DetectExecError:
    StrCpy $0 "exec error"
DetectError:
    MessageBox MB_OK "Could not determine JVM architecture ($0). Assuming 32-bit."
    Goto NotX64
DoneDetect:
IntCmp $0 64 X64 NotX64 NotX64
X64:
    File  ... 64-bit AMD DLLs.
    Goto DoneX64
NotX64:
    File ... 32-bit x86 DLLs.
DoneX64:
Delete $INSTDIR\detectjvm.exe

This has worked fine on a very large variety of machines from WinXP with no SP through Vista and Win7 with all SPs, 32- and 64-bit.

Note that in my NSIS script I'm using an existing package that checks to see if the JVM is installed and does that first, so the default 32-bit selection would only occur if something went badly wrong with the JVM install, in which case the set of DLLs you copy won't matter anyway.

Hope this is helpful to somebody.

Karat answered 9/11, 2010 at 19:53 Comment(4)

This is a very useful workaround. The problem if, what if user's 64 bit machine is not installed with JVM? The script will then making wrong assumption. – Jarita 4/11, 2011 at 5:25

Note that for my case, I need to make it to Console using Launch4J. – Jarita 28/11, 2011 at 1:51

This may fail for some odd architectures like S390x. – Halogen 25/3, 2021 at 3:1

I should have said my app was for mac and window only. – Karat 25/3, 2021 at 3:41

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

http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_detection

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".

Rive answered 15/1, 2011 at 3:41 Comment(2)

As Thorbjørn Ravn Andersen said in another post, 32-bit JVMs run fine on a 64-bit os. Use sun.arch.data.model property if you're worried about the JVM bit width and not the operating system bit width (assuming you're running on the Hot Spot JVM...) – Rive 15/1, 2011 at 3:49

The bit-problem isn't because of the java code itself, but because of the wrapper, that we ship with our software. Assuming the following: If a customer tries to install our 64Bit SW version but he only has 32Bit Java installed; he has to be informed... – Euratom 24/1, 2011 at 10:29

import sun.misc.*;

import java.lang.reflect.*;

public class UnsafeTest {
  public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
    Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");
    unsafeField.setAccessible(true);
    Unsafe unsafe = (Unsafe) unsafeField.get(null);
    System.out.println(unsafe.addressSize());
  }
}

Defant answered 12/10, 2009 at 22:19 Comment(0)

java -version

For a 64bit java version it'll print :

java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) ***64-Bit*** Server VM (build 25.92-b14, mixed mode)

For 32 bit it'll be just

java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) Client VM (build 25.92-b14, mixed mode)

Selfassured answered 24/5, 2016 at 14:6 Comment(1)

You can try on the command line: java -d64 -version If it's not a 64-bit version, you'll get a message that looks like: This Java instance does not support a 64-bit JVM. Please install the desired version. Consult the help options of the JVM for more info java -help – Psaltery 2/7, 2017 at 18:31

On linux, my (java) vm reports java.vm.name=Java HotSpot(TM) 64-Bit Server VM. The javadocs for System declare that System.getProperty will always have a value for this but are silent on sun.arch.data.model.

Unfortunately they don't specify what the system property will be so some other JVM might just report java.vm.name=Edgar.

BTW, by "installed on the system", I assume you mean "the current running JVM"?

Ribaudo answered 30/4, 2009 at 15:2 Comment(0)

There might be both 32 bit and 64 bit JVM's available on the system, and plenty of them.

If you already have dll's for each supported platform - consider making a small executable which links and run so you can test if the platform supports a given functionality. If the executable links and run, you can install the corresponding shared libraries.

Elect answered 30/4, 2009 at 22:3 Comment(0)

-1

If you have the path to the .exe you want to check, you can use this answer. Basically it just looks at the headers in the .exe file and tells you whether or not it is 64 or 32 bit on Windows.

Lickerish answered 15/2, 2016 at 20:16 Comment(0)

-6

The following code checks the machineType field in any windows executable to determine if it is 32 or 64 bit:

public class ExeDetect
{
  public static void main(String[] args) throws Exception {
    File x64 = new File("C:/Program Files/Java/jre1.6.0_04/bin/java.exe");
    File x86 = new File("C:/Program Files (x86)/Java/jre1.6.0/bin/java.exe");
    System.out.println(is64Bit(x64));
    System.out.println(is64Bit(x86));
  }

  public static boolean is64Bit(File exe) throws IOException {
    InputStream is = new FileInputStream(exe);
    int magic = is.read() | is.read() << 8;
    if(magic != 0x5A4D) 
        throw new IOException("Invalid Exe");
    for(int i = 0; i < 58; i++) is.read(); // skip until pe offset
    int address = is.read() | is.read() << 8 | 
         is.read() << 16 | is.read() << 24;
    for(int i = 0; i < address - 60; i++) is.read(); // skip until pe header+4
    int machineType = is.read() | is.read() << 8;
    return machineType == 0x8664;
  }
}

Note that the code has been compacted for brevity...

Xanthippe answered 4/6, 2009 at 12:54 Comment(4)

note that the code breaks as soon as the user doesn't use the very same jre version... – Evenings 3/12, 2009 at 15:0

This is a generic method for detecting a 64bit executable on windows. Nothing specific to jre version. – Xanthippe 23/4, 2011 at 1:31

If you change for "C:\Program Files\Java\jre6\,..."!"C:\Program Files (x86)\Java\jre6\,..." then it's little bit better but only good on the Windows platform and a regular install. – Equivocation 10/11, 2013 at 4:55

@PeterSmith It's dependent on the JRE version because you're using hardcoded paths that only exist if the specific JRE version was installed in the default directory. Have you otherwise abstracted it away in any form in code not shown? – Arcturus 27/7, 2017 at 2:45

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags