Login
Login-Name Passwort


 
Newsletter
Werbung

So, 29. Mai 2005, 00:00

GNU Classpath - Was gibt es Neues?

Mit dieser Artikelserie soll umfassend über GNU Classpath und seine wichtigsten Schwesterprojekte informiert werden.

Motivation

Mit dieser Artikelserie will ich euch umfassend über GNU Classpath und seine wichtigsten Schwesterprojekte informieren. Wer sich ein bisschen Zeit zum Lesen nimmt, dessen Wahrnehmung bezüglich Java in der freien Software Community wird gründlich umgekrempelt.

Ich versuche den Inhalt in einer möglichst allgemein verständlichen Form rüberzubringen, jedoch wird der technische Hintergrund von Java manchmal durchscheinen.

Worum geht's hier eigentlich?

In diesem ersten Teil werde ich Hintergrundinformationen zu Sun, Java und dessen Lizenzproblematik präsentieren, bevor ich dann GNU Classpath mit seiner bisherigen Geschichte vorstelle. Der nächste Abschnitt ist dann bekannter Software gewidmet, die heute schon auf unserer freien Implementierung läuft. Den Abschluss dieses Artikels bildet ein oberflächlicher Ausblick auf die Zukunft von GNU Classpath.

Was ist eigentlich Java?

Viele von euch haben gehört, dass Java langsam sei und sich nicht für ernste Programme eigne. Leider wird bei dieser Betrachtung vergessen, dass es sich bei dem Begriff Java zuerst einmal um eine Sprache handelt. Eine Sprache kategorisiert man üblich nach ihren Fähigkeiten und ihrer Ausdruckskraft. Java ist eine Sprache, die streng eine Programmiermethodik unterstützt, die objektorientierte Programmierung genannt wird und heute wesentlich für die moderne Anwendungsentwicklung ist. Daneben kann ein Java-Programmierer von Typsicherheit Gebrauch machen. Beide Konzepte richtig eingesetzt verhelfen zu einer zügigen Programmentwicklung, da sie den Design-Prozess unterstützen und bei der Vermeidung von Programmierfehlern dienlich sind. Geschwindigkeit lässt sich an dieser Stelle noch gar nicht messen, dafür braucht es Programme, die mit dieser Sprache etwas anfangen können.

Als Java 1996 an die Öffentlichkeit gelangte, war eine ihrer erstaunlichsten Eigenschaften die Fähigkeit, auf verschiedenen Betriebssystemen zu laufen, ohne neu übersetzt zu werden. Erkauft wird diese Eigenschaft durch den sogenannten Bytecode, der von einem Programm namens virtuelle Maschine (engl. Java Virtual Machine/JVM) verarbeitet und ausgeführt wird. Nun können die Befehle in dem Bytecode aber nicht direkt auf die Fähigkeiten des unterliegenden Betriebssystems zugreifen, sondern »nur« eine sogenannte Klassenbibliothek benutzen. Diese stellt Funktionen bereit, die eine typische Java-Anwendung so braucht: Zeichenketten, grafische Komponenten, eine Netzwerkschnittstelle und vieles mehr. Darin steckt das eigentliche Geheimnis der Plattformunabhängigkeit: Denn jedes Betriebssystem, auf dem Java-Programme laufen sollen können, braucht eine speziell angepasste Klassenbibliothek. Für die Geschwindigkeit von Java sind daher zwei Dinge von Bedeutung: Einerseits das Vermögen der virtuellen Maschine, den Bytecode zügig zu verarbeiten, und andererseits die Sorgfalt bei der Implementierung der Klassenbibliothek.

Welche Probleme hat die freie Softwarewelt mit Java?

Traditionell gibt es die Klassenbibliothek im Paket mit einer virtuellen Maschine und einigen Hilfsprogrammen der Firma Sun Microsystems als sogenannte Java Runtime Environment (JRE; für Anwender) oder Java Development Kit (JDK; für Entwickler) kostenlos unter einer unfreien Lizenz.

Im Laufe der Zeit wurde der Bibliothek immer mehr Funktionalität zugefügt und die virtuellen Maschinen wurden immer raffinierter im Umgang mit dem Bytecode. Schon bald zeichnete sich jedoch ab, dass Sun mit der Entwicklung überfordert schien: Peinliche Programmierfehler schlichen sich durch die Qualitätssicherung, lange bekannte Bugs wurden nicht behoben und einige von den Java-Entwicklern sehnlichst erwartete Features wurden immer und immer wieder auf die nächste Version verschoben.

Neben diesen technischen Problem war Sun auch weiterhin nicht gewillt, die Lizenzbedingungen für ihr Produkt zu lockern, wodurch Distributionen wie Debian (heute auch Ubuntu und Fedora Core) keine Java-Unterstützung auf Basis der Sun-Software anbieten können.

In der Vergangenheit äußerte sich Sun wiederholt dem Thema Relizenzierung und einige hohe Sun-Mitarbeiter Sprachen gewichtige Worte. Am Ende wurde aber immer wieder betont, wie wichtig eine zentrale Kontrolle für die Sicherstellung der Kompatibilität sei, und das ganze Thema verschwand wieder in der Versenkung.

Ist Java denn nicht frei?

Einige Leute behaupten gelegentlich (darunter auch James Gosling, der geistige Vater der Programmiersprache, dass Java »Open Source« sei.

Bisher haben sich alle Lizenzen, unter denen Sun ihr Produkt vertrieben hat, als sogenanntes »Nur-Lese-Open-Source« herausgestellt. Ein Blick in die Quellen ist somit erlaubt, aber weitergehende Freiheiten ergeben sich daraus nicht.

Freedom Zero - die Basis aller freien Software

Entgegen gewisser Trends, lediglich Zugang zum Quellcode als ein wichtiges Merkmal zu fordern, möchte ich in diesem Abschnitt erläutern, warum die Freiheit, ein Programm für jeden erdenklichen Zweck einzusetzen, weitaus bedeutender ist. In der aktuellen Situation können sich nur wenige vorstellen, dass ihr Computer ihnen etwas nicht ermöglicht. Wir haben uns an den Rechner als eine Maschine gewöhnt, die jede Aufgabe bewältigen kann. Die Exportbeschränkungen der USA auf starke Verschlüsselungsalgorithmen oder die überzogenen Nutzungsverbote von Software in Ländern wie dem Irak, Afghanistan und anderen erscheinen uns heute lächerlich, da sie gar nicht durchgesetzt werden können.

In Zukunft werden aber Techniken wie »Trusted Computing« (TCPA) oder digitales Restriktionsmanagement (DRM) diese Lücke schließen und den Zugang kontrollieren. Die Java- und auch die .NET-Plattform sind dabei hervorragend dafür geeignet, Software mit Schranken zu versehen. Bei korrekter Implementierung und entsprechender Rechtevergabe ist es einem Java-Programm nicht möglich, die Grenzen der virtuellen Maschine zu durchbrechen. Was einerseits eure Festplatten vor ungewolltem Zugriff von außen sichern kann, lässt sich auch für das genaue Gegenteil nutzen. Mit einer Implementierung als freie Software stellen wir sicher, dass das Programm immer seinen Anwendern dient.

Offtopic: Eine andere interessante Thematisierung von »Freedom Zero« bietet dieser Artikel.

Was ist das Problem mit dem Begriff »Free Java«?

Wie viele wissen, ist zwar das GNU/Linux-Betriebssystem einem System namens Unix nachempfunden, aber es darf offiziell nicht so genannt werden. Letzteres ist ein Markenname, der für Kompatibilität vergeben wird. Vor einigen Jahren wurde daher in vielen Artikeln stattdessen »Un*x« geschrieben und hat Unbedarfte wie mich damals ziemlich verwirrt. Bei »Java« handelt es sich ebenfalls um einen Markennamen, der von Sun Microsystems an Produkte vergeben wird, die ihrer Spezifikation entsprechen und getestet wurden. GNU Classpath strebt zwar eine solche Zertifizierung an, wird aber bis zum erfolgreichen Abschluß derselbigen offiziell kein Java sein und somit ist auch die Bezeichnung »freies Java« problematisch.

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung