| Titel | Inhalt | Suchen | Index | API | Go To Java 2, Zweite Auflage, Handbuch der Java-Programmierung |
| << | < | > | >> | Kapitel 1 - Was ist Java? | |
Wie bereits im Vorwort erwähnt, wollen wir uns der Java-Euphorie gerne anschließen, sie aber nicht bedingungslos übernehmen. In diesem Abschnitt soll der Versuch unternommen werden, eine 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 postulierte 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 verstehen, denn sie wurde neu entworfen und kommt ohne die Altlasten von gewachsenen Bibliotheken aus (allerdings merkt man auch ihr die vier JDK-Versionen 1.0, 1.1, 1.2 und 1.3 mittlerweile durchaus an). Trotz allem erfordert der Umgang mit Java und seinen Bibliotheken ein nicht zu unterschätzendes Maß an Einarbeitungszeit, bevor man als Entwickler zu produktiven Ergebnissen kommt.
Die Quellcode-Portabilität von Java-Programmen ist etwas höher als die von C- oder C++-Programmen. Das ist hauptsächlich dem Verzicht auf explizite Pointer, maschinennahe Datentypen und Operatoren zu verdanken. Auch die genaue Spezifikation der elementaren Datentypen und die sehr viel größere Zahl an Standard-Bibliotheken tragen zur höheren Quellcode-Portabilität bei.
Der wichtigere Portabilitätsvorteil von Java besteht jedoch darin, daß die kompilierten Programme binärkompatibel sind. Ein einmal übersetztes Programm, das innerhalb des Java-Standards entwickelt wurde, wird auf jeder Plattform laufen, die eine Java-VM und die erforderliche Laufzeitumgebung zur Verfügung hat.
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 rechenintensive Java-Programme um den Faktor 10 bis 20 langsamer sein als vergleichbare C/C++-Programme.
Dieses schlechte Ergebnis relativiert sich in der Praxis durch mehrere Faktoren. Einerseits sind nur wenige Programme ausgesprochen rechenintensiv. Statt dessen verbringen sie oft einen Großteil ihrer Zeit damit, auf Eingaben des Benutzers oder langsame Datenbank- oder Festplattenzugriffe zu warten. Zudem steigt die Performance von Java-Programmen durch die Entwicklung von Just-In-Time-Compilern, Native-Code-Compilern oder Java-Prozessoren ständig und nähert sich zunehmend der von kompiliertem C/C++-Code an.
Das Performance-Problem kann daher als temporäres Problem angesehen werden - falls es für den speziellen Typ Anwendung überhaupt 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 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 48 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. Größere Applikationen, die komplett in Java geschrieben wurden, waren zunächst kaum auf dem Markt.
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 sie in aller Regel nicht so schwerwiegend, daß nicht ein Workaround gefunden werden könnte. Zudem stecken die Fehler 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.
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 vier Jahren seit Ausgabe der Version 1.0 eine immense Verbreitung erfahren. Java war Anlaß für Hunderte 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 vielen Stellenanzeigen werden Java-Kenntnisse verlangt.
Zeitgleich zur Diskussion um die Eignung Javas als Entwicklungswerkzeug für grafische Oberflächen hat sich bereits ein Wandel auf der Serverseite angedeutet. 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 auf der Basis von CORBA, 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 MX oder in Mobiltelefonen laufen; aber auch komplexe Standalone-Programme wie JBuilder 3.5, NetBeans (Forte), Together/J oder OptimizeIt. Viele Unternehmen setzen Java ein, um die Produktivität bei der Entwicklung graphischer Oberflächen zu erhöhen, und verbinden in Java geschriebene Frontends mit den vorhandenen batchorientierten Applikations- und Datenbankservern.
Natürlich kann heute niemand sagen, ob Java auch langfristig erfolgreich sein wird und als Programmiersprache auch in zehn oder zwanzig Jahren eine Rolle spielen wird. Das derzeitige Entwicklerinteresse spricht allerdings stark dafür. Programmiersprachen und -methoden werden nicht von heute auf morgen ausgewechselt, denn Paradigmenwechsel brauchen ihre Zeit. Sind sie erst einmal vollzogen, gibt es in aller Regel kein Zurück mehr.
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 sinnvolle 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 ebenfalls erst mit Java salonfähig. Mit weltweit mehreren Millionen Java-Entwicklern ist die kritische Masse zur (irreversiblen) Etablierung dieser neuen Techniken bereits heute vermutlich erreicht.
Auch die umfassenden Aktivitäten aller großen Hard- und Softwarehersteller und ihre Bekenntnisse zu Java lassen erwarten, daß die Kinderkrankheiten ausgemerzt und in naher Zukunft stabile und performante Java-Applikationen in großer Zahl nachgefragt und ausgeliefert werden. Wer dann bereits auf Erfahrungen in Java-Programmierung zurückgreifen kann, hat möglicherweise den entscheidenden Vorteil im Wettbewerb mit der Konkurrenz.
| Titel | Inhalt | Suchen | Index | API | Go To Java 2, Zweite Auflage, Addison Wesley, Version 2.0 |
| << | < | > | >> | © 2000 Guido Krüger, http://www.gkrueger.com | |