Die Geschichte eines der größten Erfolge auf dem Sektor der elektronischen Kommunikation begann mit einem Fehlschlag. Noch vor wenigen Jahren war das interaktive Fernsehen in euphorischen Prognosen als das Medium der Zukunft gepriesen worden. Das Interesse der Zuschauer hielt sich dann jedoch in sehr engen Grenzen – so eng, daß die Geräteindustrie keinen Anlaß sah, ihre Produkte mit den dafür erforderlichen Computerchips auszustatten. Entsprechend erübrigte es sich, Software für Fernsehgeräte zu schreiben, und auch für Hilfsmittel zum Erstellen solcher Programme gab es keine Verwendung mehr.

Genau dafür aber hatten James Gosling und seine Mitarbeiter bei der Firma Sun Microsystems in Mountain View (Kalifornien) eine Programmiersprache entwickelt. Sie sollte für verschiedenste – auch noch nicht existierende – Typen von Mikrochips Maschinencode produzieren, der in Fernsehgeräten, Waschmaschinen oder Mikrowellenherden über lange Zeit fehlerfrei funktionierte; denn ein Haushaltsgerät mit einem nachgebesserten Programm auszustatten wäre unangemessen aufwendig. Hohe Rechengeschwindigkeit war dagegen nicht gefordert.

Nun suchte man einen neuen Verwendungszweck für das überflüssig gewordene Produkt – und fand ihn im Internet. Software zur Verbreitung im Netz sollte schließlich ebenfalls auf Computern der verschiedensten Art lauffähig sein. Auch einen griffigen Namen ließen sich die Autoren einfallen; so frisch und anregend wie der Java-Kaffee in ihrem Stammcafé sollte ihr Software-Produkt sein.

Ein per Internet übermitteltes Programm muß allerdings auch hohen Sicherheitsansprüchen genügen: Der Anwender will darauf vertrauen können, daß es weder seine Daten ruiniert noch sie anderen preisgibt oder gar ein Virus in sein Gerät einschleust. Gosling und seine Mitarbeiter modifizierten deshalb ihre neue Programmiersprache mit dem Ziel, das Schreiben schädlicher Programme unmöglich zu machen: Jede potentiell gefährliche Anweisung sollte einem Grammatikfehler gleichkommen. Somit könnte bereits eine formale Überprüfung auf grammatische Korrektheit – zu erledigen durch ein weiteres Computerprogramm – die Unschädlichkeit eines Programms erweisen: eine Art strukturelle Nichtangriffsfähigkeit.

Dieses hehre Ziel ist bei Computern allerdings ebenso schwierig zu erreichen wie bei Waffen; denn beide sind üblicherweise auf Effizienz und nicht auf Rücksichtnahme optimiert. So gibt es in den gängigen Prozessoren keine Vorkehrungen dagegen, daß ein Programm seinen eigenen Text verändert. Ein böswillig manipuliertes Stück Software könnte mithin innerhalb seiner selbst an die Stelle einer Anweisung, die anstandslos den Grammatiktest passiert hat, den Befehl "Lösche die Festplatte" setzen.

Es galt also, das übliche Sortiment zulässiger Computerbefehle auf eines aus garantiert harmlosen Anweisungen zu reduzieren – aber nicht zu sehr, weil sonst das legitime Arbeiten allzu umständlich oder gar unmöglich würde. Die Autoren von Java lösten diese Aufgabe, indem sie eine gedachte Maschine mit entsprechend eingeschränktem Befehlssatz definierten. Ein echter Computerchip realisiert dann diese Maschine, indem er ihre Befehle in seine eigenen umsetzt. Diese Umsetzung muß für jede Chip-Sorte nur ein für allemal programmiert werden.

Bei gängigen Programmen wird zunächst der sogenannte Quellcode in einer höheren Programmiersprache wie Fortran, C oder Pascal formuliert. Was der Prozessor eines Computers verarbeitet ist dagegen der Maschinencode: eine Folge für ihn spezifischer elementarer Befehle. Die Umsetzung zwischen beidem erledigt üblicherweise ein Programm namens Compiler. Gosling und seine Mitarbeiter haben eine Zwischenstation eingeführt: Aus dem Quellcode wird zunächst sogenannter Bytecode und dann erst Maschinencode.

Die Idee ist an sich nicht neu. Autoren großer Softwarepakete haben sich eine ähnliche Zwischenstation zurechtgelegt und erleichtern sich damit die Anpassung ihrer Codes an neue Prozessoren und deren Befehlssätze. Java zeichnet sich demgegenüber durch zwei Eigenschaften aus: Erstens ist der Bytecode öffentlich dokumentiert, und zweitens erfüllt auch diese Zwischenstation noch ein Prinzip, das man normalerweise nur auf der Ebene des Quellcodes anwendet: das objektorientierte Programmieren.


Objektorientiertes Programmieren

Grundbaustein eines Softwarepakets ist in diesem Falle nicht mehr die Prozedur (Haupt- oder Unterprogramm), sondern das Objekt: eine Zusammenfassung von Daten mit sogenannten Methoden, die angeben, was man mit diesen Daten tun kann. Genauer gesagt, beschreibt das Programm, woraus ein allgemeines Objekt, beispielsweise ein Viereck, besteht und welche geometrischen Transformationen und sonstigen Handlungen sich darauf anwenden lassen. Konkrete Vierecke sind dann Exemplare (instances) der dadurch definierten Klasse "Viereck". Im Jargon sagt man nur noch "Klasse", wenn man die Beschreibung einer Klasse von Objekten meint, und an die Stelle eines Programmpakets tritt die sogenannte Klassendatei (class file).

Die Grammatik von Java lehnt sich stark an die weitverbreitete Programmiersprache C++ an. Das dort nur als Möglichkeit enthaltene objektorientierte Programmieren ist allerdings obligatorisch; einige Sprachelemente, die dem Prinzip zuwiderlaufen und ohnehin eine potentielle Quelle schwer zu findender Fehler bilden, wurden gestrichen.

Objekte haben – zumindest in der Vorstellungswelt ihrer Programmierer – ein gewisses Eigenleben und eine Art Intimsphäre: Ihre Daten sind keinem anderen Objekt direkt zugänglich. Es geschieht nur dadurch etwas mit ihnen, daß das Objekt von einem anderen (oder vom Benutzer) eine Anforderung erhält, woraufhin es eine seiner Methoden ausführt. Dabei kann es selbst eine Anforderung an ein anderes Objekt senden. Diese Datenkapselung (data hiding) paßt zum Sicherheitskonzept von Java, wonach auf Daten nie direkt mittels einer – manipulierbaren – Speicheradresse, sondern nur über einen Namen und damit unter Aufsicht zugegriffen werden darf.

Noch wichtiger ist eine weitere Eigenschaft objektorientierter Programme: Im Gegensatz zu ihren prozeduralen Gegenstücken sind sie auf natürliche Weise in übersichtliche Teile zerlegbar. Die Klasse "Rechteck" muß nicht sämtliche auf ein Rechteck anwendbare Methoden beschreiben; sie kann auf die Klasse "Viereck" verweisen und sich im übrigen auf die Eigenschaften beschränken, die ein Rechteck über die eines Vierecks hinaus hat. Dadurch bleibt jede einzelne Klasse ein Programmstück überschaubaren Umfangs, und es ist relativ einfach, einem größeren Programmpaket einzelne Funktionen hinzuzufügen, ohne das Paket selbst antasten zu müssen.


Java im Internet

Eine Klasse wird erst in den Arbeitsspeicher des Computers geladen, wenn ein Objekt sie anfordert oder eine andere Klasse auf sie verweist. Somit braucht sie im ausführenden Computer gar nicht von Anfang an vorhanden zu sein; es genügt, wenn sie sich auf einem Gerät irgendwo im Internet befindet. Dann löst die Anforderung einen Dateitransfer aus; sowie das bestellte Stück Software eingetroffen ist, arbeitet das Programm weiter.

Hauptanwendungsgebiet dieser Technik ist das World Wide Web (WWW), der in den letzten Jahren zu enormer Popularität gelangte Hypertext-Bereich des Internet. Dort erlaubt sie, mit den Bild- und Textdaten auch gleich Programme bereitzustellen, die – auf dem Gerät des Benutzers laufend – bewegte Bilder zeigen (Bild 1), die Aufmerksamkeit des Zuschauers durch rote Blinklichter fesseln oder auch in ernstzunehmender Weise auf seine Wünsche eingehen. Nicht ohne Grund ist das meistzitierte Java-Programm ein Web-Browser (ein Hilfsmittel zum Durchstöbern des WWW) namens HotJava. Der weitverbreitete Browser Netscape kann in seiner Version 2.0 und deren Nachfolgern ebenfalls schon Java-Programme umsetzen.

Auf diese Weise läßt sich auch ein Normierungsproblem elegant umgehen: Während zur Zeit noch internationale Gremien sich immer wieder mühsam über Vorschriften zur Beschreibung einer Web-Seite einigen müssen, damit alle Empfängergeräte sie richtig umsetzen können, liefert in Zukunft der Produzent einer solchen Seite diese Vorschriften gleich mit – als Java-Programm.

In der Praxis kann das nur deshalb funktionieren, weil die zu transportierenden Stücke relativ klein sind. Heute übliche monolithische Programme, die eine Fülle von Fähigkeiten in sich vereinigen, würden bei ihrer Größe von mehreren Megabyte das Netz und die Geduld der Anwender überfordern, sollten sie jedesmal auf Anforderung übertragen werden.

Tatsächlich benötigt ein Anwender aber zu jedem Zeitpunkt nur einen kleinen Teil von dem, was zum Beispiel eine gängige Textverarbeitungssoftware alles kann. Also zerlegt man eine solche eierlegende Wollmilchsau in handliche Einzelteile; wer Eier haben will, bekommt nicht das ganze Programmpaket, sondern nur das eierlegende Unterprogramm, genauer: die Klasse "Ei", die ihrerseits eine Methode (einen object constructor) zum Eierlegen enthält.

Einzelprogramme dieser Art, die auf HotJava aufbauen, heißen applets (eine sprachneuschöpferische Verkleinerungsform von applications). Wenn Java sich erst einmal als Standard etabliert hat, wird aus vielen kleinen Bausteinen ein reichhaltiges Sortiment an Anwendungsprogrammen für jeden Bedarf entstehen – so die optimistische Prognose. Der objektorientierte Aufbau würde automatisch dafür sorgen, daß die Bausteine alle zusammenpassen.

Compiler und Interpreter

Wie gesagt, geschieht bei Java die Umwandlung von Quell- in Maschinencode in zwei Schritten. Der erste – vom Quell- zum Bytecode – findet ein für allemal im Gerät dessen statt, der das Programm bereitstellt, der zweite – vom Byte- zum Maschinencode – dagegen jedesmal aufs neue im Computer des Empfängers. Diese Aufgabe erledigt übrigens kein Compiler, sondern ein sogenannter Interpreter (englisch für Dolmetscher).

Vergleicht man den Quellcode mit einer Montageanleitung für ein Produkt, das aus vielen Einzelteilen zusammenzusetzen ist, dann entspricht ein Interpreter einem Monteur der langsamen, aber zuverlässigen Art: Er befolgt die Anleitung Satz für Satz, sucht sich jedes Bauteil, von dem die Rede ist, aus dem Vorrat, vergewissert sich, daß es auch das richtige ist, und setzt es dann an die geforderte Stelle. Wenn eine Tätigkeit mehrfach durchzuführen ist, arbeitet er den zugehörigen Abschnitt der Anleitung jedesmal aufs neue durch, als ob er ihn noch nie gesehen hätte.

Ein Compiler dagegen verschafft sich zunächst einen Überblick über den kompletten Arbeitsvorgang, legt sich die Reihenfolge der Arbeitsschritte sowie das Rohmaterial möglichst geschickt zurecht und arbeitet dann wie ein Roboter: ohne hinzuschauen, darauf vertrauend, daß jedes Einzelteil dort liegt, wo es hingehört, und daß dort, wo er ein Halbfertigprodukt ablegt, auch Platz dafür ist. Dies verkürzt den Arbeitsablauf ganz enorm.

Ein Programm in Bytecode-Form wird vor der Ausführung durch ein eigens dafür geschriebenes Programm, den bytecode verifier, auf unzulässige Anweisungen überprüft und dann interpretiert, also auf die langsame direkte Art ausgeführt. Dadurch benötigt es rund 20mal so viel Zeit, wie wenn es auf herkömmliche Weise kompiliert worden wäre.

Allerdings kann der immer noch anhaltende Geschwindigkeitszuwachs der Hardware auf die Dauer auch derartige Leistungsverluste kompensieren. Außerdem ist für einen Browser die Rechendauer immer noch klein verglichen mit der Zeit, die der Benutzer vor dem Bildschirm sich überlegt, was er als nächstes sehen will.

Prinzipiell spricht auch nichts dagegen, anstelle eines Interpreters für Bytecode gleich einen Compiler zu schreiben. Solange dieser vertrauenswürdig ist und auf dem vertrauenswürdigen Gerät des Benutzers arbeitet, ist dadurch die Sicherheit nicht beeinträchtigt. Aber offensichtlich ist das bei Sun Microsystems nicht erste Priorität.

Dagegen gibt es bereits jetzt eine Art Amateurausgabe von Java: JavaScript oder "koffeinfreies Java", wie lästerliche Zungen im Netz es genannt haben. Die Möglichkeiten sind geringer, die Regeln einfacher, und der Quellcode wird nicht erst in Bytecode umgewandelt, sondern direkt versandt. Also ist JavaScript noch langsamer als Java – aber ohne große Vorkenntnisse programmierbar. Ein solches Script läßt zum Beispiel auf der Web-Hauptseite von Spektrum der Wissenschaft (https://www.spektrum.de) wie bei einem Nachrichtenticker einen Text durch ein kleines Fenster laufen.


Dialog mit den Anwendern

Java ist ein Kind des Internet – in vielerlei Hinsicht. Alles, was man zum Programmieren in dieser Sprache braucht, steht im Netz zur Abholung bereit (http://www.javasoft.com); Diskussionen, neue Programme, Konstruktionsfehler und deren Behebung werden ebenfalls über das Netz verbreitet. Wie allgemein üblich, kassiert die Firma Sun nichts für den Abruf ihres Materials; wann und wie sie mit ihrem Produkt Geld verdienen wird, ist bislang noch unklar.

Weil es so einfach ist, an das Material zu kommen, haben bereits sehr viele Anwender mit dem System gespielt. Wahrscheinlich ist die Software dadurch in wenigen Monaten intensiver getestet worden als andere Programme in mehreren Jahren. Dabei zeigten sich auch Sicherheitslücken (Bild 2 auf Seite 22).

Schließlich erfährt man im Internet wegen der dort üblichen Geschwätzigkeit Dinge, die sonst wahrscheinlich über den kleinen Kreis der Eingeweihten nicht hinausgedrungen wären. So bekennen die Autoren von Java freimütig, daß sie unter anderem auch die Absicht verfolgten, die Marktstrategie eines Quasi-Monopolisten wie Microsoft zu unterlaufen: Wenn man sich seine Standard-Programme nach Bedarf aus jeweils den neuesten Applets zusammenstellen kann, muß man nicht mehr das große teure Universalpaket von Microsoft kaufen, das ohnehin wenige Monate später durch die nächste Version zu ersetzen ist.

Ironischerweise kann das nur gelingen, wenn Java selbst eine monopolartige Stellung auf dem Softwaremarkt erlangt. Welche Abhängigkeiten sich dadurch ergeben, ist noch nicht abzusehen.


Aus: Spektrum der Wissenschaft 7 / 1996, Seite 17
© Spektrum der Wissenschaft Verlagsgesellschaft mbH