GNU Compiler Collection

@rbo:Die GNU-Compiler Collection

@rbu:GCJ :Der native Java-Compiler

@d:GCC (GNU Compiler Collection) ist eine Sammlung von Referenz-Compilern. Vor Kurzem wurde der GCJ (GNU Compiler for Java) hinzugefügt, welcher die Entwicklung von leistungsfähigen Linux-Lösungen forciert. GCJ stellt weit reichende Features wie das Standard-JDK von Sun zur Verfügung. Die Handhabung orientiert sich am C-Compiler, somit fällt der Einstieg leicht.

@u:Neue Entwicklungsumgebung

@e:Da Linux immer mehr Einzug ins Unternehmen findet, gibt es ein großes Interesse, das auch die Java-Entwicklungsplattform unterstützt wird. Unter Linux spielte die Sprache „Java“ bisher meist eine untergeordnete Rolle, da die meisten Projekte mit C++ realisiert wurden. Aus diesem Grund wurde der GNU-Compiler for Java in die GCC aufgenommen und somit der Support auf breiter Basis gesichert. Ursprünglich war der GCC ein reiner C-Compiler. Heute dient er zur Entwicklung von Cross-Plattform-Lösungen und stellt eine konsistente Compilersammlung bereit. Bei GCJ handelt sich um eine komplette Entwicklungsumgebung.

@ao:Alexander Scheb
@zk1:Der GCJ

@g:Intern greift GCJ auf die libgcj-Bibliothek zu, welche mit GCC 3.0 ausgeliefert wird. Die Bibliothek liefert das Laufzeitsystem (Runtime) und stellt einen Bytecode – Interpreter sowie eine große Klassenbibliothek und einen konservativen Garbage Collector zur Verfügung. Aus rechtlichen Gründen kann nicht auf die SUN-Bibliothek zurückgegriffen werden und muss so eine Eigene bereitstellen. Die meisten Standard-JDK-Klassen (java.lang, java.io, java.util, java.net, java.security, java.sql und java.math) sind innerhalb der libgcj-Bibliothek implementiert. Leider ist das AWT-GUI-Toolkit unvollständig implementiert und die Swing-Bibliothek fehlt vollständig. Dieser Klassen aus dem JDK müssen entweder lizenziert oder durch freie Implementation ersetzt werden.

((Bild8.tiff))

@b:GCJ ist ein Unterprojekt und Teil des GNU Compiler Collection-Projektes.

@zk1: Der Standardweg

@n:Im Prinzip sind bei jedem Javaprogramm immer zwei Schritte nötig. Zuerst folgt die Übersetzungsphase und dann die Ausführungsphase. Jedes Javaprogramm wird mittels javac-Compiler zuerst kompiliert, welche eine Vielzahl von Dateien mit der Endung *.class produziert. Jede Datei ist eine binäre Repräsentation (Bytecode) einer Klasse und ihrer Details. Die Ausführung wird über die JVM (Java virtuelle Maschine) erledigt, worüber class-Dateien zur Ausführung gebracht werden. Das wird über das Kommando „java <Programmname >“ erledigt. Jedoch führt die JVM zu einem enormen Ausführungsoverhead. Deshalb haben Javaprogramme häufig mit Performance Problemen zu kämpfen.

@zk1:Just-in-time-Compiler

@n:Die Lösung ist ein so genannter Just-in-time-Compiler, welcher eine dynamische Übersetzung durchführt. Ein gewöhnlicher JIT-Compiler übersetzt den Java-Bytecode bei der ersten Ausführung in native Instruktionen. Beim ersten Aufruf läuft das Programm langsam ab, aber danach mit höherer Geschwindigkeit. Der JIT-Compiler puffert den Maschinencode, damit er beim nächsten Durchlauf nicht nochmals komplett übersetzt werden muss. Dies bringt vor allem bei Schleifen einen enormen Geschwindigkeitsgewinn. In diesem Fall hat das Laufzeitsystem zur Methodenausführung genug Zeit, um entsprechenden Maschinencode on-the-fly zu generieren. Bei dem JIT-Verfahren gibt es nur das Problem des Startup-Overheads. Es braucht eben Zeit eine Methode zu kompilieren, gerade, wenn dies optimiert erfolgen soll.

Zudem ist eine JIT schwer zu entwickeln und braucht enorm viel Speicher. Zudem ist die Interoperabilität zu anderen Sprachen eingeschränkt, da das Laufzeitsystem langsam arbeitet. Ab dem JDK 1.2 wird von Sun ein JIT-Compiler mitgeliefert (sunwjit). Daneben gibt es auch freie Implementierungen wie Metrowerks JIT for PowerPCs oder Cacao for Alpha-Prozessoren. Interpretierter Bytecode oder der JIT-Compiler kann nie die Geschwindigkeit von nativen Code erreichen. Wer also auf binäre Portierbarkeit verzichten kann, weil er die Zielplattform kennt, wird einem echten Java-Compiler aufgeschlossen gegenüberstehen. Eine Vorkompilierung erzielt den höchsten Geschwindigkeitsvorteil.

@zk1:Interna

@n:Der GCC hat, wie bekannt, seine Wurzeln in C und C++. Allerdings unterstützt GCC schon lange eine Reihe zusätzlicher Sprachen (Modula2, Ada, Pascal, Fortran und jetzt Java). GCJ führt einen sehr eleganten Weg ein. Java wird als eine Sprache unter vielen gehandelt. Die Handhabung fällt wie bei anderen Compilern aus. So kann der Entwickler ihn einfacher nutzen, da er vieles schon kennt. Die Kompilierung ist sogar leichter, da es keine Templates oder Präprozessor wie in C++ gibt. Dies liegt daran, da das Typsystem, Objektmodell und das Ausführungsbehandlungsmodell einfacher entworfen wurden. Während der Kompilierung wird das Programm innerhalb eines abstrakten Syntax-Baumes repräsentiert und nutzt die gleichen Datenstrukturen in GCC wie for andere Sprachen. Jedes Java-Konstrukt nutzt dieselbe interne Repräsentation wie ein C++ Äquivalent.

@zk1:Vorurteile

@n:GCJ kann zu Optimierungszwecke auf alle GNU-Tools zurückgreifen, welche zur Verfügung stehen. Mit GCJ lässt sich die Zeitspanne der Programmausführung sehr effektiv optimieren. Gewöhnlich kommt jetzt der Einwand, dass dies die Domäne eines JIT-Compilers sei. Die Hot Spot Technologie hat dies versprochen und auch gehalten. Hot Spot versucht im Hintergrund die zeitkritischen Teile zu optimieren, um einen weiteren Geschwindigkeitsschub zu erreichen. Dazu werden während der Laufzeit Informationen gesammelt, um die lohnenden Codestellen for die Optimierung zu finden. Generell ist ein ausgeführtes Programm, welches mit GCJ kompiliert wurde, nicht immer schneller als eine JIT-Lösung. Auf jeden Fall ist es schneller als jede JVM. Ein großer Vorteil von GCJ ist die schnelle Startgeschwindigkeit sowie die moderate Speichernutzung. Den Bytecode hat den Nachteil, dass die JVM enorm viel Speicher benötigt, um die Instruktionen zu ausführen zu können.

@zk1:Problemfälle

@n:Der Aufruf der Java virtuellen Maschine oder des JIT-Compilers fordert einen enormen Zeitaufwand. Der Aufruf der Forte for Java-Entwicklungsoberfläche zeigt dies exemplarisch. Es dauert ewig, bis die IDE zur Verfügung steht. Ebenso benötigt Net Beans 74 MB Speicher, bevor der Entwickler überhaupt irgendetwas machen kann. Diese Hauptspeicheranforderung erschwert die Verteilung von Java-Anwendungen enorm. Eine weitere Illustration ist JEmacs. Das Projekt implementiert den traditionellen Emacs-Editor in Java und greift dabei auf die Swing-Bibliothek zurück. Der Programmstart erfordert 26 MB Speicher, wobei Emacs nur 8 MB benötigt. Führt man jedoch mit GCJ eine native Kompilierung durch und startet diese, stellt man fest, das diese mindestens 2x schneller abläuft, weniger Fehler produziert und dabei 25 % weniger Speicher verbraucht. Hieran sieht man, welchen Nutzen der neue GNU Compiler for Java bringt.

@zk1:Leistungsmerkmale des GCJs

@n:Einen interessanten Ansatz verfolgt GCJ durch diverse Leistungsmerkmale. Der Entwickler kann unter anderem:

@n:1) Java-Sourcen direkt in Maschinencode übersetzen,

@n:2) Java-Sourcen in Bytecode übersetzen (java->class)

@n:3) Java-Bytecode in Maschinencode übersetzen

@n:4) sowie Maschinencode for andere Systeme erzeugen (Cross-Compiler).

@n:Dies macht GCJ interessant for den Einsatz im Embedded-Bereich, da dieser so entworfen wurde, dass er auch mit dem GNU-C-Compiler (gcc) und dem GNU-Debugger (gdb) zusammenarbeitet. Der Einstieg in GCJ ist nicht einfach, da dessen Entwicklung noch nicht vollends abgeschlossen ist. Das Ziel des GCJs ist es, dass der Entwickler hoch performante Linux-Anwendungen durch native Kompilierung erzeugen kann. Heute existieren zahlreichere Projekte, die erfolgreich mit der Sprache „Java“ realisiert wurden. Dies zeigt, welchen Nutzen diese Sprache bringt, wenn eine schnelle Umsetzung gefragt ist. Zu den bekanntesten dürfte Jakarta vom der Apache Foundation (jarkarta.apache.org) sowie zahlreiche XML-Tools von W3C und Freenet (freenet.sourceforge.net) zählen. In Tabelle1 sind weitere interessante Projekte zusammengefasst.

@n:Tabelle1:

@n:Projektname Projektzweck

@n:XWT Bei XWT handelt es sich um ein XML-Windowing Toolkit

@n:jUSB/jPhoto jUSB ist eine Open-Source-Java-API for die USB-Schnittstelle

@n:PAL PAL ist eine Java-Biblithek zum Einsatz der molekularen Evolution

@n:Tamanoir Das Tamanoir-System ist ein komplettes Framework zur Verteilung von Routern innerhalb eines Netzwerkes.

@zk1:Der Installationsprozess

@n:Im ersten Schritt gilt es erstmals die neue Entwicklungsumgebung aufzusetzen. GCJ ist for Windows, Linux und andere Unix-Varianten verfügbar. Bei den meisten Distributionen dürfte GCJ schon vorinstalliert sein. Welche Version vorliegt, lässt sich mittels des Kommandos gcj –version schnell ermitteln. Die GCJ-Homepage empfiehlt die ältere Version 2.95 nicht zu nutzen und die aktuellste Version aufzuspielen. Bei SuSE 8.2 braucht man dies nicht, da GCC 3 bereits schon installiert ist. Es ist übrigens generell keine Empfehlung die vorkompilierten Pakete eines Herstellers zu verwenden. So lassen sich meist keine zusätzlichen Patches einspielen oder das Programmverzeichnis angeben. Auch die verschiedenen Distributionen machen dem Entwickler das Leben schwer: Dies liegt an den voneinander abweichenden Installationspfaden und unterschiedlichen Informationen über Bibliotheksabhängigkeiten. Um solchen Problemen vorzubeugen, sollte man am besten direkt mit dem Quellcode arbeiten. Dann stehen vielfältige Möglichkeiten offen, ein auf die eigene Bedürfnisse angepasstes System einzurichten. For die Installation und Konfiguration von GCJ ist es erforderlich, als Super-User zu agieren. Dazu meldet man sich als Root-Anwender beim System an. Sobald das Archiv (gcc-3.0.4.tar.gz) vom FTP-Server ftp://gcc.gnu.org/pub/gcc/releases heruntergeladen (zirka 20 MB) ist, empfiehlt es sich, die Datei in das Verzeichnis /usr/local/src zu kopieren und auf der Shell oder im Shell-Fenster mit dem Kommando: tar xzf gcc-3.0.4.tar.gz zu entpacken. Anschließend wechselt man ins neu angelegte GCC-Verzeichnis (cd /usr/local/src/gcc). Vor der eigentlichen Installation stehen Vorkonfigurations- und Kompilierungsarbeiten an. Mithilfe eines Konfigurationsscripts lassen sich alle Übersetzungsbefehle an die aktuelle Systemkonfiguration anpassen. For den Übersetzungsvorgang kann jeder lauffähiger ANSI-C++-Compiler zum Einsatz kommen. Um den Quellcode nach eigenen Vorstellungen zu kompilieren, gibt es eine Vielzahl von Parametern zu dem Konfigurationsskript ./configure. Zu dieser Gattung zählt der Parameter –prefix=/usr/local/gcc, dessen Zweck darin besteht, dass Programmverzeichnis von GCJ festzulegen. Das Kommando zum Start des Konfigurationsscripts sieht folgendermaßen aus:

./configure --prefix=/usr/local/gcc --enable-shared --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c++,java --enable-fast-character

Nach dessen Ausführung kann der Administrator die Installation mittels „make“ und „make install“ abschließen. Während der Übersetzung kommt es gelegentlich zu Problemen. Daher sollten Vorsichtige besonders bei einer Neukompilierung alle automatisch generierten Dateien vor einem erneuten Durchlauf unbedingt löschen. Dies geschieht mittels der Befehle „rm config.cache“ und „make clean“. In Einzelfällen fordert das Konfigurationsskript jedoch nur andere Parameterangaben. Der Installationsprozess dauert zirka 1 Stunde, bevor alles abgeschlossen ist.

((Bild1.tiff))

@b:SuSe 8.2 ist bereits mit der aktuellsten GCC-Version ausgestattet.

((Bild2.tiff))

@b:Die installierte GCJ-Version läßt sich über das Kommando „Gcj –version“ ermitteln.

@l:Ausschnitt GCC-Makefile:

# Makefile for directory with subdirs to build.

# 1999, 2000 Free Software Foundation

# Directory in which the compiler finds executables, libraries, etc.

libsubdir = $(libdir)/gcc-lib/$(target_alias)/$(gcc_version)

GDB_NLM_DEPS =

SHELL = /bin/sh

# INSTALL_PROGRAM_ARGS is changed by configure.in to use -x for a

# cygwin host.

INSTALL_PROGRAM_ARGS =

INSTALL = $(SHELL) $$s/install-sh -c

INSTALL_PROGRAM = $(INSTALL) $(INSTALL_PROGRAM_ARGS)

INSTALL_SCRIPT = $(INSTALL)

INSTALL_DATA = $(INSTALL) -m 644

INSTALL_DOSREL = install-dosrel-fake

# This is set by the configure script to the list of directories which

# should be built using the target tools.

TARGET_CONFIGDIRS = libiberty libgloss $(SPECIAL_LIBS) newlib librx winsup opcodes bsp libstub cygmon libf2c libchill libobjc

# Target libraries are put under this directory:

# Changed by configure to $(target_alias) if cross.

TARGET_SUBDIR = .

# This is set by the configure script to the arguments passed to configure.

CONFIG_ARGUMENTS =

# This is set by configure to REALLY_SET_LIB_PATH if --enable-shared

# was used.

SET_LIB_PATH =

# This is the name of the environment variable used for the path to

# the libraries. This may be changed by configure.in.

RPATH_ENVVAR = LD_LIBRARY_PATH

# configure.in sets SET_LIB_PATH to this if --enable-shared was used.

# Some platforms don't like blank entries, so we remove duplicate,

# leading and trailing colons.

REALLY_SET_LIB_PATH = \

$(RPATH_ENVVAR)=`echo "$(HOST_LIB_PATH):$(TARGET_LIB_PATH):$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR);

ALL = all.normal

INSTALL_TARGET = installdirs \

install-gcc \

$(INSTALL_MODULES) \

$(INSTALL_TARGET_MODULES) \

$(INSTALL_X11_MODULES) \

$(INSTALL_DOSREL)

INSTALL_TARGET_CROSS = installdirs \

install-gcc-cross \

$(INSTALL_MODULES) \

$(INSTALL_TARGET_MODULES) \

$(INSTALL_X11_MODULES) \

$(INSTALL_DOSREL)

# Should be substed by configure.in

FLAGS_FOR_TARGET =

CC_FOR_TARGET =

CHILL_FOR_TARGET =

CXX_FOR_TARGET =

CXX_FOR_TARGET_FOR_RECURSIVE_MAKE =

GCJ_FOR_TARGET =

@zk1:Der Praxisalltag

@n:Der Anwender kann nun die ersten Schritte mit GCJ unternehmen. Der GCJ kann Java-Dateien, Bytecode-Dateien (class) sowie ZIP- und JAR-Archive verarbeiten. Zur Demonstration soll ein Java-Quellprogramm in ein direkt ausführbares Programm (nativer Maschinencode) übersetzt werden, der sich ohne JVM (Java virtuelle Maschine) starten läßt. Als Java-Quellprogramm kann z.B. ein simples HelloWorld-Beispiel dienen. Als Erstes ist dem GCJ-Compiler anzugeben, welche Klasse über eine main()-Methode verfügt, worüber das Programm später gestartet werden kann. Das wird über die Option main=HelloWorld spezifiziert. Zusätzlich ist der Name der Objektdatei zu bestimmen, welcher der Compiler anlegt. Der Entwickler gibt folgende Anweisung for die native Kompilierung ein:

@l:Gcj –main=HelloWorld –o HelloWorld HelloWorld.java

@n:Als Ergebnis wird eine Objektdatei erzeugt und durch einen so genannten Linker eine ausführbare Datei zusammengebaut. Nun kann der Anwender dass Programm über den Befehl: ./HelloWorld ausführen. Die Ausführungsgeschwindigkeit ist gegenüber dem Standard-Compiler (javac) wesentlich schneller. Was aber spürbar schneller geht, ist der Programmstart, da kein Java-Interpreter gestartet werden muss. Als Tribut muss man auf die Plattformunabhängigkeit verzichten, da der Code nur noch auf dem Zielsystem lauffähig ist.

((Bild3.tiff))

@b:Hier hat der native Java-Compiler bei der Kompilierung eine Objektdatei erzeugt.

@n:Natürlich lässt sich mit dem GCJ auch gewöhnlicher Bytecode erzeugen. Dazu ist nur die Option –C anzugeben. Die Anweisung sieht in diesem Fall so aus:

@l:Gcj –C HelloWorld.java –d build

@n:Auf gleiche Art ist es kein Problem mit GCJ so genannten Java-Bytecode in ein direkt ausführbares Programm zu kompilieren. Somit kommen auch Java-Klassen in Frage, von denen kein Quellcode vorhanden ist. Folgende Anweisung zeigt dies exemplarisch:

@l:Gcj –main=HelloWorld –o HelloWorld HelloWorld.class

@n:GCJ ist sogar in der Lage richtige Shared-Bibliotheken (*.so Datei) zu erzeugen. Somit können dann andere Programme darauf zur Laufzeit ohne Probleme zugreifen und dessen Funktionen for ihre Zwecke nutzen. Sogar das GCJ-Laufzeitsystem steht zum Beispiel als Shared-Bibliothek zur Verfügung.

((Bild5.tiff))

@b:Der Konqueror zeigt an, welche Dateien vom GCJ generiert worden sind.

@zk1:Compileroptionen

@n:Wie jeder Compiler lässt sich der GCJ über eine Reihe diverser Optionen gezielt steuern. Folgende Optionen stehen dem Entwickler bei der Kompilierung zur Verfügung. Die Option –help gibt eine Kurzübersicht aller möglichen Optionen aus. Die Option –C übersetzt Java-Quellen in Bytecode (Class-Dateien). Die Option –output-class-dir spezifiziert das Ausgabeverzeichnis der übersetzten Class-Dateien. Die Option –bounds-check schaltet die Überprüfung der Feldgrenzen ein. Die Option –main spezifiziert den Einstiegspunkt ins Programm innerhalb der übersetzten Dateien. Die Option –Idir hängt das angegebene Verzeichnis an den Classpath an. Die Option –classpath verwendet den angegebenen Pfad als Classpath.

((Bild4.tiff))

@b:Der GCJ stellt vielfältige Compilerschalter zur Verfügung.

@zk1:Externe Bibliotheken

@n:Auch Javaprogramme setzen gelegentlich externe Bibliotheken ein, die in einer anderen Sprache implementiert sind. Dies ist immer der Fall, wenn ein Low-Level-Zugriff auf Code benötigt wird, welcher in Java nicht zu realisieren wäre bzw. die Bibliothek eine Funktion bietet, wo es unnötig wäre, dies neu zu implementieren. Dazu wird die entsprechende Methode im Java-Programm einfach als native deklariert und braucht sich keine Sorgen über die eigentliche Implementierung zu machen. Diese wird von einer Implementierung in einer anderen Sprache erbracht. In diesem Fall kommt die JNI-Schnittstelle (Java Native Interface) zum Zuge. Das Hauptziel der Portabilität vor JNI ist es, dass auch nach Austausch der Implementierung das Programm lauffähig bleibt. Nachteilig ist, dass der Entwurf for die Verteilung von geschlossenen Einheiten entwickelt wurde und nicht for eine freie Softwarewelt (Open Source). Die Portabilität wird indirekt durch eine Tabelle mit Funktionen erzielt. Jedoch wird die Ausführungsgeschwindigkeit von JNI hierdurch sehr langsam. Gleichzeitig ist das Schreiben solcher Funktionen und Einhaltung aller Regeln sehr fehleranfällig. GCJ stellt jedoch eine Alternative zur Verfügung. Dies ist das so genannte Compiled Native Interface (CNI) und basiert auf die Idee das Java grundsätzlich eine Untermenge von C++ ist und GCC die gleichen Aufrufskonventionen for C++ und Java verwendet. Somit ist es logisch, dass es möglich ist entsprechende Java-Methoden mit C++ zu schreiben und der Verwendung der C++ Syntax um auf Java-Felder zuzugreifen oder Methodenaufrufe zu tätigen. Da es die gleiche Konvention ist, ist kein Problem.

@zk1:Andere Programmiersprachen

@n:Wie bereits beschrieben, wird normalerweise ein Javaprogramm durch eine JVM ausgeführt, da dass Programm in einer so genannten Zwischensprache (Bytecode) vorliegt. Erstaunlicherweise gibt es einige Programmiersprachen, die ebenfalls mit der JVM ausgeführt werden können. Eine Liste ist auf der Website:

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html zu finden. Die meisten davon sind reine Interpreter, doch einige nehmen eine Kompilierung zum Bytecode vor. Hier kann der GCJ eingesetzt werden, um daraus richtigen nativen Maschinencode zu erzeugen.

Ein solcher Compiler ist Kawa, welcher 1996 entwickelt wurde. Kawa lässt sich unter GCJ ohne zusätzliche Software einsetzen. Die Website: www.gnu.org/software/kawa zeigt alle Instruktionen, wie Kawa unter GCJ eingerichtet werden kann. Die Programmierung erfolgt innerhalb von Kawa mittels der Sprache Scheme, wobei es sich um ein Lisp Abkömmling handelt. Der Entwickler kann Kawa direkt im interaktiven Modus testen. Implementiert er eine Methode wird diese von Kawa direkt in Bytecode kompiliert und als neue Klasse automatisch herein geladenen. Dazu wird die ClassLoader Klasse genutzt, um eine neue Klasse zur Laufzeit zu definieren. Die neuen Klassenmethoden werden vom GCJ-Bytecode-Interpreter interpretiert. Die Geschwindigkeit des Scheme-Code läßt sich erhöhen, indem Kawa class-Dateien anlegt. Um diese Klassendateien zu Maschinencode zu kompilieren, steht das Kommando GCKAWA bereit. Dies ist ein Skript, welches alle nötigen Umgebungsvariablen setzt (LD_LIBRARY_PATH und CLASSPATH) und den GCJ aufruft. Anschließend läßt sich das erzeugte Programm direkt ausführen, da eine gewöhnliches GNU/LINUX ELF Datei erzeugt wurde. Das Programm greift auf die Shared-Libraries libgcj.so (GCJ Laufzeitbibliothek) und libkawa.so (Kawa Laufzeitbibliothek) zu, welche zur Ausführung notwendig sind. Der gleiche Ansatz kann ist for jede andere Sprachen auch anwendbar.

((Bild6.tiff))

@b:Es gibt eine Vielzahl von Programmiersprachen die auf der JVM lauffähig sind. Diese Website gibt einen Überblick darüber.

((Bild7.tiff))

@b:Diese Website gibt einen Überblick welche Java-Compiler zur Zeit verfügbar sind.

@zk1:Fazit

@n:Wenn man Java als reine Programmiersprache betrachtet, bietet der GNU-Java-Compiler einen interessanten Ansatz. Durch die Einbindung in die GNU-Compiler Collection ist die Anbindung anderer Sprachen wie C oder C++ einfacher möglich als über die JNI-Schnittstelle, aber auch diese wird unterstützt. Zwar ist GCJ noch nicht vollends ausgereift, wird aber stetig weiterentwickelt. Der Geschwindigkeitsgewinn, der sich damit erzielen läßt, wird zwar durch den Verlust der Plattformunabhängigkeit erkauft, aber nicht immer wird diese Unabhängigkeit benötigt. Wenn klar ist, for welche Plattform entwickelt wird, ist dieser Ansatz zu empfehlen.

@zk1:Schluss

@n:GCJ reift immer mehr heran zu einer soliden Plattform for vielfältige Zwecke. Viele hoffen das Java so noch mehr in freien Projekten eingesetzt wird. Die freie Gemeinde treibt die Entwicklung voran und stellt sicher das GCJ immer besser wird. Nach den ersten Schritten stellt sich heraus, daß GCJ gar nicht so schwer zu handhaben ist.

@zk1:Web-Links:

@n:[1] GCC-Homepage: [http://gcc.gnu.org/]

@n:[2] GCJ-Homepage: [http://gcc.gnu.org/java/]

@n:[3] GCJ-Dokumentation: [http://gcc.gnu.org/onlinedocs/gcj/]

@n:[4] GCJ-Installationsanleitung: [http://gcc.gnu.org/install/]

@n:[5] Informationen zu CNI:

@n:[5] Kawa-Homepage: [http://www.gnu.org/software/kawa/]

@n:[6] Alle Sprachen die auf der JVM lauffähig sind: [http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html]

@n:[7] Sammlung verfügbarer Java-Compiler: [http://www.dwheeler.com/java-imp.html]