[JNI] UnsatisfiedLinkError, warum?
Timon Christl
bin ich da nicht so fit. Nun das Problem:
Ich habe folgende Klasse:
package de.christltimon;
import java.io.File;
final class LinuxFileTools extends FileTools {
public LinuxFileTools() {
System.loadLibrary("filetools");
}
public native boolean isLink(String s);
}
Der Aufruf von loadLibrary steht nicht in einem static {} Block, weil ich
die Library erst laden lassen will wenn das Objekt erzeugt wird, nicht
wenn die Klasse geladen wird. Je nach Wert der Properties os.name und
os.arch soll eine andere von FileTools abgeleitete Klasse benutzt werden,
die dann ihrerseits die richtige Library lädt. Sollte soweit kein
Problem darstellen.
Ich habe also sozusagen nach Lehrbuch mit javah den Header erstellt, die
native Methode implementiert und ein libfiletools.so zusammengelinkt
(Ich arbeite unter Linux wie man sehen kann). Nach ein bißchen Gefiedel
mit dem Library-Suchpfad fand java auch tatsächlich die Library, jedoch
irgendwie nicht die Methode:
Exception in thread "main" java.lang.UnsatisfiedLinkError: isLink
at de.christltimon.LinuxFileTools.isLink(Native Method)
at de.christltimon.LinuxFileTools.isLink(LinuxFileTools.java:16)
at Test.main(Test.java:12)
Würde java die Library nicht finden, wäre die Meldung ja anders:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no filetools in
java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1312)
at java.lang.Runtime.loadLibrary0(Runtime.java:749)
at java.lang.System.loadLibrary(System.java:820)
at de.christltimon.LinuxFileTools.<init>(LinuxFileTools.java:8)
at de.christltimon.FileTools.getInstance(FileTools.java:13)
at Test.main(Test.java:10)
Was mache ich da falsch? Mir kommt die Namensgebung der Header-Datei schon
ein bißchen merkwürdig vor (de_0002fchristltimon_0002fLinuxFileTools.h),
liegts vielleicht daran? Oder ist der C-Compiler schuld, es ist nämlich
der gcc 2.96 (Ich benutze ihn nicht freiwillig, unsere Admins wollten ja
umbedingt auf Redhat 7 upgraden).
--
Timon Christl <chr...@fmi.uni-passau.de>
Matthias Ernst
> Zunächst: Ich habe seit Java 1.2 nichts mehr mit JNI gemacht, deshalb
> bin ich da nicht so fit. Nun das Problem:
>
Poste bitte mal das generierte header-file. Das '2f' ist dubios, das ist
genau der ASCII-Code für '/'. Machst Du 'javah
de/christltimon/LinuxFileTools.h' ? Versuchs mal mit einem Punkt statt
dessen.
Matthias
--
Matthias Ernst - SoftwareIngenieur
CoreMedia AG - http://www.coremedia.com - 0700-COREMEDIA
Visit us at
* Buchmesse, Frankfurt, 1.1/C1113 (at DWS)
* Systems, Munich, C1.330
Timon Christl
>> Zunächst: Ich habe seit Java 1.2 nichts mehr mit JNI gemacht, deshalb
>> bin ich da nicht so fit. Nun das Problem:
>>
>Poste bitte mal das generierte header-file. Das '2f' ist dubios, das ist
>genau der ASCII-Code für '/'. Machst Du 'javah
>de/christltimon/LinuxFileTools.h' ? Versuchs mal mit einem Punkt statt
>dessen.
Das wars tatsächlich, wenn ich / statt . schreibe streikt er. Kleiner
Flüchtigkeitsfehler mit großen Auswirkungen. Komisch ist nur daß javah
tatsächlich ein Headerfile generiert. Eigentlich wäre es doch sinniger
wenn dann eine Fehlermeldung käme, denn schließlich existiert keine
Klasse mit einem solchen Namen.
Also Danke, es funktioniert jetzt.
--
Timon Christl <chr...@fmi.uni-passau.de>
Matthias Ernst
> Das wars tatsächlich, wenn ich / statt . schreibe streikt er. Kleiner
> Flüchtigkeitsfehler mit großen Auswirkungen. Komisch ist nur daß javah
> tatsächlich ein Headerfile generiert. Eigentlich wäre es doch sinniger
> wenn dann eine Fehlermeldung käme, denn schließlich existiert keine
> Klasse mit einem solchen Namen.
In der Hinsicht scheinen die Java-Tools ein wenig schwammig zu sein.
FindClass im Java Native Interface erwartet zum Beispiel einen
slash-separierten String, javap kann glaube ich beides.
Symptomatisch die Javadoc von ClassLoader:
@param name the expected name of the class, or <code>null</code>
if not known, using '.' and not '/' as the separator
and without a trailing ".class" suffix.