dll's in jar einbinden

[xZise]

Moin,
wir haben ein Projekt gestartet mit OGL und brauchen dazu einige dll's und unter Eclipse funktioniert es, aber wenn ich es in eine jar exportiere und dann ausführe, fehlen ihn libarys. Und wenn man sich das Archiv anschaut, fehlen einen die ganzen dll's. Wie kann man das verhindern?

Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:56)
Caused by: java.lang.VerifyError: class com.sun.opengl.impl.GLContextImpl overrides final method isCreated.()Z
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$000(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)
        at window.Window.<init>(Window.java:89)
        at OpenSCD.main(OpenSCD.java:26)
        ... 5 more

MfG
Fabian

 

[Gastredner]

Vielleicht würde es funktionieren, wenn ihr die DLLs in eurem Eclipse-Projekt in einen Source-Ordner bzw. ein package legen würdet.
Allerdings denke ich nicht, dass es am Ende überhaupt funktioniert - ich glaube, DLLs können nicht eingelesen werden, solange sie in einem Archiv stecken. Ihr müsstet daher die DLLs beim Start des Programmes extrahieren (z. B, in eine temporäre Datei - JNA arbeitet so). Dann könnt ihr die Bibliotheken aber auch gleich in einem externen Ordner mitliefern.

 

[xZise]

Und wie würde man dann an die Libaries kommen, wenn die in externen Ordnern liegt (was ja kein Beinbruch ist, wenn man div. OGL Anwendungen sieht )?

MfG
Fabian

 

[Gastredner]

Ich glaube, die müssen einfach nur im CLASSPATH liegen. Kann man entweder über einen entsprechenden Aufruf des Programms (über Batch oder Shellscript) oder das Hinzufügen des entsprechenden Eintrags in der MANIFEST.MF des Jars erreichen.
Kann aber auch sein, dass ich mich irre - DLLs werden zur Laufzeit aus allen Pfaden geladen, die in der Systemproperty java.library.path angegeben sind. Vielleicht wäre es also möglich, diesen beim Programmstart einfach zu ändern, bevor die Klassen mit nativen Abhängigkeiten geladen werden:

// z. B. irgendwo in main():
String pathSeparator = // Path-Separator für das aktuelle System finden- unter Windows wäre dies ;, unter Linux :.
String libraryPath = System.getProperty("java.library.path");
System.getProperties().setProperty("java.library.path", libaryPath + pathSeparator + "./native/opengl.dll");

Die native Bibliothek opengl.dll läge dabei in dem Verzeichnis native, welches im Arbeitsverzeichnis (bzw. dem Programmverzeichnis, wenn es denn das Arbeitsverzeichnis ist) zu finden ist.
Ich weiß nicht, ob das funktionieren würde - aber versuchen könnte man es ja mal.

 

[kay73]

Vielleicht wäre es also möglich, diesen beim Programmstart einfach zu ändern, bevor die Klassen mit nativen Abhängigkeiten geladen werden:

Funktioniert aber nicht. Du kannst den Setter ausführen, bekommst keinen Fehler, erhälst beim Lesen sogar die neue Zeichenkette, aber die VM interessiert das nicht. Die liest den Wert nur einmal beim Hochfahren. Man kann allerdings den Library Path als Startparameter

-Djava.library.path=...

setzen. Aber auch nicht so das Wahre, IMHO.

Wenn es nur um eine einzige DLL geht, würde ich in Eclipse einen Source Folder anlegen und dort die DLL hinkopieren. Dann im statischen Initialisierer der native Klasse mit Hilfe

getClass().getClassLoader().getResourceAsAsStream()

Zugriff auf das File holen und den Inhalt in ein Temp-File, das mittels

File.createTempFile()

erzeugt wurde, schreiben. Man kann

deleteOnExit()

setzen, dann hinterlässt es keinen Müll auf der Platte. Diese DLL mit absoltem Pfad mit

Runtime.load()

laden.

Fies wird es bei transitiven Abhängigkeiten: Wenn es um mehrere DLLs geht, muss man sich wohl oder übel irgendwie dem Search Path Used by Windows to Locate a DLL fügen. Blöd ist hier auch, dass man das "current directory" auch nicht setzen kann. Das kann je nach Startart auch das Java-Verzeichnis sein.

 

[Gastredner]

Man kann allerdings den Library Path als Startparameter

-Djava.library.path=...

setzen. Aber auch nicht so das Wahre, IMHO.

Ich finde diese Lösung eigentlich ganz nett. So kann man den Pfad jederzeit editieren und muss sich nicht erst noch um das Entpacken und das Lokalisieren der Bibliothek kümmern, wie man es bei deinem zweiten Vorschlag tun müsste (außerdem gibt es Probleme, wenn man mal einen Pfad mit einem ! in einem Verzeichnisnamen hat - ich hatte das Problem letztens mit JNA, welches ja genauso arbeitet).

 

[kay73]

Das Dumme mit dem Startparameter ist aber, dass sich das schlecht deployen lässt und man Gefahr läuft, den Pfad für den Prozess zu zerstören. Deshalb einen Zehnzeiler, der eine Ressource auf allen System wohldefiniert platziert. Darüber hinaus kann sogar vorher das BS abfragen und ggfs. die richtige DLL/.so auswählen. Die jOGL-Demos machen das meines Wissens auch so.

Was ich meinte ist, dass DLLs andere DLLs nachladen wollen: Es gibt ein Problem, wenn eine Funktion einen OpenGL call macht, der in einer opengl32.dll liegt. Wenn diese DLL nicht schon vorher korrekt da ist, wird es knifflig.

	protected String resourceFromClasspath (final String resource) throws IOException {
		
		final File tempFile = File.createTempFile("temp", ".tmp", new File(System.getProperty("java.io.tmpdir")));
		tempFile.deleteOnExit();
		
		final FileOutputStream fos = new FileOutputStream(tempFile);		
		final InputStream is = getClass().getClassLoader().getResourceAsStream(resource);
		int n;
		final byte buffer [] = new byte [4096];
		while(-1 != (n = is.read(buffer))) {
			fos.write(buffer, 0, n);
			fos.flush();
		}
		is.close();
		fos.close();
		
		return tempFile.getAbsolutePath();
	}

 

[thE_29]

Wenn du nur eine eigene DLL nachladen willst, dann kannst du diese aus dem JAR extrahieren und mit einem fixen Pfad nachladen!
Bei System.load() kannst du ja einen fixen Pfad angeben (dann muss die DLL nicht im Library-Path liegen).
Aber Achtung auf diesen DLL-Injection Bug, den Windows ja hat
Nicht das dir jemand eine böse DLL unterschiebt...

 

[xZise]

Moin,
durchsucht er nicht auch den Pfad wo die jar-Datei liegt? Und ich möchte eigentlich ungern den Classpath ändern

MfG
Fabian

 

[thE_29]

IMHO würde er auch den aktuellen Pfad als Library-Path ansehen (Classpath != Library-Path).
Müsstest halt austesten...

 

[xZise]

Moin,
das scheint wohl zu funktionieren:

public static void main(String[] args) {
    System.out.println("r93");
    System.loadLibrary("jogl");
    System.loadLibrary("gluegen-rt");
    System.loadLibrary("nativewindow_awt");
    System.loadLibrary("newt");
    System.loadLibrary("timer");
}

Leider kann ich damit es nicht unter 64 bit ausführen:

C:\...\jar>java -jar r93.jar
r93
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa
der.java:56)
Caused by: java.lang.UnsatisfiedLinkError: C:\...\jar\jogl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platfor
m
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at OpenSCD.main(OpenSCD.java:99)
        ... 5 more

Kann man irgendwie sagen: Lade die jogl.64.dll wenn du auf amd 64 bit und ansonsten die normale jogl.dll ?

MfG
Fabian

 

[kay73]

Du kannst versuchen, aus den System properties das Betriebssystem zu "erraten".

 

[xZise]

Aber das kann doch nicht sein?! Ich meine programmiere nur ich irgendwas mit OpenGL? Ich muss erraten ob ich Windows Dateien oder Linux Dateien benutzen soll (oder Mac). Und dann ob ich die x64 oder die x86er.

Das ist ja ganz toll

MfG
Fabian

 

[Guest2]

Moin,

Ich meine programmiere nur ich irgendwas mit OpenGL?

Nein.

Aber eine vorgefertigte Lösung für ein AllesInEins.jar gibt es imho von jogl oder lwjgl nicht. Wenn Deine Anwendung später über Webstart gestartet werden soll, geht das mit den natives darüber. Wenn Du die Anwendung einfach so starten willst, bleibt nur selber machen übrig.

Abfragen auf welchem OS die Anwendung gerade läuft geht mit:

        System.getProperty("os.name");
        System.getProperty("os.arch");

Gruß,
Fancy

 

[xZise]

Moin,
nagut dann mache ich das erstmal mit selber zusammen kopieren Erstmal soll auf jeden Fall die jar-Datei funktionieren.

Wir benutzten jogl und ich lade folgende Libaries:

System.loadLibrary("jogl");
System.loadLibrary("gluegen-rt");
System.loadLibrary("newt");
System.loadLibrary("nativewindow_awt");

Und bekomme diesen Fehler:

Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa
der.java:56)
Caused by: java.lang.UnsatisfiedLinkError: C:\[...]\nativewindow_awt.dll: Can't find dependent libraries
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at OpenSCD.main(OpenSCD.java:103)
        ... 5 more

Da ich leider kein x86 System habe, weiß ich nicht ob es mit den vorhandenen x86 dlls denn gehen würde.

Hier ist der Sourcecode. Einfach die r101.jar (sofern nicht vorhanden test.jar) nehmen und die dlls aus ../lib/win32 o.ä. in das Verzeichnis der jar kopieren.

MfG
Fabian

 

[Guest2]

Die Reihenfolge, in welcher die libs geladen werden, ist wichtig, da es da Abhängigkeiten untereinander gibt. Deine Fehlermeldung und Dein Code wundern mich, da es eigentlich schon in der ersten Zeile krachen müsste, da die jogl.dll unter anderem die gluegen-rt.dll braucht.

Als Beispiel: Klick

Bezieht sich aber auf eine neuere jogl Version, da gibt es mehr dlls die geladen werden müssen.

Gruß,
Fancy

 

[Guest2]

Nachtrag: Beim laden der libs bezieht sich x86 oder amd64 nicht auf die Hartware oder das OS, sondern auf die JVM. Wenn Du also z.B. Windows 64Bit und JVM 64Bit hast, brauchst Du auch die 64Bit dlls. Willst Du die 32Bit Version testen, kannst Du einfach die 32Bit JVM installieren.

Gruß,
Fancy

 

[hemeroc]

Man kann den LibraryPath auch zur Laufzeit setzen allerdings ist das ein wenig tricky und nicht wirklich sauber:

try {
	Class<ClassLoader> classLoader = ClassLoader.class;
	Field field = classLoader.getDeclaredField("sys_paths");
	field.setAccessible(true);
	field.set(classLoader, null);
} catch (Exception e) {
	throw new Error("Failed to make librarypath writeable.\n" + e.getMessage(), e);
}
String libraryPath = System.getProperty("java.library.path") + File.pathSeparator + "FullPathToLibraryFolder";
System.setProperty("java.library.path", libraryPath);

LG Hemeroc

 

[xZise]

Moin,
Kann man denn beide JVMs parallel installieren? Und ich habe mir schon gedacht das es an der JVM liegt, weil die führt ja die jar-Datei aus und lädt die Libraries. Und deshalb muss dort die Architektur stimmen.

Außerdem hat es schon jemand anderes unter x86 getestet und naja es funktionierte ebenfalls nicht, also der gleiche Fehler.

Lohnt es sich denn auf das Update oder gibt es viele Änderungen im Code? Würde ich die aktuellste Version von hier bekommen?

Und aktuell reicht es für mich, wenn einfach die dll's im jar-Ordner liegen.

MfG
Fabian

 

[Guest2]

Kann man denn beide JVMs parallel installieren?

Ja, das ist kein Problem. Wenn Du Java in die "normalen" Pfade installierst, "lebt" die 64Bit Version eh in "Programme", während die 32Bit Version in "Programme (x86)" landet. In Eclipse kannst Du auch beide JREs auswählen, so dass Du per Run Konfiguration wählen kannst, womit Du Dein Projekt aktuell starten willst.

Lohnt es sich denn auf das Update oder gibt es viele Änderungen im Code? Würde ich die aktuellste Version von hier bekommen?

Ja, das ist imho so ziemlich die aktuellste Version zurzeit. Mindestens die Namen einiger Pakete haben sich geändert, evtl. auch die Namen einiger Klassen. Aber keine neuen Features. Evtl. Bugfixes.

Außerdem hat es schon jemand anderes unter x86 getestet und naja es funktionierte ebenfalls nicht, also der gleiche Fehler.

Auch wieder erst bei der nativewindow_awt.dll? Sicher das nicht noch irgendwo jogl libs in einer anderen Version liegen die stören? Manche kopieren die gerne ins JRE oder Windowsverzeichnis, dann knallt es meistens, sobald eine andere Version ins Spiel kommt. Stimmen die Versionen der dlls den auch untereinander? Ältere jogl.dll neuere nativewindow_awt.dll würde z.B. auch krachen.

Gruß,
Fancy

 

[xZise]

Moin,
naja ja auch erst bei dieser dll. Und naja es waren halt die x86er Versionen der Dateien. Die hatten wir aber von Anfang an, und sollen vom nehe Tutorial stammen. Die x64er habe ich mir aber zusammengesucht.

Was mich aber gerade wundert: Wieso kann ich mit 64 bit JVM 32 bit dlls laden, aber nur innerhalb von Eclipse?

[edit]Huch... es ist ja auch Java x86 installiert. Und anscheinend kriegt der Updater das nicht gebacken. Wenn ich den der x86_64er ausführe, will er das x86er updaten [/edit]

[edit]Und wie kann ich dann in Eclipse definieren, dass er da die x64 libs laden soll? Die x86 Libs lädt er aktuell darüber, dass ich eine Userlib definiert habe und als native directory den Ordner mit den x86er Libs.[/edit]

[edit]So ich habe die jogl-2.0-pre-20100924-windows-i586.zip heruntergeladen und den Unterordner lib v2 angelegt. In diesem Unterordner dann die Ordner shared und win32. Im Ordner shared habe ich die jar-Archive jogl.all.jar und gluegen-rt.jar kopiert. In den Ordner win32 liegen alle dlls die ich in den Archiv finden konnte.

Dann habe ich bei Eclipse eine User Library Namens jogl v2 hinzugefügt. Diese habe ich (anstelle der jogl User Library) den Projekt hinzugefügt. Darin sind die beiden jar-Dateien aus den shared Ordner mit der Native Library Location den win32 Ordner.

Aber es kommt die Fehlermeldung: no jogl in java.library.path
Ich habe die User Lib auch in jogl umbenannt, keine Besserung. Und es ist egal ob ich die x86 oder x64 JVM nehme.[/edit]

MfG
Fabian

 

[xZise]

Moin,
naja gut ich wollte die jogl_desktop.dll laden, aber hatte gesagt er soll die jogl.dll laden. Jetzt lädt er das Programm immerhin in Eclipse. Aber es geht weiterhin nicht als jar:
[...]\nativewindow_awt.dll: Can't find dependent libraries

Der Code ist weiterhin:

System.loadLibrary("jogl_desktop");
System.loadLibrary("gluegen-rt");
System.loadLibrary("newt");
System.loadLibrary("nativewindow_awt");

MfG
Fabian

 

[xZise]

Moin,
kann mir keiner sagen, welche Abhängigkeiten nicht erfüllt werden? Weil mit Eclipse funktioniert es wunderbar.

MfG
Fabian

 

[Guest2]

Aus der Ferne lässt sich das nur schwer abschätzen, wo nun welche Dateien liegen und wann welche geladen werden. Da es in Eclipse geht und außerhalb nicht, würde ich tippen, das entweder was mit dem java.library.path nicht stimmt und / oder das außerhalb die falschen Dateien geladen werden.

Ich würde erstmal probeweise das System.loadLibrary() durch System.load() (mit dem vollen Pfad zur dll) ersetzen, um die Wahrscheinlichkeit zu erhöhen, dass immer dieselben Libs geladen werden.

Gruß,
Fancy

 

[xZise]

Moin,
danke für den Tipp: Aber mit System.load ändert sich leider nichts. Und es ist egal ob x86 oder x86_64.

Übrigens müsst ihr das nicht aus der ferne machen. So kann man von diesem Mercurical Repository den aktuellen Code herunterladen. Dort sind auch die Libs für x86 und x86_64 für Windows enthalten.

Btw: Gibts es keine Libs für x86-64 für Linux? Hier finde ich nichts entsprechendes. Nur eine OpenCL Implementierung.

MfG
Fabian

 

[Guest2]

Okay, erstmal unabhängig von den dlls bekomme ich beim Start von OpenSCD eine NPE:

Starting OpenSCD git-r0
Mesh: "Cube" meshparts(1):[ Vertices:8 Faces:6 ]
Exception in thread "main" java.lang.NullPointerException
	at org.openscd.ui.windows.Window.resize(Window.java:172)
	at org.openscd.ui.windows.components.VisibleComponent.<init>(VisibleComponent.java:39)
	at org.openscd.ui.windows.Window.<init>(Window.java:115)
	at org.openscd.ui.Window.tests(Window.java:80)
	at org.openscd.ui.Window.<init>(Window.java:101)
	at org.openscd.OpenSCD.main(OpenSCD.java:65)

Ja, bei der 64Bit Linux Version muss man imho zurzeit auf die, ein wenig älteren von hier zurückgreifen. Dafür gibt es da aber keine 64Bit Windows Version.


Gruß,
Fancy

 

[xZise]

Moin,
danke für den Test, weil er lädt die Libraries zuerst. Das heißt, die NPE tritt erst auf, nachdem alle Libraries erfolgreich (!) geladen wurden!

Das heißt so wie es aussieht, scheint es bei dir zu gehen, zumindest das laden der Bibliotheken. Und den Fehler habe ich vorerst auch behoben.

MfG
Fabian

 

[Guest2]

Das heißt so wie es aussieht, scheint es bei dir zu gehen, zumindest das laden der Bibliotheken. Und den Fehler habe ich vorerst auch behoben.

Aber auch nur mit der 32Bit VM. Die Fehlermeldung, die mit der 64Bit Version geworfen wird, rührt daher, das die jawt.dll (die ist Teil der VM) nicht geladen wurde, bevor die nativewindow_awt.dll geladen wurde. (warum auch immer)

Die jawt.dll direkt zu laden, geht aber auch nicht so einfach, da diese wiederum von der awt.dll abhängt. Diese wiederum darf nicht von Hand geladen werden.

Du kannst mal Folgendes versuchen:

        try {

            SwingUtilities.invokeAndWait(new Runnable() {

                @Override
                public void run() {

                    System.loadLibrary("jawt");
                    System.loadLibrary("jogl_desktop");
                    System.loadLibrary("gluegen-rt");
                    System.loadLibrary("newt");
                    System.loadLibrary("nativewindow_awt");


                }

            });

        } catch (final InterruptedException e) {

            e.printStackTrace();

        } catch (final InvocationTargetException e) {

            e.printStackTrace();

        }

Das geht bei mir dann, in Deinem Code, mit der 32Bit und der 64Bit VM.

Gruß,
Fancy

 

[xZise]

So jetzt funktioniert es zumindest bei mir. Woanders habe ich es noch nicht getestet.

Aber was genau macht die SwingUtilities.invokeAndWait()?

MfG
Fabian

 

[Gastredner]

Aber was genau macht die SwingUtilities.invokeAndWait()?

Die SwingUtilities.invoke*()-Methoden führen ein Runnable im Event-Dispatch-Thread von Swing aus, in welchem alle Oberflächenaktionen verarbeitet werden (alle Arten von Events, auch Änderungen an der GUI sollten nur dort vorgenommen werden). invokeAndWait wartet dabei auf das Ende der Ausführung des übergebenen Runnables. invokeLater würde nicht auf die Ausführung warten und stattdessen einfach im aktuellen Block fortfahren.

 

[xZise]

Das heißt, damit lade ich die AWT um dann die jawt.dll zu laden?

MfG
Fabian

 

[Gastredner]

Das heißt, damit lade ich die AWT um dann die jawt.dll zu laden?

Mit den invoke*-Methoden? Nein, der EDT ist ein ganz normaler Java-Thread, der von Swing zur Ereignisverarbeitung genutzt wird. Mit dem Laden von nativen Bibliotheken hat der nix zu tun.

 

[Guest2]

Indirekt schon. Durch das verlagern der System.loadLibrary() in den EDT wird sichergestellt, das Java das AWT Subsystem bereits vollständig gestartet hat. Damit ist dann auch sichergestellt, dass die awt.dll bereits durch Java geladen wurde. Die anderen (indirekt von awt.dll abhängigen) natives können dann eben gefahrlos nachgeladen werden.

Alternativ könnte auch kurz ein AWT Frame erzeugt werden, oder die OpenSCD z.B. von Frame erben. Aber schöner ist das alles nicht.

Gruß,
Fancy