| Titel | Inhalt | Suchen | Index | DOC | Handbuch der Java-Programmierung, 3. Auflage |
| << | < | > | >> | API | Kapitel 1 - Was ist Java? |
Wie bereits im Vorwort erwähnt, wollen wir uns der Java-Euphorie gerne anschließen, sie aber nicht vollkommen kritiklos übernehmen. In diesem Abschnitt soll der Versuch unternommen werden, eine kurze Bewertung zu geben und einige der häufigsten Mißverständnisse auszuräumen. Wir wollen dabei zunächst zu einigen Thesen Stellung nehmen, die immer wieder artikuliert werden und häufig zu überzogenen oder falschen Annahmen über das Wesen von Java führen.
Das ist vollkommen falsch, denn JavaScript ist eine von Netscape entwickelte Script-Sprache zur Erweiterung von HTML-Seiten. Sie ist syntaktisch an Java angelehnt, bietet aber bei weitem nicht so viele Features. Sie wird nicht in Bytecode kompiliert, sondern vom Browser interpretiert und erlaubt weder die Konstruktion von Applets noch von eigenständigen Applikationen. Als Script-Sprache ist sie vorwiegend für einfache Manipulationen am Layout und der Interaktionsfähigkeit von HTML-Seiten gedacht.
Diese gern wiederholte These aus der Sprachbeschreibung ist nur bedingt richtig. Java ist eine objektorientierte Programmiersprache mit fortschrittlichen Eigenschaften und muß wie eine solche erlernt werden. Sie ist einfacher zu beherrschen als C oder C++, und es gibt weniger Raum für Anfängerfehler. Auch die Klassenbibliothek ist leichter zu verwenden, denn sie wurde neu entworfen und kommt ohne die Altlasten nicht-objektorientierter Vorgänger daher. Die Kompatibilitätsanforderungen von mittlerweile vier JDK-Folgeversionen (1.1, 1.2, 1.3 und 1.4) merkt man ihr aber durchaus an. Vor allem wegen des großen Umfangs der Klassenbibliotheken erfordert der Umgang mit Java ein nicht zu unterschätzendes Maß an Einarbeitungszeit, bevor man als Entwickler zu produktiven Ergebnissen kommt.
Die Quellcode-Portabilität von Java-Programmen ist auf der reinen Sprachebene etwas höher als die von C- oder C++-Programmen. Das ist hauptsächlich dem Verzicht auf explizite Pointer sowie maschinennahe Datentypen und Operatoren zu verdanken. Auch die genaue Spezifikation der elementaren Datentypen trägt zu dieser Tatsache bei.
Bezieht man dagegen die riesige Klassenbibliothek mit ihren auf allen Plattformen standardmäßig vorhandenen Funktionen in die Betrachtung ein, fallen C und C++ im Portabilitätsvergleich um Lichtjahre zurück. Funktionalitäten wie Datenbankzugriffe, Netzwerkprogrammierung, Multithreading, Serialisierung, Grafikprogrammierung und viele andere mehr sind in Java bereits in der Grundversion enthalten und stehen auf allen Plattformen in derselben Weise zur Verfügung.
Ein weiterer Portabilitätsvorteil von Java besteht zudem darin, daß die kompilierten Programme binärkompatibel sind. Ein einmal übersetztes Programm wird auf jeder Plattform laufen, die eine Java-VM und die erforderliche Laufzeitumgebung zur Verfügung stellt. Ein Rekompilieren, wie es bei C- oder C++-Programmen erforderlich ist, benötigen Java-Programme daher nicht.
Da Java-Programme in Bytecode übersetzt werden, der nicht direkt vom Prozessor ausgeführt werden kann, muß ein Interpreter diese Aufgabe übernehmen. Dadurch können CPU-lastige Java-Programme um den Faktor 10 bis 20 langsamer sein als vergleichbare C/C++-Programme.
Dieses Argument wird auch heute noch gern von der C-/C++-Fraktion angeführt. In der Praxis relativiert es sich durch mehrere Faktoren. Einerseits sind nur wenige Programme ausgesprochen CPU-intensiv. Die meisten interaktiven Programme verbringen nämlich einen Großteil ihrer Zeit damit, auf Eingaben des Benutzers oder langsame Datenbank- oder Festplattenzugriffe zu warten. Zudem wurde das Laufzeitverhalten von Java-Programmen durch die Entwicklung von Just-In-Time-Compilern, Native-Code-Compilern oder Java-Prozessoren in den letzten Jahren stetig verbessert und nähert sich zunehmend der von kompiliertem C/C++-Code an. Die seit dem JDK 1.3 zum Umfang des JDK gehörenden HotSpot-Compiler analysieren zur Laufzeit des Programmes den interpretierten Bytecode und übersetzen besonders rechenintensive Teile in direkt ausführbaren Maschinencode.
Das Performance-Problem kann daher als temporäres Problem angesehen werden - falls es für den speziellen Typ Anwendung überhaupt noch existiert. Viele Beobachter gehen heute davon aus, daß Java-Programme bald mit derselben Geschwindigkeit laufen werden wie kompilierte C/C++-Programme. Benchmarks zeigen diese Ergebnisse in Teilbereichen schon heute. Auch die anfänglichen Performance-Probleme von Swing-Oberflächen wurden mit dem JDK 1.3 und den aktuellen Entwicklungen auf dem Prozessormarkt weitgehend unschädlich gemacht.
Allerdings kann der unachtsame Entwickler in Java sehr leicht zu einer schlechten Performance beitragen. Wer die abstrakten Designmöglichkeiten von Strings, Readern oder Writern, Collection-Klassen und vielen anderen Bestandteilen der Klassenbibliothek bedenkenlos verwendet, kann das Laufzeitverhalten seines Programmes stark beeinträchtigen. Schon mit der Kenntnis einiger Details über den Aufbau wichtiger JDK-Klassen lassen sich die vorhandenen Bibliotheken weit effizienter nutzen, und die Performance der Programme steigt an. In Kapitel 49 gehen wir auf einige dieser Details ein und zeigen, wie man Java-Programme schreibt, deren Performance für viele Anwendungen adäquat ist.
Diese Behauptung resultiert vor allem aus drei Beobachtungen. Zum einen hatten viele der zunächst in Java entwickelten Anwendungen Spielzeug- oder Democharakter. Meist als Applet realisiert, hatten sie lediglich die Aufgabe, eine Homepage zu verschönern oder die Java-Kentnisse ihrer Entwickler zu demonstrieren. Echten Nutzwert boten dagegen nur wenige, und größere Applikationen, die komplett in Java geschrieben wurden, waren zunächst kaum auf dem Markt. Dies hat sich mittlerweile vollständig geändert. Es gibt hunderte, wahrscheinlich tausende von ausgewachsenen Java-Applikationen aus allen nur erdenklichen Anwendungsgebieten.
Zweitens war das Look-and-Feel von Java-Programmen nicht ausgereift. Tatsächlich bildet das AWT nur einen geringen Anteil der in den jeweiligen plattformspezifischen Fenstersystemen verfügbaren Möglichkeiten ab. Die wenigen Dialogelemente stehen allerdings portabel zur Verfügung. Mit Hilfe des Swing-Toolsets kann dieses Problem als gelöst angesehen werden. Swing bietet einen umfassenden Satz komplexer Dialogelemente und stellt ihn plattformübergreifend zur Verfügung. Dabei ist es möglich, das Look-and-Feel der jeweiligen Anwendung zur Laufzeit umzustellen und so dem Geschmack und den Kenntnissen des jeweiligen Benutzers anzupassen.
Die dritte Beobachtung besagt, daß Java voller Fehler steckt. Während dies weniger für die Sprache selbst, ihre Werkzeuge oder die elementaren Eigenschaften der Klassenbibliothek gilt, konnten die frühen Grafikbibliotheken ein gewisses Maß an Fehlerhaftigkeit nicht verhehlen. Zwar gibt es nach wie vor Fehler im JDK (alle bekannten Bugs sind in der als Bug Parade bezeichneten Fehlerdatenbank gespeichert), doch sind diese in aller Regel nicht so schwerwiegend, daß nicht ein Workaround gefunden werden könnte. Zudem stecken die Fehler meist in den Klassenbibliotheken. Der Compiler und die virtuelle Maschine, auf der die ausführbaren Programme laufen, können für die meisten Anwendungen als hinreichend stabil angesehen werden. Auch hier gibt es Ausnahmen, insbesondere bei JDK-Portierungen auf weniger gebräuchliche Betriebssysteme. Auf den meisten Systemen ist das JDK in der täglichen Praxis jedoch ein ausgesprochen stabiles, zuverlässiges und hinreichend schnelles Entwicklungswerkzeug.
Wenn man das Anwenderinteresse zugrunde legt, ist Java schon jetzt die mit Abstand erfolgreichste Programmiersprache der letzten Jahre. Wie oben gezeigt, hat die Sprache in den wenigen Jahren seit Ausgabe der Version 1.0 eine immense Verbreitung erfahren. Java war Anlaß für Tausende von Büchern und Zeitschriftenartikeln, und es entstanden eine Reihe von stark frequentierten Newsgroups, die das Interesse an Java deutlich machen. Alle größeren Softwarehersteller unterstützen die Sprache und haben konkrete Produkte realisiert. In den meisten einschlägigen Stellenanzeigen werden Java-Kenntnisse verlangt.
Zeitgleich zur Diskussion um die Eignung Javas als Entwicklungswerkzeug für grafische Oberflächen hat sich ein Wandel auf der Serverseite vollzogen. Mit dem Servlet-API und den Java Server Pages haben sich beispielsweise im Bereich der Generierung dynamischer Web-Seiten Techniken etabliert, die dem traditionellen CGI-Scripting Konkurrenz machen. Daneben setzen große Softwarehersteller auf mehrschichtige Client-Server-Architekturen mit Java-Unterstützung (Oracle Financials, Star Office) oder statten ihre Datenbank- oder Web-Server mit Java-Fähigkeiten aus (Oracle 8, Lotus Domino, SUN Java Web Server, Apache jserv). In vielen Unternehmen gibt es bereits verteilte Anwendungen, die auf die plattformübergreifenden Fähigkeiten und die Binärkompatibilität von Java-Anwendungen setzen.
Auch auf der Client-Seite ist seit einiger Zeit ein Trend zu Java zu beobachten. So gibt es »kleine« Java-Anwendungen, die auf dem Palm Pilot, dem Psion 5 oder in Mobiltelefonen laufen. Aber auch komplexe Standalone-Programme wie - beispielsweise aus dem Bereich der Entwicklungswerkzeuge - JBuilder, NetBeans (Forte), Together/J oder OptimizeIt werden mittlerweile in Java entwickelt. Viele Unternehmen setzen Java ein, um die Produktivität bei der Entwicklung graphischer Oberflächen zu erhöhen, oder verbinden in Java geschriebene Frontends mit den vorhandenen batchorientierten Applikations- und Datenbankservern. Nicht selten führt der Umstieg von C/C++ auf Java zu drastischen Effizienzsteigerungen bei der Entwicklung und Portierung komplexer Anwendungssysteme.
Neben der plattformübergreifenden Portabilität von Bytecode und grafischer Oberfläche bietet Java Dinge wie Datenbankanbindung, Multithreading oder Netzwerkprogrammierung ohne architektonische Brüche. Mit der »Pflicht«, objektorientiert zu programmieren (im Gegensatz zu C++ gibt es in Java keine legitimierte Möglichkeit, rein prozedurale Programme zu schreiben), muß der Entwickler einen weiteren Schritt in der Evolution seiner eigenen Fähigkeiten vollziehen. Applets, Servlets und der Austausch von Bytecode zwischen Anwendungen wurde erst mit Java salonfähig. Mit weltweit mehreren Millionen Java-Entwicklern ist die kritische Masse zur (irreversiblen) Etablierung dieser neuen Techniken sicher erreicht.
Natürlich kann heute niemand sagen, ob Java auch langfristig erfolgreich sein und als Programmiersprache auch in zehn oder zwanzig Jahren eine Rolle spielen wird. Das derzeitige und nach mittlerweile 7 Jahren immer noch steigene Entwicklerinteresse spricht allerdings sehr dafür. Programmiersprachen und -methoden werden nicht von heute auf morgen ausgewechselt, denn Paradigmenwechsel brauchen ihre Zeit. Vorhandener, mit viel Mühe erstellter Quellcode wird nicht einfach weggeworfen. Auch 20 Jahre alte COBOL-, RPG- und FORTRAN-Programme werden heute noch gewartet, wenn auch mit sinkender Tendenz. Java hat seinen Zenit noch nicht einmal erreicht, und neuer Code auf Basis von Java wird in nach wie vor zunehmendem Maße entwickelt. So kann die Prognose gewagt werden, daß Java auch im Jahre 2010 und darüber hinaus nennenswerte Bedeutung haben wird.
Wer heute auf Erfahrungen in Java-Programmierung zurückgreifen kann, hat morgen möglicherweise den entscheidenden Vorteil im Wettbewerb mit der Konkurrenz.
| Titel | Inhalt | Suchen | Index | DOC | Handbuch der Java-Programmierung, 3. Auflage, Addison Wesley, Version 3.0.1 |
| << | < | > | >> | API | © 1998-2003 Guido Krüger, http://www.javabuch.de |