JNI Rückgabefehler

[Sunchezz]

Hallo liebe Java-Freunde =)

folgendes Problem:

Ich habe eine Dll und möchte daraus eine Funktion aufrufen, genau genommen klappt das auch schon, allerdings ist der Rückgabewert falsch!

Soll: XXXX-XXXX-XXXX-XXXX
Ist: "???????????1"

mit anderen Programmiersprachen klappt es einwandfrei.

Liegt es vielleicht daran das ich zum laden der Dll ein fremdes Framework benutze?
vielleicht kennt ihr das ja: JInvoke

import com.jinvoke.JInvoke;
import com.jinvoke.NativeImport;

public class DLLInvokater {
  @NativeImport(library="C:\\...\\ID.dll"
                         //,function="?GetHardwareID@@",
                         //convention=CallingConvention.STDCALL)
                         )
   public static native String GetID(boolean flag1, boolean flag2, boolean flag3, boolean flag4, String arg);
   public static void main(String[] args) {
      JInvoke.initialize();
      System.out.println("The code return " + GetID(true, false, false, false, ""));
   }
}

ach ja, das JInvoke habe ich benutzt weil ich die DLL nicht selbst geschrieben habe und mir der nomale JNI weg daher unpassent schien. Da muss man ja Header files und solchen kram integrieren oder?

So, meine Frage nun, wieso bekomm ich als Rückgabe nur Fragezeichen, wenns in anderen Sprachen einwandfrei klappt?
In die Dll komm ich ja offensichtlich rein, die Methode ist mit allen Parametern und der dekleration einverstanden, sonst bekäm ich ja ne Exception. Wieso stimmt also der Rückgabewert überhaupt nicht?

Kann das was mit UTF oder ASCI zu tun haben?

Vielen Dank schonmal!

 

[Gastredner]

Kann das was mit UTF oder ASCI zu tun haben?

Wäre mein erster Gedanke gewesen, vielleicht eine andere Kodierung. Windows nutzt standardmäßig CP-1251 (oder so), wenn du das zurückgegebene String-Objekt darauf umbiegen könntest, dann ginge das vielleicht (vielleicht durch Streams mit entsprechender Kodierung jagen).
Alternativ kannst du, um sicher zu gehen, es ja auch mal mit JNA probieren.

 

[Sunchezz]

Nun ja, ich hab nun einige Codierungen ausprobiert:

String s = new String(GetID(false, false, true, false).getBytes(), "Cp1252");
System.out.println("The code return " + s);

und wenn daran nichts falsch is,
scheint die Kodierung der falsche weg zu sein.
Obwohls echt ne erleichterung wäre!

 

[Andi_CH]

Betrachte doch den Rückgabewert doch vorerst als ein Array of Byte - vielleicht gibt das einen Hinweis was wirklich im Returnwert steckt.

 

[Sunchezz]

gute idee, hat leider nur nichts gebracht...

habe mir das byte array mal ausgeben lassen:
63, 63, 63, 63, 63, 63, 63, 63, 55

alles ziemlich seltsam!

Aber an der DLL kanns nun wirklich nicht liegen, da hab ich schon getestet das es funktioniert, und vernünftige werte zurück kommen.
Also kanns ja nur an java, JNI, oder der Kodierung liegen oder lieg ich völlig falsch?

 

[Sunchezz]

So, ich habe das Problem nun gelöst/umgangen.
Ich habe jetzt auf gut Glück den Weg des JNA beschritten, und es hat auf anhieb funktioniert.

Schön für mich, denn jetzt kann ich weiter arbeiten, aber ehrlich gesagt würde es mich trotzdem interessieren warum da son Müll rauskam!
Scheint wohl wirklich am Framework JInvoke gelegen zu haben!

 

[Andi_CH]

gute idee, hat leider nur nichts gebracht...

habe mir das byte array mal ausgeben lassen:
63, 63, 63, 63, 63, 63, 63, 63, 55

alles ziemlich seltsam!

Aber an der DLL kanns nun wirklich nicht liegen, da hab ich schon getestet das es funktioniert, und vernünftige werte zurück kommen.
Also kanns ja nur an java, JNI, oder der Kodierung liegen oder lieg ich völlig falsch?

Na ja, das war vermutlich nicht das was ich gemeinte habe - wenn du einfach den empfangenen String als Bytearray ausgibst ist ja klar was kommt - ich hätte es lieber gesehen wenn du einen Bytearray empfangen hättest.

Aber wenns ja nun läuft ....

Für mich heisst das einmal mehr - nur Bytearrays sind wirklich kompatibel

 

[Marco13]

Ja, schau dir mal an was bei

byte data[] = GetID(...);
System.out.println(Arrays.toString(data));

rauskommt.

 

[Sunchezz]

Nun ja, geht das denn so einfach?

Ich mein die Methode liefert ja nunmal einfach nur nen normalen String zurück!

 

[Marco13]

Kann man ja nicht wissen - dann ist das "new String(" aber überflüssig (und dann wüßte ich auch nicht, was man da groß machen sollte....)

 

[Andi_CH]

Nun ja, geht das denn so einfach?
Ich meine die Methode liefert ja nunmal einfach nur nen normalen String zurück!

Welche Methode? Die in der dll oder die im Javaprogramm?

Die in der dll muss dich nicht interessieren - da kannst du in der Javawelt damit machen was du willst - auch einen Array of Bytes und der wird garantiert nicht durch länderspezifisches En- bzw. Decoding beeinflusst. (Wieder mal ein Nachteil von unsichtbaren Automatismen)