For a recent project I had to determine the bitness of IBM Domino in pure Java.
One may ask if there is a reason to have that information. In my case I wanted to call some included native C libraries via JNI within an OSGi plug-in. And calling i. e. a 64bit library on a 32bit system…well…that just won’t work.
I didn’t wanted to go with the assumption that on a 64bit operating system always 64bit Domino runs.
As I’m serving “only” Linux and Windows the number of combinations wasn’t so big. On Windows most installations of Domino are 64bit like the operating system. But I’m still seeing 32bit Domino installed on 64bit Windows. And I’m seeing very often 32bit Domino on 64bit Linux (even if people have moved to Domino 9 where IBM has introduced native 64bit support for Linux.).
The solution to this was simple – and a little bit suprising. I used System.getProperties() to see what properties are set on each Java VM.
Here is a listing of the interesting parameters (Domino 9 64bit on CentOS 64bit):
org.osgi.framework.processor: x86-64 org.osgi.framework.os.name: Linux sun.arch.data.model: 64 osgi.os: linux java.vm.info: JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr15-20131231_180656 (JIT enabled, AOT enabled) osgi.arch: x86_64 java.fullversion: JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr15-20131231_180656 (JIT enabled, AOT enabled) com.ibm.vm.bitmode: 64 os.arch:amd64
64bit as expected. The – at least for me – suprising part was, that all parameters differed when running 32bit Domino on the same box.
org.osgi.framework.processor: x86 org.osgi.framework.os.name: Linux sun.arch.data.model: 32 osgi.os: linux java.vm.info: JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr14-20130704_155156 (JIT enabled, AOT enabled) osgi.arch: x86 java.fullversion: JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr14-20130704_155156 (JIT enabled, AOT enabled) com.ibm.vm.bitmode: 32 os.arch:x86
I’ve run the same tests on Windows and got the same results. So using those Java properties allow you to detect the Domino bitness in pure Java.
Another solution – if you run in a pure OSGi environment – is to bundle your native code into fragments and load the fragments based on the operating system. The Bundle-NativeCode tag is your friend then.