From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- .../hjp5/html/k100011.html | 331 +++++++++++++++++++++ 1 file changed, 331 insertions(+) create mode 100644 Master/Reference Architectures and Patterns/hjp5/html/k100011.html (limited to 'Master/Reference Architectures and Patterns/hjp5/html/k100011.html') diff --git a/Master/Reference Architectures and Patterns/hjp5/html/k100011.html b/Master/Reference Architectures and Patterns/hjp5/html/k100011.html new file mode 100644 index 0000000..4362f3b --- /dev/null +++ b/Master/Reference Architectures and Patterns/hjp5/html/k100011.html @@ -0,0 +1,331 @@ + + + +Handbuch der Java-Programmierung, 5. Auflage + + + + + + + + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage +
 <<  +  <   +  >   + >>  + API  +Kapitel 1 - Was ist Java? +
+
+ + + + +

1.3 Bewertung

+
+ +
+ + + + +

1.3.1 Einige weitverbreitete Missverständnisse ...

+ +

+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 Missverstä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

+ +

+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. + + + + +

These 2: Java ist einfach zu erlernen

+ +

+Diese gern wiederholte These aus der Sprachbeschreibung ist nur bedingt +richtig. Java ist eine objektorientierte Programmiersprache mit fortschrittlichen +Eigenschaften und muss 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 +sechs JDK-Folgeversionen (1.1-1.4, 5.0 und 6.0) 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. + + + + +

These 3: Java ist portabel

+ +

+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 weit +zurück. Funktionalitäten wie Datenbankzugriffe, Netzwerkprogrammierung, +Multithreading, Serialisierung, Grafikprogrammierung +und viele andere mehr sind in Java bereits in der Standardversion +enthalten und stehen auf allen Plattformen in praktisch identischer +Weise zur Verfügung. + +

+Ein weiterer Portabilitätsvorteil von Java besteht zudem darin, +dass 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. + + + + +

These 4: Java-Programme sind langsam

+ +

+Da Java-Programme in Bytecode übersetzt werden, der nicht direkt +vom Prozessor ausgeführt werden kann, muss 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 +(JIT-Compiler), Native-Code-Compilern oder Java-Prozessoren in den +letzten Jahren stetig verbessert und nähert sich zunehmend dem +von kompiliertem C/C++-Code an. Die seit dem JDK 1.3 zum Umfang des +JDK gehörenden HotSpot-Compiler analysieren zur Laufzeit des +Programms 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, dass Java-Programme +in den meisten praktisch relevanten Situationen mit derselben Geschwindigkeit +laufen wie kompilierte C/C++-Programme, und Benchmarks bestätigen +diese Ergebnisse bereits. Auch die anfänglichen Performance-Probleme +der Swing-Oberflächen wurden mit dem JDK 1.3 und seinen Nachfolgeversionen +weitgehend unschädlich gemacht. Auch der nach wie vor anhaltende +Fortschritt bei der Hardware-Entwicklung hat seinen Beitrag geleistet. +Während die ersten Java-Versuche meist auf PCs der Kategorie +Pentium-I mit 75 MHz und 8 MByte RAM abliefen, haben die aktuellen +CPUs die 3GHz-Marke überschritten, und 512 MB Hauptspeicher zählen +zum guten Ton. + +

+Dennoch kann der unachtsame Entwickler in Java leicht zu einer schlechten +Gesamtperformance 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 Programms 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 50 +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 Demo-Charakter. Meist als Applet realisiert, hatten +sie lediglich die Aufgabe, eine Homepage zu verschönern oder +die Java-Kentnisse ihrer Entwickler im zweckfreien Raum 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 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, dass Java voller Fehler steckt. Während +dies weniger für die Sprache selbst, ihre Werkzeuge oder die +elementaren Eigenschaften der Klassenbibliothek galt, 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, dass 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 mittlerweile +auch sehr performantes Entwicklungswerkzeug. + + + + +

1.3.2 Ausblick

+ +

+Wenn man das Anwenderinteresse zugrunde legt, ist Java 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 gibt auch einige +Zeitschriften, die sich ausschließlich mit Java beschäftigen. +Zudem 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 Webseiten 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 - IntelliJ IDEA, JBuilder, NetBeans (Forte) +oder OptimizeIt werden mittlerweile in Java entwickelt. Viele Unternehmen +setzen Java ein, um die Produktivität bei der Entwicklung grafischer +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), muss 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 Etablierung +dieser neuen Techniken 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 +fast 10 Jahren immer noch anhaltende Entwicklerinteresse spricht allerdings +sehr dafür. Programmiersprachen und -methoden werden nicht von +heute auf morgen ausgewechselt, denn Paradigmenwechsel brauchen ihre +Zeit. Vorhandener, mit viel Aufwand erstellter Quellcode wird nicht +einfach weggeworfen. Auch 20 Jahre alte COBOL-, RPG- und FORTRAN-Programme +werden heute noch gewartet, denn Investitionen in Hard-, Soft- und +Brainware sind nicht von heute auf morgen austauschbar. Java hat seinen +Zenit noch nicht erreicht, und neuer Code auf Basis von Java +wird in nach wie vor zunehmendem Maße entwickelt. So kann die +Prognose gewagt werden, dass Java auch im Jahre 2010 und darüber +hinaus nennenswerte Bedeutung haben wird. Wer also auf Erfahrungen +in Java-Programmierung zurückgreifen kann, hat möglicherweise +den entscheidenden Vorteil im Wettbewerb mit der Konkurrenz. +

+ + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage, Addison +Wesley, Version 5.0.1 +
 <<  +  <   +  >   + >>  + API  +© 1998, 2007 Guido Krüger & Thomas +Stark, http://www.javabuch.de +
+ + + -- cgit v1.2.3