# JBuilder X dll load



## masterjcl (8. Juni 2004)

Guten Tag !

Ich habe folgendes Problem, ich arbeite schon seit längerem mit dem JBuilder und bin immer zufrieden gewesen aber das Problem macht mir echt graue Haare.

Ich habe eine Sample.dll geschrieben und kompiliert , ich kann die DLL ohne Probleme außerhalb vom JBuilder mittels java Ansprechen und testen. Also sie geht 100%tig. Getestet mit Visual c++ Tookit von MS und jdk 1.4.2_01. Hier noch mein Build und Testscript.



```
echo "Compile DLL"
cl /Ox /GX /LD /ML /I"C:\Programme\JBuilderX\jdk1.4\include" /I"C:\Programme\JBuilderX\jdk1.4\include\win32" Sample1.cpp
set LD_LIBRARY_PATH=c:\mydll;C:\Borland\BCC55\dll;.;
echo SET LD_LIBRARY_PATH to $LD_LIBRARY_PATH
echo "done.."
pause
echo "Compile StrLen"
javac Sample1.java
echo "done.."
java -classpath . Sample1
pause
```


Jetzt kommt es aber, ich habe eine Applikation mit einer GUI erzeugt mittels JBuilder X und wollte die DLL einbinden und testen ... keine Chanche. 
Folgendes habe ich schon probiert:
 - dll in das class Verzeichnis kopiert
 - dll in den LD_LIBRARY_PATH kopiert(Umgebungsvariable war schon gesetzt)
 - dll in das CLASS/$(Package) Verzeichnis kopiert
Hat jemand einen Tipp  eventuell liegt es aber auch am Package System von java da die Klasse mittels Package in einem Unterverzeichnis liegt..
 
thx

ps: anbei noch der DLL Code


----------



## masterjcl (8. Juni 2004)

dll Code


----------



## Thomas Darimont (8. Juni 2004)

Hallo!

Kopier die DLL mal testweise ins bin-Verzeichnis von dem aus java(.exe) ausgeführt wird. Eine andere Möglichkeit wäre noch die Variable java.library.path zu als Property (-D...) beim als Parameter von java zu setzen. Du könntest aber auch noch versuchen das ganze nach %JAVA_HOME%/JRE/i386 zu kopieren..

Lädst du die dll richtig ein deiner Java Anwendung?

Wenn die DLL test.dll heißt muss der Befehl zum laden

System.loadLibraray("test") heißen...

Gruß Tom


----------



## masterjcl (8. Juni 2004)

Vielen Dank erst einmal,
ich habe alles getestet
leider geht es immer noch nicht !


Die Dll heisst Sample1.dll
unter Linux sollte sie natürlich libSample1.so heissen 



```
package abrechnung;

public class LoadLib {
  static{
  System.loadLibrary("Sample1");
  }
  public native int intMethod(int n);
  public native boolean booleanMethod(boolean bool);
  public native String stringMethod(String text);
  public native int intArrayMethod(int[] intArray);
  public native int zusatz(int zahl);

  public LoadLib() {
int hh =intMethod(3);

  }

}
```



```
java.lang.UnsatisfiedLinkError: intMethod
	at abrechnung.LoadLib.intMethod(Native Method)
	at abrechnung.LoadLib.<init>(LoadLib.java:23)
	at abrechnung.Abrechnung.<init>(Abrechnung.java:42)
	at abrechnung.RunSys.<init>(RunSys.java:21)
	at abrechnung.RunSys.main(RunSys.java:51)
Exception in thread "main"
```


----------



## Thomas Darimont (8. Juni 2004)

Hallo!

Poste doch mal den Output zu :

```
System.out.println(System.getProperty("java.library.path"));
```

... wenn die DLL in einem dieser Verzeichnisse liegt wird sie normallerweise gefunden...

Sind deine C-Quellen eventuell noch von anderen Libs abhängig? Die müssten dann auch noch in ein Verzeichnis von dem aus sie gefunden werden könnten ...

Gruß Tom


----------



## masterjcl (8. Juni 2004)

Hier der Aufruf, ich habe nachdem Du das gepostet hast nocheinmal die dll in das Borland dll Verzeichnis kopiert, leider keine Besserung.

```
System.out.println(System.getProperty("java.library.path"));
new LoadLib();
```
Ausgabe:

```
java.lang.UnsatisfiedLinkError: intMethod
	at abrechnung.LoadLib.intMethod(Native Method)
	at abrechnung.LoadLib.<init>(LoadLib.java:23)
	at abrechnung.RunSys.<init>(RunSys.java:22)
	at abrechnung.RunSys.main(RunSys.java:53)
C:\Programme\JBuilderX\jdk1.4\bin;.;C:\WINDOWS\System32;C:\WINDOWS;C:\PVSW\BIN;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\Sybase\SQL Anywhere 7\Win32;C:\Programme\JBuilderX\jdk1.4\bin;C:\Borland\BCC55\dll;C:\Borland\BCC55\bin;C:\Borland\BCC55\dll
Exception in thread "main"
```


Ich habe auch nach alten dll's gesucht mit dem selben Namen , ich habe aber keine mehr gefunden !


----------



## masterjcl (9. Juni 2004)

Ich habe noch ein wenig geforscht und mir ist etwas aufgefallen, er scheint tatsächlich die DLL zu finden er kann aber nicht die FUnktion aufrufen aber warum is die Frage, wenn ich die DLL komplett lösche bringt er folgende Fehlermeldung.


```
java.lang.UnsatisfiedLinkError: no Sample1 in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1491)
	at java.lang.Runtime.loadLibrary0(Runtime.java:788)
	at java.lang.System.loadLibrary(System.java:834)
	at abrechnung.LoadLib.<clinit>(LoadLib.java:14)
	at abrechnung.RunSys.<init>(RunSys.java:22)
	at abrechnung.RunSys.main(RunSys.java:53)
Exception in thread "main"
```

Wenn ich die DLL jetzt in den Pfad lege kommt folgende Fehlermeldung



```
java.lang.UnsatisfiedLinkError: intMethod
	at abrechnung.LoadLib.intMethod(Native Method)
	at abrechnung.LoadLib.<init>(LoadLib.java:23)
	at abrechnung.RunSys.<init>(RunSys.java:22)
	at abrechnung.RunSys.main(RunSys.java:53)
c:\mydll
Exception in thread "main"
```


Ich habe auch schon die JDK's überprüft Sie stimmen auch überein bzw ich habe nur ein JDK .

Hat jemand eine Ahnung ich poste noch zusätzlich meine Projektdateien.


----------



## masterjcl (9. Juni 2004)

Projektdateien


----------



## masterjcl (9. Juni 2004)

Ich habe es gelöst   


Mein Problem war die Namensraum Spezifikation man sollte schon den Header File für die Wrapper Klasse definieren und nicht einfach versuchen eine DLL mit einem anderen Namensraum zu benutzen.



```
// alter header File
JNIEXPORT jint JNICALL Java_Sample1_intMethod

// neue header File
JNIEXPORT jint JNICALL Java_abrechnung_LoadLib_intMethod
```
Nachzulesen hier:
http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/design.html#wp615

trotzdem vielen Dank


----------



## Thomas Darimont (9. Juni 2004)

D'oh!

Gruß Tom


----------



## melmager (2. Oktober 2004)

masterjcl hat gesagt.:
			
		

> Ich habe es gelöst
> 
> 
> Mein Problem war die Namensraum Spezifikation man sollte schon den Header File für die Wrapper Klasse definieren und nicht einfach versuchen eine DLL mit einem anderen Namensraum zu benutzen.
> ...




Ich habe jetzt ein ähnliches Problem mit dem Link Error :-(

Loadlib ist ja hier die Classe aber woher kommt die abrechnung ?


```
class Ctapi {
  native int ctinit(int ctn,int pn);
  native byte[] ctdata(int ctn,byte[] buffer);
    //destination(dad),source(sad),length of command(lc),CommantBuffer(cmd)
    //  length of response(lr),Response(rsp)
  native int ctclose(int ctn);

  static {
    System.loadLibrary("Ctapi");
  }
}
```

so sieht bei mir im Moment aus 

JNIEXPORT jint JNICALL Java_Ctapi_ctinit
  (JNIEnv *, jobject, jint, jint);

und so im Header


----------



## masterjcl (2. Oktober 2004)

abrechnung kommt von dem verwendeten Package


package abrechnung;


----------



## melmager (2. Oktober 2004)

Na toll :-(

Wenn immer der Projekt / Package Name mit rein kommt wird es schwerer für mich

ich wollte die Classe eigendlich in mehreren Projekte nutzen, jetzt sieht es für mich so aus, das ich für jeder Projekt sein eigenes libary.so file bekommt.


----------



## masterjcl (2. Oktober 2004)

Das ist nicht ganz richtig wenn die Java-Wrapper Klasse einmal vernünftig funktioniert kannst Du Sie überall benutzen über eine neue Instanz des Objektes vom Typ Wrapperklasse.
dh Du solltest das Interface in ein eigenes Package packen dies kannst Du dann als Library immer wieder verwenden.


----------

