Hallo alle,
ich habe eine Entscheidung zu treffen. Mein kleines Program benötigt eine native library (rxtx). Diese Library muss ich aus dem JAR entpacken und laden. Nur wohin? Da ich sie dorthin entpacke benötige ich ja Schreibrechte.
Ich hätte es mir so gedacht: wenn der Ordner in dem sich die JAR-Datei befindet schreibbar ist, dann dorthin, wenn nicht ins Benutzer-Heimatverzeichnis.
Ist der Ansatz gut?
Edit: Sorry. Man muss doch immer entpacken. Reicht aber ein Temp um dann dynamisch zu laden. Hier der Artiekl von Stackoverflow den ich im Kopf hatte…
http://stackoverflow.com/questions/1611357/how-to-make-a-jar-file-that-include-dll-files
Hallo,
unter Windows gibt es ja die entsprechenden Pfade.
ggf. unter „All Users“.
Bei JOCL mache ich es ähnlich wie in dem Stackoverflow-Post angedeutet: Die Datei wird nach
System.getProperty(“java.io.tmpdir”)
entpackt und von dort aus geladen.
Ein bißchen aufpassen: File#createTempFile erzeugt eine Temporäre Datei, was ideal dafür erscheint - IST es aber nicht: Wenn so eine “temporäre” DLL erstmal geladen wurde, kann sie nicht mehr automatisch mit “deleteOnExit” gelöscht werden. (Ich hatte dann mal die Beschwerde, dass jemand hunderte Temp-DLLs in seinem Temp-Verzeichnis hatte :o )
Mahlzeit,
ja genau das ist ja das Problem dabei, die JVM gibt ja erst nach dem Beenden des JVM-Prozesses die Resource wieder frei (bzw. tut es das Betriebssystem). Mein Programm wird daher ganz sicher nicht “spurlos” bleiben, was ich bevorzugt hätte.
Ich denke, dass am elegantesten der Weg mit dem Benutzerheimat-Verzeichnis ist, beim Programmstart alle früheren verbliebenen .dll-Dateien löschen und dann bei Bedarf neu entpacken. Alles andere erscheint mir Humbug.
Besonders ungünstig erscheint mir der temp-Ordner. Ich weiss gar nicht, gibts bei dem irgendwelche definierten Löschvorgänge ohne Einschreiten des Benutzers? Wie sieht das auf einer anderen Plattform (zB Linux) aus?
Moin,
ich mache es immer nach diesem Schema: Load native libraries from jars
Wenn das Programm sauber beendet wird, sind die DLLs am Ende auch weg. Lediglich wenn das Programm “hart” beendet wird (z.B. über den Taskmanager), bleiben Dateien übrig. Diese lösche ich dann beim nächsten Programmstart.
Viele Grüße
Fancy
Nun, bei JOCL habe ich dem Dateinamen eine Versionsnummer verpasst, und akzeptiere, dass nun potentiell alle paar Monate eine wenige KB große DLL im Temp-Verzeichnis dazukommt -_- Alternativen gibt es nicht soo viele, das Problem (dass man die DLL nicht löschen kann) ist allgemein bekannt, aber mehr als krampfigste Versuche (!) von Workarounds hatte ich bisher (d.h. als ich damals danach gesucht habe) nicht gefunden. Wenn du eine Lösung findest, würde ich gerne davon hören 
EDIT: Ah, Fancy (angemeldet!?) auch hier - darauf hattest du schonmal verlinkt, aber irgendwie ist das wohl in meiner (viel zu langen) „Das muss ich mir mal ansehen“-Liste untergegangen 
[ot]Da EagleEye scheinbar Entwickler ist und vermutlich weder Buchhändler noch Werbeheuschrecke, habe ich mich mal zu einer Anmeldung hinreisen lassen. ;)[/ot]
Viele Grüße
Fancy
Bei Linux wäre deine DLL nutzlos, für Linux müsstest du deinen Code eventuell abändern, je nachdem was deine DLL da so treiben soll, und für Linux neu kompilieren. Wäre dann übrigens eine so-Datei.
Der Kernel versucht im Normalfall (außer jemand benutzt einen Custom-Kernel, der in der Hinsicht abgeändert wurde) beim Start das Temp-Verzeichnis (/tmp) zu leeren. Da bleibt also nach einem Neustart nichts über. Windows scheint aber gerne solche Dateien zu behalten, daher kann der Temp-Ordner da gigantische Ausmaße annehmen und sollte ab und an sowieso geleert werden, erst recht, wenn man Tools benutzt, die da fleißig rumspielen.
Die Lösungen für diese All-in-one-JARs berücksichtigen normalerweise, dass die Dateiendung vom OS abhängt Die Frage, wo man sie hinpackt und wie man sie ggf. wieder löscht, stellt sich bei allen OSen.
Also ich habe mich jetzt für das Benutzerverzeichnis entschieden. Das scheint mir doch eleganter zu sein, als die Dateien in das Temp-Verzeichnis zu drücken.
Für RXTX hab ich vor einiger Zeit einen Fork gebastelt der das Problem mit “mitbringen” und Laden der Nativen Lib löst: http://dev.root1.de/projects/rxtx-rebundled
Hatte die Lösung auch in der RXTX Mailingliste angeregt und dem Chef-Entwickler direkt mitgeteilt. Bekam aber keine Reaktion. Deshalb der kleine Fork.