Hi,
ich glaube ich muss nochmal etwas korrigieren, was ich einst (lang lang ist's her) sagte. Dein Fehler liegt wahrscheinlich immer noch an der JVM.dll. Ich sagte damals etwas dumm, dass du auch nur die .dll kopieren kannst. Das stimmt so natürlich null!
Das Problem ist, dass weitere Files benötigt werden, deren Pfad relativ zur .dll ist. An sich wäre es eh eine unschöne Lösung eine Datei in jeden Ornder zu kopieren, der diese benötigt (würde ihren Sinn stark in Frage stellen!). Ich hätte einfach deutlicher sagen sollen, dass es eigentlich keine ernsthafte Alternative ist (schätze du hast die Lösung gewählt).
Es gibt aber weiterhin zwei Möglichkeiten, die die schon im alten Beitrag nannte gilt immer noch. Du musst einfach den Suchpfad unter Windows so setzen, dass die
dll mit in diesem liegt. Das Problem ist allerdings, dass du damit natürlcih auf jedem Rechner auf dem dein Programm läuft den Pfad der jvm.dll ermitteln und in die PATH Variable aufnehmen musst. Gerade bei
W2k und XP (und Nachfolger) heißt dass, das du dich wohl einmal als Admin anmelden musst, nicht sehr praktisch.
Schöner ist es, wenn man die
Dll einfach dynamisch lädt. Immerhin sind das dynamische Bibliotheken, ihr Sinn liegt also gerade darin. Dynamisch heißt hier einfach, dass du nicht statisch gegen eine
dll linkst sondern die
dll erst zur Laufzeit bekannt ist. Dann wird in dieser
dll die Adresse des Einsprungpunktes (einer Funktion) gesucht und diese dann ausgeführt.
Der Vorteil liegt klar auf der Hand, du kannst eine .exe direkt starten und musst dich nicht kümmern, wo die jvm.dll liegt. Genau gesagt kümmert sich dein Programm darum, also einmal (beim Programmieren) mussst du dich drum kümmern, aber eben nicht mehr bei der Ausführung.
Bleibt also nur das Problem, wie du den Pfad der JVM.dll findest und wie deine TJavaVM von diesem Pfad erfährt. Letzteres (hab mir jetzt auch mal JavaD etwas näher angeschaut) ist gar kein Problem. Es gibt einen überladenen Konstruktor der TJavaVM. Diesem kannst du auch den Pfad zur JVM.dll übergeben.
Wo also findet man diese Datei? Festplatte durchsuchen könnte ein Weilchen dauern und wäre kaum sinnvoll. Standardpfade sind etwas worauf man sich nie verlassen sollte (schon Programme die einen Ordner 'Program Files' anlegen nerven doch). Aber Suns JRE trägt sich ganz vorbildlich in die Registry ein. Hab mal geguckt, auf meinem Rechner stimmen Suns Angaben natürlich völlig mit der Position der Schlüssel überein.
Deshalb häng ich dir jetzt auch mal einen kleine Wrapper an. Der erzeugt dir die TJavaVM und TJniEnv und sucht dabei automatisch den Pfad zur JVM.dll. Du kannst einfach eine neue Instanz mit TJvm.Create(<ClassPath>) erzeugen. In dem Pfad klappt dann auch ein '.' oder ähnliches. Schöner ist natürlich, wenn du für Java-Klassen einen eigenen Ordner anlegst.
Mit dem Aufruf des Konstruktors wird jedenfalls eine TJavaVM angelegt (also die JVM.dll geladen). Treten keine Fehler auf, so hat alles geklappt (es gibt keine andere Rückmeldung).
Ja, vielleicht hilft es dir erstmal weiter. Da mich das Thema auch gerade interessiert werde ich es mir mal noch näher angucken. Hatte bisher immer den umgekehrten Weg behandelt, dass ein Java-Programm nativen Code ausführen muss. Da sieht vieles natürlich ähnlich aus (immerhin läuft alles über die gleiche Schnittstelle), aber natürlich muss man sich da nicht um das Laden der JVM sondern um das laden der Biblitheken in Java kümmern (was recht einfach ist!).
Also wenn ich jetzt so weiter mache, wie im angegebenen Beispiel bekomme ich noch Fehlermeldungen (bei Aufruf einer Methode), aber mal schauen, denke ich mach da nur noch was falsch.