According to this FAQ :

How do I select between 32 and 64-bit operation? What's the default?

The options -d32 and -d64 have been added to the Java launcher to specify whether the program is to be run in a 32 or 64-bit environment. On Solaris these correspond to the ILP32 and LP64 data models, respectively. Since Solaris has both a 32 and 64-bit J2SE implementation contained within the same installation of Java, you can specify either version. If neither -d32 nor -d64 is specified, the default is to run in a 32-bit environment. Other Java commands (javac, javadoc, etc.) will rarely need to be executed in a 64-bit environment. However, the -d32/-d64 options may be passed to these commands and then on to the Java launcher using the established -J prefix option (eg: -J-d64).
All other platforms (Windows and Linux) contain separate 32 and 64-bit installation packages. If both packages are installed on a system, you select one or the other by adding the appropriate "bin" directory to your path. For consistency, the Java implementations on Linux accept the -d64 option.

I have Java 64 bit JVM installed on my Windows 7 machine. I have installed 32 bit Java version as well because I need it for some applications that only work with 32 bit JVM. I change the JAVA_HOME and PATH environment variables to point to the new 32 bit Java location and tried to add the new Java path to the Java Control Panel. The new Java version can be found but is not preserved  in the Java runtime environment settings when I try to add it in. Moreover when I enter 'java  -version' at a DOS command line I always see windows reporting back that it sees the 64 bit version:

java version "1.6.0_26"

Java(TM) SE Runtime Environment (build 1.6.0_26-b03)

Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Regards,

David

Had a similar issue, just with Java 11. Eventually, I found a 32bit JDK and JRE for Java 11 on https://adoptopenjdk.net/ (for the Hotspot JVM). With the 32bit JDK, I successfully connected to a 32bit dll. I hope this is useful for others who face a similar situation.

64-bit vs. 32-bit really boils down to the size of object references, not the size of numbers.

In 32-bit mode, references are four bytes, allowing the JVM to uniquely address 2^32 bytes of memory. This is the reason 32-bit JVMs are limited to a maximum heap size of 4GB (in reality, the limit is smaller due to other JVM and OS overhead, and differs depending on the OS).

In 64-bit mode, references are (surprise) eight bytes, allowing the JVM to uniquely address 2^64 bytes of memory, which should be enough for anybody. JVM heap sizes (specified with -Xmx) in 64-bit mode can be huge.

But 64-bit mode comes with a cost: references are double the size, increasing memory consumption. This is why Oracle introduced "Compressed oops". With compressed oops enabled (which I believe is now the default), object references are shrunk to four bytes, with the caveat that the heap is limited to four billion objects (and 32GB Xmx). Compressed oops are not free: there is a small computational cost to achieve this big reduction in memory consumption.

As a personal preference, I always run the 64-bit JVM at home. The CPU is x64 capable, the OS is too, so I like the JVM to run in 64-bit mode as well.