uses technices

Sprache

Ziel unserer Entwicklung war es eine plattformunabhängige Umgebung zu schaffen, die nicht an harte Legitimationen von Lizenzgebern gebunden ist. Die Sprache Java1 von Sun bietet gute Möglichkeiten, Kompatibilität auf allen Betriebssystem zu schaffen und dabei nicht auf Komfort beim Programmieren zu verzichten. Eine Implementierung als Web oder Handy Anwendung wäre dank der Struktur von Java ohne Probleme möglich. Jedoch gibt es auch Kehrseite der Medaille, die wir hier nicht verschweigen wollen. Bei Java handelt es sich um eine Bytecode-kodierte Sprache. Beim Ausführen wird das Programm jeweils neu Interpretiert von einem auf das Betriebssystem angepasstem Parser. Dieses geschieht relativ schnell, bringt jedoch dementsprechende Performanceeinbußen. Es gibt mehrere Ansätze, Java auch als normale Binärdatei zu kompilieren (gcj2), jedoch geht dann natürlich wieder der betriebssystemunabhängige Ansatz verloren.

OpenGL

Um OpenGL in Java nutzen zu können, wird ein Wrapper auf die systemspezifischen OpenGL Dateien benötigt.
Man könnte diesen selbst schreiben, indem man jede einzelne Funktion mit einer dem äquivalent „wrapped“. Dabei müsst der Code jedoch jeweils an die Betriebssystem Libraries angepasst werden.
Eine Beispielhafte eines Wrappers könnte so aussehen:

public class MyGL {
		public native void glVertex3fv(float[] a);
	
		static {
			System.loadLibrary("OpenGL");
		}
}

Falls man eine solche Implementierung für eine größere Klasse vollziehen möchte, sollte man jedoch nicht auf die von Java dafür vorgesehene Funktion des JNI3 verzichten.
Es gibt für diesen Zweck mehrere Ansätze, die alle jedoch die meisten Funktionen von OpenGL in Java ermöglichen. Die zwei bekanntesten bzw. etabliertesten sind LWJGL und JOGL.
Der Fokus der beiden Bibliotheken liegt jedoch etwas verschoben. LWJGL hat sich zum Ziel gesetzt, eine betriebssystemunabhängige Entwicklungsmöglichkeit für Multimediaanwendungen zu bieten. Dieses beinhaltet visuelle Darstellung (OpenGL), akustische Darstellung (OpenAL) sowie eine Implementierung von mehreren Eingabegeräten. Da uns jedoch der Support wichtiger als die Anzahl der Features, die wir nicht benötigen, haben wir uns für die offizielle von Sun unterstütze Variante JOGL entschieden.

JOGL

Jogl4 bietet eine reine Implementierung der OpenGL Funktionen. Die Verbindung zur OS spezifischen Rendering Library liefert die Dateien „jogl.jar“ und „glugen-rt.jar“. letztere liefert auch direkt Funktionen der bereits aus C bekannten GLU Bibliothek mit. Die Dateien werden jeweils für das Ziel Betriebssystem benötigt (Unterstützt werden momentan: Mac OSX, Linux, Solaris, Windows). Nun werden noch die betriebssystemspezifischen Dateien benötigt (libjogl, libjogl_cg, libjogl_awt, libglugen-rt jeweils mit OS entsprechender Dateiendung was meistens .so oder .dll ist). Diese müssen in die dafür vorgesehenen Order gelegt werden, damit sie vom System ausgeführt werden könnten (Linux: /usr/lib Windows: Windows/System32).
Für den Webstart von einer JOGL Anwendung ist dieses nicht von Nöten. Es wird eine Referenz auf die JOGL Seite hinterlegt, welche Fehlende Dateien nachladen kann.

Bluetooth

BlueCove & BlueZ

BlueCove5 ist eine Implementierung des Bluetooth Stacks für Java. In der momentanen stabilen Version (2.0.2) ist noch kein Linux Support enthalten, weshalb wir jeweils auf die „Nightly Build“ Version von BlueCove angewiesen sind. Diese enthält ersten Linux Support über die systemeigene BlueZ6 Library. Nach unseren Erfahrungen ist die momentane Implementierung aber schon ausreichend gut. Nach einer gewissen Zeit kann es zwar zum Absturz des Bluetooth Stacks kommen, jedoch ist dieses nur mit vielen Verbindungsvorgängen verbunden.

WiiRemote

WiiRemoteJ

WiiRemoteJ7 bietet eine eventbasierte Zugriffsmöglichkeit per Java auf den WiiRemote Controller der Nintendo Spielkonsole Wii. Diese Library bietet eine vollständige Ansteuerung aller Sensoren/IR-Cam/Steuereinheiten der WiiRemote, hat jedoch auch lizenztechnische Einschränkungen (die einzige Library dieser Software die nicht mindestens GPL nutzt) und gilt im Allgemeinen als nicht so stabil wie die C Implementierungen. Die wohl stabilste Library ist Cwiid8 welche per JNI auch angesprochen werden kann.