# JOGL Installation



## Pfaeff (23. Aug 2009)

Hallo,

Ich habe (mal wieder) das Problem, dass ich JOGL nicht zum Laufen bekomme. 
Ich wollte es eigentlich so haben, dass ich die .jar-Files in einen eigenen Ordner packe und die
DLLs in meinem Projektordner habe, da wo die .class-Files auch sind.
Jetzt habe ich die jogl.jar, sowie die gluegen-rt.jar im Verzeichnis C:\Programme\Java\JOGL\
Mein CLASSPATH sieht so aus: 





> .;C:\Programme\Java\JOGL\jogl.jar;C:\Programme\Java\JOGL\gluegen-rt.jar;


Beim Ausführen des Programms (Kompilieren geht anstandslos) bekomme ich allerdings folgenden Fehler: 





> java.lang.NoClassDefFoundError: javax/media/opengl/GLEventListener
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at java.security.SecureClassLoader.defineClass(Unknown Source)
> ...


Woran kann das liegen und warum tritt es beim Kompilieren nicht auf?

Vielen Dank

mfg


----------



## Spacerat (23. Aug 2009)

Von woaus führst du die Anwendung denn aus? Aus der IDE oder der Kommandozeile? Im 2. Fall musst du den Classpath erneut angeben.


----------



## Pfaeff (23. Aug 2009)

Meine IDE ruft soweit ich weiß auch nur "java" mit der entsprechenden Datei als Parameter auf. 
Ich habs vorher auch so gehandhabt und musste keine zusätzlichen Parameter angeben.
Hab halt den Rechner neu aufgesetzt und wollte es wieder einrichten und wundere mich nun, warum es nicht so funktioniert, wie ich das gerne hätte


----------



## Spacerat (23. Aug 2009)

Ok... mal angenommen es liegt nicht am CP, sondern daran, dass die JOGL-dlls nicht gefunden werden. Bei mir liegen diese Dlls immer in einem Verzeichnis ausserhalb des Projektes, sinnigerweise in einem separaten "$JOGL/bin". dieser Pfad müsste dann ebenfalls dem Systempfad (nicht dem Klassenpfad) angehängt werden. BTW.: Bibliotheken-Dateien haben meiner Meinung nach auch nichts in Projektpfaden verloren...


----------



## Pfaeff (23. Aug 2009)

Wenn ich jemand anderem das Projekt schicke, muss ich doch die dlls ohnehin mitliefern oder nicht? Daher finde ich es am einfachsten, alle benötigten/benutzten Bibliotheken in den Projektordner zu packen. Zusätzlich habe ich dort ebenfalls noch ein weiteres mal die .jar Dateien gelagert . Das mit dem Systempfad hatte ich bereits ausprobiert, das hat nicht funktioniert.


----------



## Spacerat (23. Aug 2009)

Pfaeff hat gesagt.:


> Wenn ich jemand anderem das Projekt schicke, muss ich doch die dlls ohnehin mitliefern oder nicht? Daher finde ich es am einfachsten, alle benötigten/benutzten Bibliotheken in den Projektordner zu packen. Zusätzlich habe ich dort ebenfalls noch ein weiteres mal die .jar Dateien gelagert .


Gute Idee... dachten schon viele... Hier mal ein gelungenes Beispiel dafür, warum die Idee dann doch nicht soo toll war. http://www.java-forum.org/codeschni...i-programmierung-meets-jogl-3.html#post479198


----------



## Pfaeff (23. Aug 2009)

Eigentlich kann man nicht erwarten, dass eventuell unerfahrene Benutzer, die sich ein Programm herunterladen erst noch auf der JOGL-Seite nach den richtigen DLLs suchen müssen. Ich selbst hatte schon Schwierigkeiten dabei. In der Hinsicht muss es eine bessere Lösung geben. Ansonsten macht man es so, dass wenn man seine Software verbreiten will, man dann entsprechende Versionen für unterschiedliche Systeme zum Download anbietet oder alle DLLs mitliefert. 

Jedoch ändert das nicht sonderlich viel an meinem Problem, welches weiterhin besteht. Ich habe ebenfalls schon versucht die DLLs durch andere zu ersetzen, bisher hat es leider nicht geklappt.


----------



## Spacerat (23. Aug 2009)

Liegen die Klasse die ausgeführt werden soll und die dlls etwa nicht im selben Verzeichnis? Etwa in dieser Art:
	
	
	
	





```
C:\project\bin\Testclass.class
C:\project\used.dll
```
"Testclass" müsste im Verzeichnis "bin" ausgefürhrt werden. Und wenn "C:\project" nun nicht im Systempfad liegt, würde "used.dll" nicht gefunden. Wenn's daran nicht liegt, wären die Verzeichnisstruktur des Projektes (Auszugsweise), der Systempfad und der Klassenpfad mal interessant anzusehen.


----------



## Marco13 (23. Aug 2009)

Spacerat hat gesagt.:


> Gute Idee... dachten schon viele... Hier mal ein gelungenes Beispiel dafür, warum die Idee dann doch nicht soo toll war. http://www.java-forum.org/codeschni...i-programmierung-meets-jogl-3.html#post479198



Jaaa, hack' noch drauf rum ;(  Amer mal im ernst: Ich find's auch blöd. In einem anderen Thread kam dann die Empfehlung, die Webstart-Version zu nehmen, aber damit hab' ich's zumindest auf die schnelle auch nicht hingekriegt ... müßt' ich aber ggf. nochtmal testen. Eigentlich braucht er ja nur einen Haufen DLLs oder .SOs... kann doch nicht so schwer sein, das in einem one-fits-all-Paket zusammenzustellen ???:L


----------



## Spacerat (23. Aug 2009)

Marco13 hat gesagt.:


> Jaaa, hack' noch drauf rum ;(  Amer mal im ernst: Ich find's auch blöd. In einem anderen Thread kam dann die Empfehlung, die Webstart-Version zu nehmen, aber damit hab' ich's zumindest auf die schnelle auch nicht hingekriegt ... müßt' ich aber ggf. nochtmal testen. Eigentlich braucht er ja nur einen Haufen DLLs oder .SOs... kann doch nicht so schwer sein, das in einem one-fits-all-Paket zusammenzustellen ???:L


..."ruhig Brauner"... . Das Beispiel war das erste, welches in von mir verfolgten Threads gefunden habe (im übrigen recht interessant... vor allem der Versuch, es mit LG3D vergleichen zu wollen. Ich schreib' wohl auch mal meine Meinung dazu).
Wenn man es genau nimmt, ist es an den Entwicklern von JOGL, stets eine One-Fits-All-Version zu verbreiten (was sie meines Wissens auch tun: z.B. "jogl-1.1.2-pre-20080523-webstart.zip"). Wenn man nun selbst Anwendungen verbreitet, müsste man natürlich auch selbst dafür sorgen, dass immer eine passende Bibliothek mit verbreitet wird, aber eben so, dass sie so installiert wird, dass sie möglicherweise auch mit anderen Applikationen verwendet werden kann. Dazu kann man entweder Web-Start verwenden, dann wäre eine Internet-Verbindung vorraussetzung, oder die gesammte Distribution der Bibliothek mit verbreiten (auf CD oder wie auch immer) und im Bedarfsfall per eigener Installationsroutine mit installieren bzw. mit installieren lassen. Und je mehr unerfahrene Benutzer die Verbreitete Software nutzen sollen, desto besser sollte die Installationsroutine dazu sein... z.B. InstallAnywhere


----------



## Pfaeff (24. Aug 2009)

Momentan habe ich alle Files im selben Verzeichnis, da es sich nur um ein kleines Testprojekt handelt. Das wird sich allerdings noch ändern. So hat es bisher aber immer funktioniert.


----------



## Marco13 (24. Aug 2009)

Naja, nur weil die Version "Webstart" heißt, setzt die ja eigentlich keine Internetverbindung voraus: Es würde ja schon reichen, die 2, 3 JARs in ein Paket zu legen, und die ganzen
jogl-windows-i586.dll
jogl-windows-i64.dll
jogl-linux-i586.so
...
und dann innerhalb der JAR die zum Betriebssystem und der Architektur passende Bibliothek mit System.loadLibrary zu laden. Gut, dann liegen bei jedem ca. 5 Bibliotheken unbenutzt rum, aber der unerfahrene Anwender wird damit leben müssen, und der erfahrene kann sie löschen, wenn er will.


----------



## Pfaeff (25. Aug 2009)

Ich habs bisher immernoch nicht hinbekommen. Mich wundert halt, dass der Fehler nicht beim Kompilieren auftritt, also schließe ich mal daraus, dass es vielleicht doch etwas mit den Laufzeitbibliotheken zu tun hat, aber wie kann das sein?


----------



## Marco13 (25. Aug 2009)

_Eigentlich_ gar nicht: Die NoClassDefFound-Sache deutet darauf hin, dass er eine (in einer JAR enthaltenen) Klasse nicht findet - wenn er eine DLL nicht finden würde, würde AFAIK eine ganz andere Meldung kommen. Allerdings braucht er diese Klasse _eigentlich_ auch schon beim compilieren. Hast du mal wirklich sowas gemacht wie
javac -DEIN_CLASSPATH Bla.java
java -DEIN_CLASSPATH Bla
(also zweimal wirklich den gleichen CP verwendet)?


----------



## Pfaeff (25. Aug 2009)

Interessant... Das Problem scheint an SciTE zu liegen. Wenn ich normal über die Konsole "java Test" aufrufe klappt es wunderbar. Jetzt ist nur noch die Frage, warum SciTE das nicht hinbekommt (ruft ja schließlich auch nur java auf).
Liegt vermutlich daran, dass SciTE diesen Aufruf hier durchführt: "java -cp . Test" 
Ich denke mal, dass dadurch der CLASSPATH überschrieben wird und es deshalb nicht funktioniert.

Danke


----------



## Marco13 (25. Aug 2009)

Üblicherweise kann man sowas in der IDE irgendwo einstellen - einfach mal in den Optionen rumsuchen....


----------

