Delphi mit Java komunizieren

[Simon1988]

so nach eine langen Pause gehts weiter.
Also den Array den man nun als Pointer gespeichert hat, kann man nun folglich abrufen p[0] usw.
Wie siehts mit mehrdimensionalen Arrays aus?

Werden gleichermaßen geholt oder ?

Delphi-Quellcode:

  // Aufruf der  Methode
  buffer := JIntArray(self.jvm.JniEnv.CallObjectMethod(instance, mid, []));
  p := PIntegerArray(self.jvm.JniEnv.GetIntArrayElements(buffer, isCopy));

hm. 1. hab ich jetzt nen 2d array und kann einfach so aufrufen : p[0,1] ?

2. Wie sähe denn die Signtur bei der Ermittlung der MethodenID aus ? einfach so ? : [I ?

[Der_Unwissende]

Zitat von Simon1988:

Wie siehts mit mehrdimensionalen Arrays aus?

Werden gleichermaßen geholt oder ?

Delphi-Quellcode:

  // Aufruf der  Methode
  buffer := JIntArray(self.jvm.JniEnv.CallObjectMethod(instance, mid, []));
  p := PIntegerArray(self.jvm.JniEnv.GetIntArrayElements(buffer, isCopy));

Ja, auch Mehrdimensionale Arrays liegen in C einfach nur am Stück im Speicher. Hier ist es allein die Interpretation für mehr als eine Dimension zuständig (letztlich ist auch der Speicher nur eindimensional). Bekannt dürfte dies Verhalten auch bei einer TBitmap und dem Befehl Scanline sein, man bekommt auch nur ein Zeiger auf das erste Element der gewählten Linie. Nimmt man die y Position 0, so zeigt dieser Zeiger auf ein Byte-Array, in dem die gesamten Bitmap-Daten (also ohne Metainfos) am Stück liegen.

Zitat von Simon1988:

hm. 1. hab ich jetzt nen 2d array und kann einfach so aufrufen : p[0,1] ?

Jap, denke schon dass das geht (vorrausgesetzt die Dimensionen stimmen).

Zitat von Simon1988:

2. Wie sähe denn die Signtur bei der Ermittlung der MethodenID aus ? einfach so ? : [I ?

Hm, jetzt für mehrdimensionale Arrays? Da bin ich mir nicht 100% sicher, müsste man ausprobieren. [ leitet ein Array vom entsprechenden Typ ein. Da Java hier durchaus den Unterschied zwischen int[] und int[][] kennt, ist das nun eine Frage. Wenn JNI intelligent handelt, klappt es!

[ADD]
Hm, bin mir eigentlich doch nicht so sicher. Ich meine in Java sind mehrdimensionale Arrays echte Arrays of Array. Das heißt natürlich, dass hier ein Array von Referenzen gespeichert wird. Das wiederum heißt, jedes Array hat eigene Eigenschaften (z.B. seine Länge). Der sichere Weg ist es hier einfach nur eindimensional auf Arrays zuzugreifen (z.B. angelehnt an die Scanline).
Hier siehst du wieder, warum ich schon sagte, dass man möglichst die primitiven Datentypen nehmen sollte. Es ist einfach der Unterschied komplett verschiedener Programmieransätze, der hier durch kommt. Wären die immer 100% kompatibel würde man sich schnell fragen ob man beide Sprachen braucht.
Jedenfalls kann es sein, dass du hier eine Art Adapter bemühen solltest, der einfach mehrdimensionale Arrays eindimensional zurückgeben kann.
[/ADD]

[Simon1988]

Und ich wieder

so hab lange nix gemacht, aber jetzt gehts weiter.
Also das Handbuch is soweit fertig.
1 )Ich mach mich jetzt an dieses Beispiel programm. Das ganze Programm und alle Klassen sind in einem Jar gespeichert und meine frage ist, brauch ich die .*class dateien oder reicht dieses jar ? wenn ja wie ?

2 ) So ich habe eine Klasse in einer Datei und gebe deren Pfad an. Danach erzeuge ich ein Objekt dieser Klasse und speicher das Objekt als ein JObject. Bei dem Constructor vder Klasse wird aber eine anderes Objekt einer anderen Klasse automatisch erzeugt. Meine Frage ist: Wie können sich selbstgeschriebene Klassen untereinander finden. ?!
ist das einfach so möglich ? oder müssen die Dateien in einem Ordner liegen? Finden die sich nur wenn sie in eimem gemeinsamen jar oder .java bleiben (so wie sie eben programmiert wurden) ?

[Der_Unwissende]

Hm,
diesmal bin ich mir wirklich unsicher, was du eigentlich wissen möchtest.
An sich würde ich dir hier wohl eher zu einem Javabuch (sehr gut ist Java ist auch nur eine Insel, kostenlos online erhältlich) raten als zu meiner Hilfe. Autoren solcher Bücher haben didaktisch wohl um einiges mehr drauf und erklären (hoffentlich) aufbauend und schrittweise und erklären alles korrekt (zumindest in guten Büchern).
Ich weiß nicht genau, wo dein jar herkommt.
An sich gibt es hier ein eigenes Kapitel, über diese Art von Dateien. Ein .jar ist eigentlich nur ein einfaches Archiv, in dass du mehrere Dateien packen kannst. Der Vorteil liegt klar auf der Hand, du hast eine Datei, die du so komplett weiter reichen kannst. Zudem gibt es noch verschiedene Möglichkeiten, weitere Dinge einzubinden / anzustellen. So ist ein jar auch gepackt (weiß gar nicht ob es auch unkromprimiert wie tar verwendet werden kann, glaube aber es war so). Dann hast du noch eine ganz wichtige Datei, das Manifest. Hier kannst du zum Beispiel eine main-class bekannt machen. Steht eine solche in der Manifest und enthält eine main Methode, ist dein jar direkt startbar.
Zu dem Umgang mit Jars kann ich dir eigentlich nur ein Buch bzw. die Sun Seiten nahe legen, da du hier wirklich vollständig die Möglichkeiten erklärt bekommst. In der Regel hat jede IDE (z.B. Eclipse) gleich eine gute Kapselung, so dass du auch bei jars nicht die Kommandozeile bemühen musst (es aber kannst).
Einer der wichtigsten Vorteile von jars ist es, dass du diese transparent in den Classpath einbinden kannst. Die Datei wird dabei einfach als Pfad behandelt. Alle .class Dateien in diesem jar kann Java wie lokale .class Dateien, die entpackt auf der Platte liegen behandeln. Die Standardklassen liegen auch als .jar in deiner JRE / dem JDK vor.

Zitat von Simon1988:

Und ich wieder
2 ) So ich habe eine Klasse in einer Datei und gebe deren Pfad an. Danach erzeuge ich ein Objekt dieser Klasse und speicher das Objekt als ein JObject. Bei dem Constructor vder Klasse wird aber eine anderes Objekt einer anderen Klasse automatisch erzeugt. Meine Frage ist: Wie können sich selbstgeschriebene Klassen untereinander finden. ?!
ist das einfach so möglich ? oder müssen die Dateien in einem Ordner liegen? Finden die sich nur wenn sie in eimem gemeinsamen jar oder .java bleiben (so wie sie eben programmiert wurden) ?

Ja, jetzt verstehe ich nicht wirklich was du machen möchtest. Sollen sich zwei Java Klassen unter Delphi finden?
Wenn der Konstruktor etwas erzeugt, so tut er dies ja eigentlich in Java. Dies passiert damit automatisch und ohne deinen Eingriff in Delphi. Was du mit dem Finden von verscshiedenen Klassen meinst weiß ich jetzt nicht genau. In Java wird eine Klasse qualifiziert aufgerufen. Klassen liegen in einem Package, welches wiederum in einem package liegen kann usw.
Jedenfalls würdest du eine Klasse ungefähr so anlegen:

Code:

package.subpackage.Class1 = new package.subpackage.Class1();

Durch das package.subpackage legst du fest, wo Class1 herkommt. In einem Package darf dann nur eine Klasse mit diesem Namen liegen. Der Einfachheit halber kannst du eine Klasse auch samt package importieren. Hier steht einmal im Kopf deiner .java Datei der import Befehl. Alle Klassen im gleichen package sind aut. bekannt. Solche die du hier importierst können ohne das Präfix des package verwendet werden. Hast du jetzt aber zwei Klassen mit gleichem Namen, stellst du wiederum durch die Qualifizierung sicher, dass du die richtige Klasse adressierst (ansonsten würde die Reihenfolge der Imports entscheiden).
Ja, wie gesagt, was du hier mit finden meinst, da bin ich mir nicht ganz sicher. Die einzelnen Dateien müssen halt im Suchpfad von Java für Klassen liegen (der so genannte Classpath).
Ja, mehr als eine Klasse in eine .java Datei zu packen ist immer ganz schlecht! Die Ordner Struktur bildet eigentlich nur die Struktur der Packages ab. Ob die Dateien in einem Ordner oder in einem jar (und hier in einem Ordner des Archivs) liegen ist letztlich egal. Du musst die .class Dateien immer in den Ordner packen, der dem package entspricht. Ein Unterordner entspricht also einem subpackage. Das oberste Element (der Wurzelordner) muss hier im Classpath liegen, damit Dateien relativ zu diesem Pfad gefunden werden können (für ein .jar File heißt das, dass dieses .jar im Classpath liegen muss).

[Simon1988]

OK. ich werd mal genauer.

Also ich hab in der DateiA eine klasse namens Map. erzeuge ich ein Objekt dieser Klasse so wird automatisch beim Erzeugen der Klasse vom Java Quelltext aus ein weiteres Objekt einer anderen Klasse die aber in DateiB vorliegt.

Ich gebe also den Classpath der DateiA an um die Klasse und den Konstruktor zu finden und rufe den auf.
Meine frage ist nun . Kann der Constructor die DateiB (und damit die weitere Klasse) einfach so finden?



und die zweite frage war eben zum Jar. Da sind alle meine Klassen gespeichert (Auch DateiA und DateiB).
Wie rufe ich genau den Path auf ?
cls := self.jvm.JniEnv.FindClass('SpatialCommander.jar\Da teiA');??

[Der_Unwissende]

Zitat von Simon1988:

OK. ich werd mal genauer.

Danke! Sorry, aber so genau wie möglich ist halt immer gut. Im Moment besonders, sitze schon ein Weilchen an der Übersetzung von ein paar Modulen, die schlecht dokumentiert, nur zu sehr eingeschränkten Versionen kompatibel und anstrengend sind (ich hasse Makefiles!!!! Besonders wenn es kein sauberes configure Skript gibt).

Zitat von Simon1988:

Also ich hab in der DateiA eine klasse namens Map. erzeuge ich ein Objekt dieser Klasse so wird automatisch beim Erzeugen der Klasse vom Java Quelltext aus ein weiteres Objekt einer anderen Klasse die aber in DateiB vorliegt.

Ich gebe also den Classpath der DateiA an um die Klasse und den Konstruktor zu finden und rufe den auf.
Meine frage ist nun . Kann der Constructor die DateiB (und damit die weitere Klasse) einfach so finden?

Eine interessante Frage, die uns der Theorie des Classpath näher bringt. Wie bereits gesagt (geht eigentlich auch aus dem Namen hervor), der Classpath ist der reine Javasuchpfad. Alle Klassen die Java verwendet müssen in diesem Pfad liegen. Ein Teil des classpath liegt automatisch im JRE (irgendwo müssen ja die Standardklassen herkommen), der Ordner external (oder so) ist dann der Ablageort für global verwendete Bibliotheken/Klassen. Ich scheue hier nicht den Vergleich mit dem Windows/system32 Ordner. Man kann zwar sicher sein, dass hier gesucht wird, aber es ist ein Ort den man meiden sollte. Je voller dieser Ordner ist, desto unübersichtlicher wird die Sache. Zudem kommt es dann schnell zu den Versionskonflikten und einer Jar-Hölle (oder so ähnlich), die man von DLLs kennt. Einfach kein schöner Ort.
Viel viel besser ist es, wenn man in dem Ordner, indem das Programm liegt die richtige Version der verwendeten Bibliotheken/Klassen findet.
Java kann per Schalter mehrere Pfade für eine JVM in den Classpath aufnehmen.

In der Delphikapselung gibst du den Java-Classpath im Konstruktor der TJVM an. Hier wird der Ort angegeben, in dem alle Packages liegen, die du zusätzlich zu den Standardbibliotheken verwendest. In den Beispielprogrammen von mir ist dies der Unterordner Java/bin. Jetzt fällt dir sicherlich auf, dass du aber keine Datei in diesem Unterordner findest, erst im Ordner /Java/bin/package1/subpackage/ liegt dann die .class Datei.
Wenn du dir die .java Datei der Klasse anschaust, findest du hier auch den Eintrag package package1.subpackage; Ist natürlich kein Zufall. Ein Java Package wird auf die Verzeichnisstruktur abgebildet. Java sucht also die Klasse A aus dem Package package1.subpackage im Classpath. Dazu wird nach dem Ordner package1 gesucht, der einen Unterordner subpackage hat, in dem die Klasse liegt. Weitere Subpackages würden weitere Unterordner mit sich bringen. Dateien eines Packages befinden sich damit natürlich immer im gleichen Ordner. Ich hoffe/denke soweit ist erstmal alles klar?

Ja, der Vollständigkeit halber sei hier natürlich noch gesagt, die Klasse allein (ohne Ordner und Unterordner) kann nicht verwendet werden. Liegt sie in einem Package muss diese Struktur auch abgebildet sein. Dies ist einfach schon deshalb erforderlich, da sonst die Klasse A aus package1 und die völlig andere Klasse A auf package2 nicht einfach irgendwo liegen dürfen, man möchte sie schließlich unterscheiden!

Ok, was hat das alles mit deiner ursprünglichen Frage zu tun? Ganz einfach:
Klasse A möchte eine Instanz von Klasse B erzeugen. Lässt sich Klasse B im Classpath finden, ist das kein Problem. Liegt Klasse B im selben Package wie A tritt nie ein Problem auf. Ansonsten musst du schauen. Liegen die Packages im selben Wurzelordner (im Beispiel wäre dies der Unterordner Java/bin/), würde B gefunden werden (Java/bin/ wird komplett in den Classpath übernommen).
In der Regel wirst du genau diesen Fall haben. Da ich gleich auf die .jar Dateien eingehen werde, lasse ich hier den anderen Fall einfach mal aussen vor (ich kann da eh nichts zu sagen!).

Zitat von Simon1988:

und die zweite frage war eben zum Jar. Da sind alle meine Klassen gespeichert (Auch DateiA und DateiB).
Wie rufe ich genau den Path auf ?
cls := self.jvm.JniEnv.FindClass('SpatialCommander.jar\Da teiA');??

Oh, da hab ich wohl die .jar Dateien etwas falsch erklärt. Nochmal vorweg, die vollen Möglichkeiten eines .jar findest du in der Hilfe von Sun.
Ein .jar File ist wirklich eine tolle Erfindung. Das wichtigste Prinzip hast du schon benannt, du hast alle Klassen in einer Datei. Du kannst dein ganzes Programm einfach in eine einzige Datei packen und hast alles was du brauchst. Wichtig ist hier, dass du eine .jar Datei wie einen lokalen Ordner behandeln kannst. Du hast nicht direkt die Dateien A und B in dem jar File, sondern sie liegen in einem Unterverzeichnis, dass dem Package entspricht.
Für Java verhält sich ein .jar File transparent. Java merkt nicht, dass es ein Archiv ist sondern behandelt diese Datei wie einen normalen Pfad. Du kannst es dir so vorstellen, als ob Java das Archiv aut. entpackt und du dich nun im Wurzelordner des entpackten Archivs befindest.
Das heißt, du kannst auch einfach eine komplette .jar in deinen Classpath aufnehmen und alle Packages die hier drin stecken sind aut. im Classpath zu finden (mit ihren Klassen natürlich). Auch für ein .jar sind nur die .class Dateien wichtig. Die .java sind immer QC und müssen nicht mitgeliefert werden. Ist nur Wichtig bevor du Kunden Quellcode aushändigst

Wenn du also die jar Datei in den Classpath steckst, kannst du ganz normal auf die Klassen zugreifen. Du musst Java nicht sagen, dass die in einem .jar liegen, dass merkt Java eh nicht. Du greifst ganz normal auf das Package zu.

Ich habe das bekannte Beispiel nochmal mit einem .jar erstellt. Also genau genommen habe ich einfach nur die Unterordner java/bin und java/src entfernt und ihren Inhalt in ein sehr einfaches jar gesteckt. Im jar findest du die Dateien TestClass.class/.java in dem Unterverzeichnis package1/subpackage (also dem eingetragenen Package).
TJvm bekommt nun als Classpath den Pfad der .jar Datei. Das Laden der Klasse erfolgt wie gewohnt mittels
cls := self.jvm.JniEnv.FindClass('package1/subpackage/TestClass); Diese Zeile ist wirklich unverändert. Ich hoffe das zeigt dir nochmal, dass die .jars wirklich transparent für Java sind. Hier gibt es keinen Unterschied zu einem lokalen Verzeichnis, es gelten die gleichen Regeln. Allerdings kann ein .jar File noch ein wenig mehr (was du dann in den Details der Manifest Datei findest).

An sich sind .jar Files sehr gut zu verwenden. Du hast eine einfache und kompakte Form alles wichtige zusammen zu halten und weiter zu reichen. Hier sollte auch noch mal deutlich gesagt werden, dass du so sehr leicht konsistente Versionen von Programmen erstellen und verwalten kannst. Liegen alle verwendeten (nicht Standardklassen) in deinem .jar, ist dieses so komplett und kann verwendet werden. Keine Versionskonflikte und (hoffentlich) keine anderen Probleme.
Wie gesagt, häufig werden .jars auch gleich startfähig ausgeliefert, dann hast du eine startbare Datei und musst dich um nichts kümmern.

Ja, anbei das veränderte / neue Beispiel. Hoffe das macht die Verwendung noch etwas klarer.

[Simon1988]

Ok .. war zu voreilig

hab grad gemerkt ich muss die dateien noch compilieren.
Mach ich morgen und dann sehen ma weiter .. aber danke schonmal

[Luckie]

Ich muss da noch mal nachhaken. Ich bin jetzt erstmal auf Delphi umgestiegen, damit ich irgendwie weiterkomme.

Mein Java-Programm sieht so aus:

Code:

public class HelloWorld {
    public static void main(String[] argv) throws Exception
    {
       HelloWorld test = new HelloWorld();
       int res = test.Test();
       
       System.in.read();
       
       System.out.print(res);
    }
    
    public int Test()
    {
       System.out.print("Hello, world\n");
       return 42;
    }
}

Jetzt will ich die Methode Test aufrufen:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Jvm := TJvm.create('..\..\JavaDemo');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  cls               : JClass;
  mid               : JMethodID;
  result            : JInt;
  instance          : JObject;
begin
  cls := self.jvm.JniEnv.FindClass('HelloWorld');
  Assert(Assigned(cls), 'Class HelloWorld not found');

  mid := self.jvm.JniEnv.GetMethodID(cls, '<init>', '()V');
  Assert(Assigned(mid), 'Constructor not found');

  instance := self.jvm.JniEnv.NewObject(cls, mid, []);
  mid := self.jvm.JniEnv.GetMethodID(cls, 'Test', '(I)I');
  Assert(Assigned(mid), 'Method "Test" not found');
  
  result := self.jvm.JniEnv.CallIntMethod(instance, mid, [10]);
  ShowMessage('Result = ' + IntToStr(result));
end;

Aber er findet die Methode Test nicht. Was mache ich da falsch?

OK, habe es gefunden. Die Signatur hat nicht gestimmt. So muss es aussehen:
mid := self.jvm.JniEnv.GetMethodID(cls, 'Test', '()I');

[Luckie]

Ein Problem ist jetzt doch noch aufgetaucht: Wie muss ich eine Methode aufrufen, die einen String zurückgibt?

Ich habe es so probiert:

Delphi-Quellcode:

procedure TForm1.btnStrTestClick(Sender: TObject);
var
  cls               : JClass;
  mid               : JMethodID;
  result            : JString;
  instance          : JObject;
begin
  cls := self.jvm.JniEnv.FindClass('HelloWorld');
  Assert(Assigned(cls), 'Class HelloWorld not found');

  mid := self.jvm.JniEnv.GetMethodID(cls, '<init>', '()V');
  Assert(Assigned(mid), 'Constructor not found');

  instance := self.jvm.JniEnv.NewObject(cls, mid, []);
  mid := self.jvm.JniEnv.GetMethodID(cls, 'strTest', '()Ljava/lang/String');
  Assert(Assigned(mid), 'Method "strTest" not found');

  result := self.jvm.JniEnv.CallObjectMethod(instance, mid, []);
  ShowMessage('Result = ' + String(result));
end;

Aber da findet er die Methode nicht:

Code:

    public String strTest()
    {
       return "Hello, world";
    }

Hat sich auch erledigt. Sio geht es:

Delphi-Quellcode:

mid := self.jvm.JniEnv.GetMethodID(cls, 'strTest', '()Ljava/lang/String;');
  Assert(Assigned(mid), 'Method "strTest" not found');

  result := self.jvm.JniEnv.CallObjectMethod(instance, mid, []);
  ShowMessage('Result = ' + jvm.JniEnv.JStringToString(result));

[Der_Unwissende]

Zitat von Luckie:

Ein Problem ist jetzt doch noch aufgetaucht: Wie muss ich eine Methode aufrufen, die einen String zurückgibt?

Fast richtig, aber bei Klassen musst vollqualifiziert mit ; eintippen, also
  mid := self.jvm.JniEnv.GetMethodID(cls, 'strTest', '()Ljava/lang/String;'); So sollte eigentlich alles klappen (ungetestet).