# dll's in jar einbinden



## xZise (11. Sep 2010)

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 (11. Sep 2010)

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 (11. Sep 2010)

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 (11. Sep 2010)

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 (12. Sep 2010)

Gastredner hat gesagt.:


> 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 (12. Sep 2010)

kay73 hat gesagt.:


> Man kann allerdings den Library Path als Startparameter
> 
> 
> 
> ...


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 (12. Sep 2010)

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 (13. Sep 2010)

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 (13. Sep 2010)

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 (13. Sep 2010)

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


----------



## xZise (18. Sep 2010)

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 (18. Sep 2010)

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


----------



## xZise (20. Sep 2010)

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 (20. Sep 2010)

Moin,



xZise hat gesagt.:


> 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 (27. Sep 2010)

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 (27. Sep 2010)

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 (27. Sep 2010)

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 (27. Sep 2010)

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 (28. Sep 2010)

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 (28. Sep 2010)

xZise hat gesagt.:


> 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.




xZise hat gesagt.:


> 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.  




xZise hat gesagt.:


> 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 (28. Sep 2010)

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 (29. Sep 2010)

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 (4. Okt 2010)

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

MfG
Fabian


----------



## Guest2 (4. Okt 2010)

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 (6. Okt 2010)

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 (6. Okt 2010)

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 (6. Okt 2010)

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 (6. Okt 2010)

xZise hat gesagt.:


> 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 (6. Okt 2010)

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

Aber was genau macht die _SwingUtilities.invokeAndWait()_?

MfG
Fabian


----------



## Gastredner (7. Okt 2010)

xZise hat gesagt.:


> 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 (7. Okt 2010)

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

MfG
Fabian


----------



## Gastredner (7. Okt 2010)

xZise hat gesagt.:


> 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 (7. Okt 2010)

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


----------

