32 bit vs 64 bit .dlls in Java

Hello,

A large portion of our software design here at Komatsu relies heavily on DDS integration. Currently, our goal is to be mostly Java-based. We have software that we need to deploy to customers that do not have a full version of RTI installed on their system. Because of this, we need to come up with a deployable solution where the customer can receive DDS data over their network and our Java applications can run on either a 32 bit or a 64 bit JVM effectively. However, we have only been able to support a 32bit environment thus far because we have run into a number of functional/design problems. We are currently using RTI version 5.2.3.

1. Can the 64 bit ndds*.dll libraries even be loaded into a 64 bit JVM on version 5.2.3 using the functionality provided inside com.rti.dds.util.NativeInterface?
• We have encountered un-ending problems attempting to load these libraries on a 64 bit JVM. We have encountered repeated UnsatisfiedLinkErrors even though the ndds*.dll libraries are blatantly accessible via the Path environment variable (C:\Program Files\rti_connext_dds-5.2.3\lib\x64Win64VS2010).
• Workaround: During our investigation, we noticed that we can load the 32-bit libraries into a 32 bit JVM by only loading nddsjava.dll, but we were only able to get the 64-bit libraries to load into a 64 bit JVM by loading the .dll files in the order below using System.load(). As of RTI Connext 5.2.3, are you loading the libraries in this order on Windows for both 64 and 32 bit JVMs?:
1. nddscore.dll
2. nddsc.dll
3. nddsjava.dll
• Can you duplicate the problems we are seeing with this?
2. What is the best way we can support 32 bit and 64 bit Java when we deploy our software to a customer machine that will be receiving DDS data? Currently, as of 5.2.3, it does not seem like RTI Java code provides an intuitive mechanism to load the correct .dlls based on what the bitwise architecture of the currently running JVM is. Since the library loading is entirely encapsulated inside NativeInterface.java, it makes it extremely difficult to find a code design workaround for this, or even know if RTI will load the correct libraries.
• Potential solution: Deploy two folders to the customer machine; one containing the 32-bit .dlls and the other containing the 64-bit .dlls. Create a wrapper class for NativeInterface.java that loads the correct .dlls based on the Java os.arch JVM property at runtime out of the corresponding deployed folder. Prevent NativeInterface.java from attempting to load the libraries somehow.

Thank you.