Tit   Inh   Ind   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   <<   <   >   >> 

1.3 Bewertung



1.3.1 Einige weit verbreitete Mißverständnisse ...

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.

These 1: Java == JavaScript

Das ist vollkommen falsch, denn JavaScript ist eine von Netscape entwickelte, proprietäre 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 erlaubt sie einfache Manipulationen am Layout und der Interaktionsfähigkeit von HTML-Seiten.

These 2: Java ist einfach zu lernen

Diese gern postuliert 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 und für Fehler in sehr großen Programmen. Auch die Klassenbibliothek ist leichter zu verstehen, denn sie wurde neu entworfen und kommt ohne die Altlasten von gewachsenen Bibliotheken aus (allerdings merkt man ihr die drei JDK-Versionen 1.0, 1.1 und 1.2 in einigen Bereichen 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.

These 3: Java ist portabel

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.

These 4: Java-Programme sind langsam

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 Umstände. 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 in einigen Jahren mit derselben Geschwindigkeit laufen werden wie kompilierte C/C++-Programme.

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 29 gehen wir auf einige dieser Details ein und zeigen, wie man Java-Programme schreibt, deren Performance für viele Anwendungen adäquat ist.

These 5: Java ist nicht für ernsthafte Anwendungen geeignet

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 Applets. Größere Applikationen, die komplett in Java geschrieben wurden, waren zunächst kaum auf dem Markt.

Zweitens war das Look & 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 sollte dieses Dilemma gelöst werden. Swing bietet einen umfassenden Satz komplexer Dialogelemente und stellt ihn plattformübergreifend zur Verfügung. Dabei ist es möglich, das Look&Feel der jeweiligen Anwendung zur Laufzeit umzustellen und so dem Geschmack und den Kenntnissen des jeweiligen Benutzers anzupassen. Allerdings hinkt sowohl die Performance als auch die Stabilität von Swing noch hinter der von vergleichbaren plattformspezifischen Libraries (insbesondere unter Windows) hinterher.

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, kann das AWT ein gewisses Maß an Fehlerhaftigkeit nicht verhehlen. Obwohl mit der Version 1.1 viele der frühen Bugs behoben wurden, kann es auch in seiner heutigen Fassung nicht als ausgesprochen stabiles System bezeichnet werden. Die aktuellen Auslieferungen des JDK 1.2 wurden einem aufwendigen Qualitätssicherungsprogramm mit mehrmonatigem Beta-Test und einer mehrstufigen Auslieferung des endgültigen Releases unterzogen (»release candidates«).

Tatsächlich hat sich in den letzten Monaten - zeitgleich zur Diskussion um die Eignung Javas als Entwicklungswerkzeug für grafische Oberflächen - bereits ein Wandel auf der Serverseite angedeutet. Mit dem Servlet-API hat sich beispielsweise im Bereich der Generierung dynamischer Web-Seiten eine Technik etabliert, die dem traditionellen CGI-Scripting ernsthafte Konkurrenz macht. Daneben setzen große Softwarehersteller auf mehrschichtige Client-Server-Architekturen mit Java-Unterstützung (Oracle Financials, Star Office) oder statten ihre Datenbankserver (Oracle 8) oder Web-Server (Lotus Domino, SUN Java Web Server, Apache jserv) mit Java-Fähigkeiten aus. 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.

1.3.2 Wird Java erfolgreich sein?

Wenn man das Anwenderinteresse zugrunde legt, ist Java schon jetzt die mit Abstand erfolgreichste Programmiersprache der letzten Jahre. Wie oben gezeigt, hat Java in den ersten drei Jahren seit Ausgabe der Version 1.0 eine immense Verbreitung erfahren. Die Sprache war Anlaß für Hunderte von Büchern und Zeitschriftenartikeln, und es entstand 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 bereits heute Java-Kenntnisse vom Bewerber verlangt.

Natürlich kann heute niemand sagen, ob Java auch langfristig erfolgreich sein wird und als Programmiersprache auch in zehn oder zwanzig Jahren noch eine Rolle spielen wird. Drei der Kernfaktoren, die den Erfolg von Java ausmachen, sprechen allerdings schon heute dafür:

1.3.3 Fazit

Was überwiegt nun? Die Vorteile oder die Nachteile? Diese Frage sollte jeder für sich selbst beantworten. Dieses Buch wäre nicht geschrieben worden, wenn der Autor nicht der Meinung wäre, daß es die Vorteile sind.

Tatsächlich läßt sich Java heute ohne weiteres dazu verwenden, anspruchsvolle Programme, Tools oder Applets zu entwickeln. Wie dabei mit den bekannten Nachteilen und Unzulänglichkeiten umzugehen ist, muß projektbezogen entschieden werden. Natürlich gibt es dabei eine Korrelation zwischen Innovativität und einer gewissen Unausgereiftheit.

Alleine die umfassenden Aktivitäten aller großen Hard- und Softwarehersteller und ihre Bekenntnisse zu Java lassen erwarten, daß die Kinderkrankheiten ausgemerzt werden und in nicht allzu ferner Zukunft eine Reihe stabiler und ausgereifter Entwicklungsumgebungen zur Verfügung stehen wird. Wer dann bereits auf Erfahrungen in Java-Programmierung zurückgreifen kann, hat möglicherweise den entscheidenden Vorteil im Wettbewerb mit der Konkurrenz.


 Tit   Inh   Ind   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   <<   <   >   >> 
Go To Java 2, Addison Wesley, Version 1.0.2, © 1999 Guido Krüger, http://www.gkrueger.com