JOGL Installation

[Pfaeff]

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)
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 sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javax.media.opengl.GLEventListener
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 sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 12 more
Could not find the main class: Test. Program will exit.
Exception in thread "main" >Exit code: 1

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

Vielen Dank

mfg

 

[Spacerat]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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