CODEWITHSUNDEEP
javac++dlljava-native-interface
Andrew Evt
Andrew Evt

Reputation: 3689

JNI problems with dll files

I have problem with JNI, again...

This time my code works... But... not correct on all PC.

I have:

  1. Jar file -> my prog
  2. dll file -> with native methods
  3. another dll file -> with another functions.

On my PC all this files are in ONE folder.

Files code (.java):

// loading library
    try {
        Runtime.getRuntime().loadLibrary("E140tests");
        setText("Library E140tests.dll was loaded correctly.");
    } catch (UnsatisfiedLinkError ex) {
        // try load with absolute path
        setText("Error: E140tests.dll wasn't loaded!");
        setErrorFlag(true);
    }

E140tests.dll -> second file (compileted in MSVS)

#include "jni.h"
#include "jni_md.h"
#include "Lusbapi.h"
#include "LusbapiTypes.h"
#include "JNITEST2.h"

#ifdef __cplusplus
extern "C" {
#endif

/*
 * Class:     JNITEST2
 * Method:    ADCinit
 * Signature: (LJNITEST2;)V
 */
JNIEXPORT void JNICALL Java_JNITEST2_ADCinit
  (JNIEnv* env, jobject, jobject obj) {
  ...

lusbapi.dll -> third file, with another functions.

#ifndef __LusbapiH__
#define __LusbapiH__

// --------------------------------------------------------------------------
// ---------------------------- COMMON PART ---------------------------------
// --------------------------------------------------------------------------
#include <windows.h>
#include "LusbapiTypes.h"

If I throw my files in system32, all works too.

But. In another PC (xp, 7) my code doesn't works! Doesn't matter: if files(+dll) are in one folder, or if dll files are in system32 -> code can't find them.

I thought, that problem is in Runtime Libraries (MSVS), but wenn I installed them, nothing has changed...

(on my PC are IntelijIDEA, MSVS, jdk7.xx -> all works. I tested prog on another PC (with MSVS installed) -> and all worked. But on another -> dll wasn't found (and with Runtime Libraries installed too)).

i'll be waiting for help)

Upvotes: 1

Views: 1239

Answers (3)

Java42
Java42

Reputation: 7716

If you are going to distribute your application, you will want to build both 32bit and 64bit versions of your DLL. Then use the following technique to have the proper DLL loaded regardless of your customers JVM arch. Append either a 32 or a 64 (MyJniDLL32.dll & MyJniDLL64.dll) to your generated output file.

String archDataModel = System.getProperty("sun.arch.data.model");
System.loadLibrary(libraryName+archDataModel);

The arch of the DLL (32 vs 64) must match the JVM ach (32 vs 64 ), not the OS arch. If you are running a 32bit JVM on a 64bit OS, your Java code must have access to a 32bit DLL.

Upvotes: 0

Sri Harsha Chilakapati
Sri Harsha Chilakapati

Reputation: 11950

You have to compile the DLL in both architectures. For compilation, you can use your 64-bit system and use these commands to compile.

For 64 bit (GCC)

gcc -o E140Tests64.dll -shared -IC:\....\include sourcefile.c

For 32 bit (GCC)

gcc -o E140Tests.dll -shared -IC:\....\include sourcefile.c

Hope this helps.

Upvotes: 0

WillBD
WillBD

Reputation: 1919

Unfortunately, when you compile the .DLL, it is only compatible with systems of matching architecture.

aka: 32-bit .DLL's work on 32-bit machines, the same goes for 64-bit. There are tactics to get around this (buying a licence for visual studio gives you tools that will allow this, and will produce platform-specific .dlls), but it means you have to bundle the appropriate .DLL with whatever version of the program you're testing. That's why on websites it asks if you have a 32-bit or 64-bit machine most of the time.

This is also one of the main reasons that java is nice, because it is 'platform independent' (I use that term loosely since other things can influence this to make it untrue).

Either way, as soon as you add JNI calls, you add a whole slew of dependencies that make it a little harder to distribute the software.

Upvotes: 2

Related Questions