Seit dem Erscheinen der Java-SE-6-Version sind Java 2D und JOGL interoperabel. Dadurch kann JOGL Swing-Komponenten über das OpenGL-Rendering legen, OpenGL-3D-Grafiken über das Java-2D-Rendering zeichnen, Java-2D-Grafiken über das 3D-OpenGL-Rendering zeichnen und so weiter.
JOGL wird momentan von der Game Technology Group entwickelt, die zu Sun Microsystems gehört. Die Programmbibliothek gilt als Referenzimplementierung für JSR-231 (Java Bindings for OpenGL).
 Der Screenshot zeigt das Rendering mit OpenGL unter der Verwendung von JOGL. Er liefert ein Beispiel für Lichtbrechungs- und Spiegelungseffekte. |
Das Design von JOGL
In JOGL erfolgt der Zugriff auf die Basis-OpenGL-C-API über JNI-Aufrufe (Java Native Interface). Das zugrunde liegende System muss also OpenGL unterstützen, damit JOGL funktioniert. JOGL unterscheidet sich von so manch anderen Java-OpenGL-Wrapper-Bibliotheken: Es verwendet kaum die prozedurale OpenGL-API und arbeitet mit nur wenigen Wrapperklassen. Es versucht also nicht, die OpenGL-Funktionalität auf das objektorientierte Programmierparadigma abzubilden.
Den JOGL-Code erstellen die OpenGL-C-Header-Dateien großteils automatisch. Dafür kommt das Konvertierungstool Gluegen zum Einsatz. Es wurde eigens zur Vereinfachung der Entwicklung von JOGL programmiert. Diese Design-Entscheidung hat Vor- und Nachteile.
OpenGL ist eher eine Zustandsmaschine und prozedural angelegt. Das passt eigentlich nicht zur typischen Verfahrensweise des Programmierens unter Java. Viele Programmierer finden das sehr lästig. Das unkomplizierte Mapping der OpenGL-C-API auf Java-Methoden erleichtert aber die Konvertierung bestehender C-Anwendungen und des Beispielcodes enorm. Durch die dünne Abstraktionsschicht von JOGL funktioniert die Laufzeitausführung sehr effizient. JOGL ist jedoch viel schwieriger zu programmieren als Bibliotheken mit höherer Abstraktion, beispielsweise Java 3D. Da der größte Teil des Codes automatisch erstellt wird, können Veränderungen an OpenGL auch rasch zu JOGL hinzugefügt werden.
