1 What's new?

Lassen Sie uns gleich damit beginnen, uns an die faszinierende Welt von Java heranzutasten. Bevor wir jedoch zur eigentlichen Java-Schnuppertour kommen, sollen für die Leser, die Java bereits kennen, kompakt die Neuerungen von Java 2.0 und dem JDK 1.2/1.3 aufgeführt werden.

In diesem Abschnitt wird eine gewisse Vertrautheit mit den wichtigsten Begriffen von Java und seinem Umfeld vorausgesetzt. Wer sich mit Java noch nicht auskennt, kann gerne später auf diesen Abschnitt zurückkommen.

1.1 Java 1.2, Java 2.0, JDK 1.2 und JDK 1.3

Java 2.0! Erheblich verspätet, aber dafür mit umso lauterem Getöse ging Java nach dem fulminanten 1.0-Einstieg und den Zwischenversionen 1.1 und 1.2 (Beta) Anfang 1999 in die zweite Runde. Im Dezember 1998 hatte Sun Microsystem (der »Eigentümer« von Java) endlich die bereits Anfang 1998 angekündigte und mehrfach verschobene Finalversion des JDK 1.2 (Java Development Kit) - der Java-Entwicklungsumgebung - freigegeben. Kurz danach gab Sun auf der Java Business Expo bekannt, dass es nicht nur ein neues JDK, sondern ein vollständiges Plattform-Update unter dem Namen Java 2.0 gibt.

Diese Namenspolitik überraschte zum damaligen Zeitpunkt doch ziemlich, denn es schien bis dahin klar, dass das vollständige Update der bis dahin vertriebenen JDK-Finalversion 1.1 und seiner ergänzenden Tools als Version 1.2 in Umlauf kommt. So ganz überzeugt von seiner Namenspolitik scheint auch Sun nicht gewesen zu sein, denn das erste JDK von Java 2 - Kern der Java-2.0-Plattform - wurde innerhalb der Java-2.0-Plattform als JDK 1.2 eingeführt und auch das neue JDK von Java 2 läuft als Version 1.3. Sogar Publikationen zur Gesamtplattform wurden von Sun Microsystems noch Anfang 1999 unter dem Titel »Java 1.2« veröffentlicht. Aber um es gleich vorab festzuhalten - die Veränderungen des Java-APIs (API ist die Abkürzung für Application Programming Interface -Programmier- und Anwendungsschnittstelle), die sich noch zwischen den Betaversionen des JDK 1.2 und der als Final freigegebenen Version ergeben haben, erzwangen eine solche Namenspolitik fast unweigerlich. Es war leider so, dass beispielsweise das API der dritten Betaversion 1.2 und das 1.2/2.0-Final-API extrem viele Unterschiede aufwiesen. Der Oberbegriff »Java 2« macht den Break zu den Vorgängerversionen (insbesondere den inkompatiblen Betaversionen) deutlich. Mit der Einführung des JDK 1.2 und der Java-2-Plattform hatte Sun endlich einen Stand geschaffen, von dem aus es weitgehend um die Verbesserung der Stabilität (ein rigoroses Qualitätssicherungsprogramm) und Performance (Vervollkommnung der virtuellen Maschine) ging. Davor lag der Hauptfokus auf dem Ausbau und der Entwicklung von neuen Features und der Beseitigung von Schwachstellen. Zwischen dem JDK 1.2 und dem Mitte 2000 eingeführten JDK 1.3 (Codename Kestrel) hingegen sind die Unterschiede nicht mehr so gravierend, weshalb Java 2 ohne gravierende Probleme als Obermenge für beide JDK-Welten fungieren kann. Vor allem sind die Veränderungen von dem JDK 1.3 fast nur als echte Erweiterungen und Verbesserungen zu sehen, die keine gravierenden Inkompatibilitäten zum JDK 1.2 nach sich ziehen. Dementsprechend werden das JDK 1.3 wie auch das JDK 1.2 und die dazwischen liegenden Versionen JDK 1.2.1 und 1.2.2 zur Java-2-Plattform gezählt. Die vielleicht bedeutendste Erweiterung des JDK 1.3 ist die Einführung der HotSpot-Technologie. Diese beinhaltet im Wesentlichen eine so genannte adaptive Compilertechnologie, bei der interpretierte Programmteile bei Bedarf zur Ausführungszeit des Programms in Maschinencode übersetzt werden kann. Dazu zählt ebenso eine geschwindigkeitsoptimierte virtuelle Maschine für den Client und die zugehörigen, mit dem JDK 1.3 neu eingeführten neuen Optionen bei einigen Programmen des JDK. >

Der Mischmasch der Versionen führt bei vielen Betrachtern zu Verwirrung. Deshalb zur Klärung - wir werden uns in dem Buch mit Java 2.0 und vor allem dem dazu gehörenden JDK 1.3 beschäftigen, aber die Aussagen gelten auch meist für das JDK 1.2. Allgemein wird das gesamte Konzept zur Entwicklung von Applikationen für Java 2 mit dem JDK 1.3 unter »Java 2 SDK« zusammengefasst (SDK steht für Software Development Kit).

Wesentlicher Unterschied zwischen der vollständigen Java-Plattform und dem JDK ist, dass die Plattform weitere APIs, Programme, Tools und Konzepte enthält. Hierzu zählen das JSDK (Java Servlet Development Kit), das bis zur Beta 4-Version des JDK 1.2 noch zu diesem gezählt hatte, oder auch andere Tool-Pakete, die die Funktionalität des JDK erweitern. Die aktuelle Java-2-Plattform und das Java 2 SDK (Java 2 Software Development Kit) beinhalten unter anderem folgende Basiselemente:

Das Konzept der zur Java-2-Plattform gehörenden Java Foundation Classes (JFC) beinhaltet folgende Details:

Zu den erweiterten Features des Java-2-SDKs zählen die folgenden Konzepte:

Das Java-2-SDK beinhaltet zudem einen Tool Support, der folgende Konzepte enthält:

Die wesentlichen Neuerungen der Java-2-Plattform gegenüber den Vorgängerversionen konzentrieren sich auf die Bereiche Sicherheit, Interoperabilität mit anderen Systemen, Plattformneutralität, Geschwindigkeitssteigerung, Internationalisierung und Vereinfachung der Entwicklungstätigkeit. Prinzipiell sollte man dabei festhalten, dass schon im Schritt von 1.0.x auf die Final 1.1.x-Versionen erhebliche Veränderungen stattfanden. Leider gab es aber auch viele Veränderungen im Laufe der vier Betaversionen des JDK 1.2, weshalb diese Betaversionen in vielen Bereichen nicht mehr mit dem Finalrelease 1.2 (und natürlich erst recht nicht dem JDK 1.3) übereinstimmen. Gerade der Wechsel von der Beta-3-Version auf die wenig beachtete Beta-4-Version des JDK 1.2 beinhaltete zahlreiche und sehr massive Modifikationen, insbesondere auf Ebene des API, aber auch bei Tools. Viele Umsteiger von einem JDK 1.1.x oder einer der drei ersten Betaversionen 1.2 hatten deshalb ziemliche Umstellungsprobleme. Die wichtigsten dieser Reformen und Erweiterungen von Java und des JDK bis zu der aktuellen Version sollen im Rahmens dieses Buchs näher erläutert werden. Dabei sind die Änderungen im Detail natürlich so umfangreich, dass wir sie hier nicht allesamt ansprechen können. Glücklicherweise sind eine Menge von Veränderungen auch so speziell, dass »normale« Programmierer davon kaum berührt werden.

1.2 JavaSoft und Sun

»Verantwortlich« für Java ist Sun Microsystems (http://java.sun.com) bzw. JavaSoft - eine Tochterfirma der Firma Sun Microsystems. Wir werden im Folgenden nicht so genau zwischen Sun und JavaSoft trennen, da diese organisatorischen Strukturen für Sie nur am Rande interessant sein dürften. Wie dem auch sei - Sun und JavaSoft halten im Internet permanent die aktuellsten Informationen um Java bereit. Die wichtigsten Informationen kann man in folgende Bereiche klassifizieren:

1.3 Die Java-Neuerungen

Behandeln wir zuerst die Neuerungen, die Java im weiteren Sinn betreffen.

1.3.1 Kompatibilität und das Java-Plug-In

Im Allgemeinen gilt, dass Entwicklungen, die mit einer älteren Version von Java erstellt wurden, ebenso in der virtuellen Maschine der Folgeversionen ohne Probleme laufen sollten. Dies gilt sowohl auf binärer Ebene als auch auf Ebene des Quelltextes (allerdings definitiv ohne Gewährleistung durch Sun). Ausnahmen sind explizit diejenigen Java-Programme, die mit einer der Java-Vorgängerversionen erstellt wurden und die auf Klassen zurückgreifen, in welchen sicherheitsrelevante Löcher festgestellt wurden. Auch einige Java-Programme, die auf Klassen mit Implementations- oder Designbugs zurückgreifen, können unter neuen Versionen unter Umständen nicht mehr laufen. Solche Applikationen müssen bei einer Portierung von älteren auf eine neuere JVM neu kompiliert werden.

Bei der Neukompilierung von älterem Java-Quellcode werden dann ziemliche Schwierigkeiten auftreten, wenn dort Java-Pakete importiert werden, die in dem neuen Konzept nicht mehr vorhanden sind (das ist zwar selten, aber möglich) oder verlagert und/oder umbenannt wurden (das ist leider sehr oft der Fall). Beispielsweise sind die Pakete des gesamten Swing-Konzeptes ab dem JDK 1.2 gegenüber der bisherigen Konzeption (Version 1.1 und sogar Beta 1.2) vollständig verlagert und umbenannt worden. In solchen Fällen muss in dem Java-Quelltext die import-Struktur dem neuen API natürlich angepasst werden. Sie finden dazu im Anhang eine Tabelle.

Insgesamt gab es in der 1.1.1-Version als erste richtige Finalversion nach dem 1.0.x-Standard eine ganze Menge an neuen Funktionalitäten. Innerhalb der einzelnen Zwischenvarianten der 1.1-Versionen fanden dahingegen keine echten Erweiterungen statt, sondern weitestgehend nur Fehlerbereinigungen und interne Optimierungen.

Die erste öffentliche JDK-Version 1.2 Beta wurde während des Jahreswechsels 1997/98 vorgestellt und enthielt doch einige Überraschungen. Insbesondere wurden einige 1.1-Entwicklungen bzw. Features der Vorgänger wieder zu den Akten gelegt, weil sie nicht ganz die Erwartungen erfüllt hatten (ein Sicherheitstool und einige Optionen). Dies bedeutet, dass in der Sicherheitsfunktionalität von Java eine gewisse Inkompatibilität zwischen Java 1.1.x und den Folgeversionen besteht. Zwischen der JDK-Version 1.2 und 1.3 wurden dann kaum noch solche Änderungen durchgeführt, die zu echten Inkompatibilitäten führen können.

Applets

Eine gewisse Schwierigkeit bei Java-Applets ist die Integration von Java-Versionen jenseits von Java 1.0.2 (!) in die gängigen Browser. Applets, die neuere APIs nutzten, setzen einen entsprechend kompatiblen Browser oder Viewer voraus. Dies war (und ist!) ein nicht ganz unbeträchtliches Problem, denn viele der heute noch im Internet verwendeten Browser unterstützen maximal Java 1.0.2, können also mit auf dem 1.1-API (oder Folgeversionen) basierenden Funktionalitäten nichts anfangen. Die meisten Programme, die Java unterstützen, wurden erst Anfang 1998 auf die Unterstützung von Java 1.1.3 upgedatet. So kann der Netscape Communicator in den Versionen 4.03-4.05 nur mit Java-1.1-Funktionalität umgehen, wenn er mit dem JDK-1.1-Patch ausgestattet ist. Ab der Version 4.06 ist JDK-1.1-Unterstützung dann teilweise (!) integriert. Der Microsoft Internet Explorer kann ab der Version 4.01 mit Java-1.1-Funktionalität umgehen (mit den üblichen Einschränkungen durch die Auffassung von Microsoft, was Java genau sein soll). Java 2.0 und das JDK 1.2 bzw. 1.3 mit den zugehörigen Klassen erzeugen nun aber erneut das Problem. Zusammenfassend muss man festhalten: Es gibt eine Vielzahl von Problemen, wenn Sie Applets mit Funktionalitäten erstellen, die über die Version 1.0.2 hinausgehen.

Die ganze Problematik bedeutet dennoch nicht unbedingt, dass Sie für die Erstellung von Applets mit einem alten JDK arbeiten müssen. Sofern Applets mit einem beliebigen JDK erstellt und kompiliert wurden und nur auf Java-Standard-1.0.2 basierende Funktionalitäten nutzten, sollten sie auch in nur diesen Standard unterstützenden Browsern/Containern dargestellt werden können. Diese Abwärtskompatibilität wird allerdings von Sun nicht ausdrücklich garantiert.

Das Java-Plug-In

Die Java-2.0-Plattform beugt - im Gegensatz zu den Vorgängerversionen - Inkompatibilitäten mit Browsern vor und beinhaltet ein Java-Plug-In für Webbrowser (ehemals bekannt als Activator), das automatisch von der Installationsroutine des JDK bzw. der Laufzeitumgebung mit installiert wird. Mittels dieses Tools kann die Java-Laufzeitumgebung eines Browsers durch eine beliebige andere Java-Laufzeitumgebung ersetzt werden. Damit ist im Prinzip immer eine vollständig zu einer beliebigen JVM kompatible Laufzeitumgebung für Applets vorhanden. Das Java-Plug-In wurde erstmals mit dem JDK 1.2 bzw. der zugehörigen Laufzeitumgebung JRE 1.2 ausgeliefert und installierte unter Windows in das Startmenü eine Aufrufmöglichkeit.

Abbildung 1.1:  Das Java-Plug-In, das mit dem JDK 1.2 ausgeliefert wurde

Im JDK 1.3 hat sich die Situation insoweit verändert, als dass das Java-Plug-In unter Windows nun über die Systemsteuerung zur Verfügung steht.

Abbildung 1.2:  Das Java-Plug-In des JDK 1.3 lässt sich über die Systemsteuerung starten

Nachdem Sie das Java-Plug-In gestartet haben, können Sie das als Laufzeitmanager konzipierte Tool über verschiedene Registerblätter konfigurieren. Am wichtigsten ist wohl, dass man in dem Registerblatt Advanced bzw. Erweitert verschiedene Java-Laufzeitumgebungen (alle auf Ihren Rechner vorhandenen) einstellen kann, die als Java-Plug-In für Browser fungieren. Es ist also nicht nur möglich, zwischen verschiedenen bei Ihnen aktuell auf dem Rechner installierten Java-Laufzeitumgebungen zu wechseln. Sie können darüber hinaus jederzeit die neueste Java-Laufzeitumgebung auf Ihrem Rechner installieren und diese steht dann theoretisch denjenigen Browsern zur Verfügung, die eine externe Java-Laufzeitumgebung verwenden können.

Abbildung 1.3:  Einstellen der Laufzeitumgebung

Leider funktioniert das Plug-In nicht bei allen Browsern und sie können sich nicht unbedingt darauf verlassen, dass die Browser mit dem 1.3-API oder sogar schon viel früher eingeführten Techniken wie Java 2D oder Swing tatsächlich zurechtkommen. Insbesondere Sicherheitsrestriktionen der Browser hebeln neuere Techniken immer wieder aus (Firewalls, keine Installationen von Plug-Ins auf Clientrechnern erlaubt, allgemeine Sicherheitsbedenken usw.).

Die hauptsächlichen Probleme mit dem Java-Plug-In beruhen aber darauf, dass Sie bei Anwendern nicht voraussetzen können, dass das Plug-In und vor allem eine passende andere Java-Laufzeitumgebung auch wirklich installiert ist1. Ein Problem kann darin bestehen, dass die Verwendung des Java-Plug-Ins die Einbindung von Applets in Webseiten mittels des <OBJECT> oder <EMBED>-Tags voraussetzt. Meist wird jedoch das einfachere <APPLET>-Tag verwendet, und dann kann das Java-Plug-In nicht genutzt werden. Es gibt zwar von Sun einen vollständig in Java geschriebenen HTML-Konverter (zu laden von der Sun-Plug-In-Homepage http://java.sun.com/products/plugin), der aus einer Webseite mit dem <APPLET>-Tag eine solche mit <OBJECT>-Tag (für den Internet Explorer) bzw. <EMBED>-Tag (für den Netscape Navigator) macht. (Defaulteinstellung ist, dass beide Versionen in die Webseite eingefügt werden). Dies hilft jedoch keinem Anwender unmittelbar, wenn er eine Seite mit einer <APPLET>-Referenz aus dem Netz lädt.

Abbildung 1.4:  Die Plug-In-Downloadseite von Sun

Auf Seite 29 finden Sie den Einsatz des Java-Plug-Ins konkret besprochen.

Zusammenfassend kann man sagen, dass es theoretisch möglich ist, in einem moderneren Browser Applets zu verwenden, die die gleichen APIs nutzen wie eine eigenständige Java-Applikation. Das setzt aber beim Anwender erhebliche Faktoren voraus:

1. Es muss eine passende Java-Laufzeitumgebung vorhanden sein. Die Java-Umgebung, die vom Browser mitgeliefert wird, reicht in der Regel nicht aus. Entweder ist also die Laufzeitumgebung des Betriebssystems ausreichend oder der Anwender muss explizit eine Laufzeitumgebung nachinstalliert haben. Das kann man bei den meisten Anwendern definitiv nicht voraussetzen.
2. Das Java-Plug-In muss vorhanden sein oder zumindest bei Bedarf nachinstalliert werden können. Letzteres wird in professionell gemanagten Netzwerken mit Firewall und zentraler Verwaltung natürlich verhindert. Aber auch im Bereich der Standalone-Rechner verhindern viele fortgeschrittene Anwender diese Nachinstallation (Sicherheits- und Stabilitätsbedenken, unerwünschter Ressourcenverbrauch auf dem eigenen Rechner, hohe Downloadkosten usw.).
3. Der Ersteller einer Webseite muss das veraltete und - im Vergleich zum <APPLET>-Tag - recht komplizierte <EMBED>-Tag zum Einbinden von Applets verwenden, wenn er den Navigator unterstützen will. Der Internet Explorer verlangt gar das <OBJECT>-Tag, das die meisten Anwender wegen seiner ActiveX-Verbindung generell nicht akzeptieren. Sollen beide Browservarianten unterstützt werden, müssen (wie in unserem Beispiel gezeigt) beide Varianten in einer Webseite notiert und getrennt werden. Und damit hat man ältere Browser und einige Browser von anderen Herstellern explizit ausgeschlossen.

In einem Intranet können die genannten Faktoren leicht vorausgesetzt werden, weshalb dort Java-Applets voll ausgereizt werden können. Im Internet wird es noch einige Zeit dauern, bis die Voraussetzungen akzeptabel sind.

Was heißt deprecated?

Über die Entwicklung von Java wurden von Sun immer wieder Java-Elemente als »deprecated« bezeichnet, was übersetzt in etwa »missbilligt«, »veraltet« oder »verworfen« bedeutet2. Dies bedeutet aber nicht, dass Sie diese Elemente vergessen können oder nicht mehr verwenden dürfen. Diese Methoden lassen sich durchaus noch anwenden und sogar mit neueren Methoden - mit der nötigen Vorsicht - mischen. Und nicht nur das - es gibt Situationen, in denen zwingend als deprecated gekennzeichnete Techniken verwendet werden müssen! Insbesondere bei der Entwicklung von Java-Applets werden Sie normalerweise gezwungen sein, das als veraltet gekennzeichnete Eventmodell 1.0 zu verwenden. Wir werden im Abschnitt über die Ereignisbehandlung von Java sowie den Applets noch genauer darauf eingehen.

1.3.2 Interoperabilität

Es gibt mittlerweile zahlreiche Java-APIs, nicht nur von Sun, sondern von diversen Herstellern, die sich mit Java beschäftigen. Um das Zusammenspiel zwischen diesen verschiedenen APIs zu gewährleisten (die so genannte Interoperabilität), wurde das Java Collection Framework, eine formalisierte Schnittstelle zum Einbinden von neuen Java-Technologien, definiert. Dieses gehört in der Java-2-Plattform zu den Kerntechnologien.

1.3.3 Anpassung einer Applikation an verschiedene Länderstandards

Eine der wichtigsten Neuerungen im Sprung von den 1.0.x-Versionen aufwärts war die mögliche Anpassung einer Java-Applikation an verschiedene Länderstandards. Eine Applikation kann so beispielsweise landesspezifische Schreibweisen berücksichtigen, wie zum Beispiel die Zeit oder das Datum. Des Weiteren ist es nun erlaubt, Texte in Menüs und Dialogen in verschiedenen Sprachen auszugeben. Der 16 Bit große Unicode kann vollständig angezeigt werden, soweit dieser bisher mit Zeichen gefüllt ist (da ist noch viel Platz). Dieser Vorgang, der von Sun mit Internationalisierung beschrieben wird, betrifft im Wesentlichen das java.text-Package und das java.io-Package.

Das zugehörige, in der Version 1.1 neu hinzugekommene Programm native2ascii konvertiert native-verschlüsselte 8-Bit-Zeichen in Unicode.

1.3.4 Erweiterung der Sicherheitsschnittstelle von Java

Java ist eine der sichersten Programmiersprachen bzw. Plattformen der EDV-Welt. Aber natürlich nicht perfekt. In der Geschichte von Java wurden - wie bei jeder vergleichbaren Umgebung - immer wieder Sicherheitslücken aufgedeckt. Die immer wieder nachgeschobenen kleinen Releasewechsel beseitigten nach und nach bekannt gewordene Sicherheitslücken (so etwa 23 der 24 in der Version 1.1 im Frühsommer 97 durch Forscher der University of Washington im Rahmen des Kimera Project entdeckten Sicherheitsrisiken) und sonstige Bugs. Eine wichtige Erweiterung der ersten Java-Plattform betraf die Sicherheitsschnittstelle von Java. Diese verbindet ab der Version 1.1 so genannte Low-Level- und High-Level-Sicherheitsfunktionalität. So können ab diesem Release Applets und Daten mit einer digitalen Unterschrift versehen werden. Das Konzept wurde im Laufe der Updates noch erweitert um abstrakte Schnittstellen für die Verwaltung von Schlüsseln, das Zertifikats-Management und die Zugriffskontrolle. Spezifische APIs zur Unterstützung von X.509 v3-Zertifikaten und anderer Zertifikatformate sowie eine umfangreiche Funktionalität im Bereich der Zugriffskontrolle sind weitere Sicherheits-Highlights der neuen JDK-Versionen.

Seit der JDK 1.1-Version ist im JDK-Paket ein Tool enthalten, mit dem Sie so genannte Java-Archive (Erweiterung .jar) signieren können. JAR-Dateien sind neu in der Version 1.1 eingeführt worden und fassen einzelne Java-Dateien zu einem Paket zusammen - später mehr dazu. Der Appletviewer erlaubt jedem aus dem Netz geladenen Applet in Form einer JAR-Datei, die als vertrauenswürdig eingestuft und mit diesem Tool entsprechend signiert wurde, mit denselben Rechten auf dem lokalen Rechner zu laufen wie eine lokale Applikation. Dies hat extrem weitreichende Konsequenzen, denn ein solches Applet ist nicht mehr Bestandteil des »Laufstalls«, in den das Java-Sicherheitsmodell Applets normalerweise zwingt.

Das zugehörige Java-Sicherheitsprogramm der JDK-Version 1.1 heißt javakey. Dieses Tool ist als eine der bedeutendsten Neuerungen in der Version 1.2 durch die Programme keytool und jarsigner ersetzt worden. Im JDK 1.3 wurden die beiden Tools nochmals um eine neue Option erweitert (-provider). Daneben wurden bereits im JDK 1.2 die Sicherheitsprogramm jar und policytool hinzugefügt.

Das JDK 1.2 erweiterte den Umfang der Tools, die von dem Sicherheitsmodell von Java betroffen sind, in der Finalversion um ein weiteres Programm (oldjava). Dies ist zwar nur ein Interpreter, aber dessen Hauptfunktion ist es, Applikationen zu unterstützen, die über einen eigenen Security Manager verfügen, der auf dem originalen Sicherheitsmodell von Java 1.0/1.1 basiert. Dieser wird unter der Java-2-Plattform eine Exception auswerfen und nicht starten. Solche Applikationen können mit dem Programm oldjava als Interpreter jedoch weiterverwendet werden.

1.3.5 Verschlüsselung in Java

Die Sicherheitsschnittstelle von Java bietet seit der Version 1.1 eine Unterstützung für die so genannte Public-Key-Verschlüsselung. Bekanntestes Beispiel für eine Public-Key-Verschlüsselung ist wohl PGP (Pretty Good Privacy). Die Public-Key-Verschlüsselung ist eine relativ neue und extrem zuverlässige Verschlüsselungsvariante, die mit zwei Schlüsseln arbeitet: einem privaten Schlüssel, der nur beim Sender verbleibt, und einem öffentlichen Schlüssel, der verschickt wird. Diesen zweiten Schlüssel darf jeder kennen, denn er wird ausschließlich zum Kodieren einer Nachricht benutzt. Zum Dekodieren kann er nicht verwendet werden. Die Folge ist, dass bis jetzt nur der Empfänger des Schlüssels an den Sender des Schlüssels eine kodierte Botschaft senden kann, die ausschließlich dieser dann mit seinem privaten Schlüssel dekodieren kann. Will der potenzielle Sender eine kodierte Nachricht verschicken, muss er also erst von dem potenziellen Empfänger den öffentlichen Schlüssel erhalten.

Dieses Verfahren hat den riesigen Vorteil, dass der Dekodierungsschlüssel niemals verteilt werden muss und es äußerst sicher ist. Nachteil ist andererseits unleugbar, dass man einen großen Aufwand mit dem Verschicken und Verwalten der verschieden Kodierungs-Schlüssel betreiben muss.

Durch die Kombination der digitalen Unterschrift und der Public-Key-Verschlüsselung können selbst sensible Daten in einer Java-Applikation verarbeitet und im Internet bereitgestellt werden.

Zu der Funktionsweise von Verschlüsselungsverfahren im Allgemeinen finden Sie im Anhang einen Beitrag, der auf einige Grundlagen eingeht.

1.3.6 Das Abstract Window Toolkit

Als ein großer Nachteil von Java in der Version 1.0 wurde oft angeführt, dass Java durch seine Plattformunabhängigkeit für alle Architekturen und Betriebssysteme Vorsorge treffen muss und deshalb sehr oft nur den kleinsten gemeinsamen Nenner aller Fähigkeiten der einzelnen Plattformen nutzen kann. Java-Applets können immer nur die Möglichkeiten verwenden, die in ihrer internen Laufzeitbibliothek verankert sind (z.B. die Grafik-, Kommunikations-, Multithreading-Klassen bzw. die Klassen für die grafische Benutzeroberfläche). Da die Klassenbibliothek für den Entwurf einer grafischen Benutzeroberfläche - das AWT (Abstract Window Toolkit) - in der Version 1.0 relativ klein und allgemein gehalten wurde, konnten die Applets zu dieser Zeit nur eine Auswahl der unter Windows bekannten Elemente bieten. Hauptargument der Kritiker war, dass auf der WINTEL-Plattform (Windows und INTEL) basierende Computer die verbreitetsten Rechner im Internet sind (über 80 % der angeschlossenen Rechner) und Java für weniger als 20 % der Internetteilnehmer die vollständige Windowsfunktionalität aufgab.

Das AWT hat in der Version 1.1 sehr weitreichende Erweiterungen erfahren. Dazu zählen eine einheitliche Druckerschnittstelle, damit Applikationen darüber plattformunabhängig drucken können (selbst dies war in der Version 1.0 noch nicht gegeben), aber auch schnelleres und einfacheres Scrolling, bessere Grafikmöglichkeiten sowie flexiblere Font-Unterstützung. Eine Unterstützung von Pop-up-Menüs und der Zwischenablage waren weitere wichtige Erweiterungen.

Das 1.2/1.3-API hat gerade hier noch einmal zugelegt und viele weitere neue Funktionalitäten und Erweiterungen folgen lassen. Das neue Paket beinhaltet die erste vollständige Implementation der Java Foundation Classes (JFC), einem Satz von APIs und vorkompilierten Komponenten. Die JFC schließt nun Java 2D zur Erstellung von 2D-Grafiken, UI Components (Swing Package), Zugriffsmöglichkeiten auf diverse Hilfstechnologien (Accessibility), Drag&Drop und Application Services ein. Insbesondere das Swingkonzept erlaubt statt der davor recht rustikalen Oberfläche von Java-Anwendungen ein mehr dem durch Windows geprägten Massengeschmack angepasstes Aussehen.

Das in der Version 1.0 noch sehr starr ausgelegte Eventhandling (also die Reaktion auf Ereignisse) wurde bereits für die Java-Version 1.1 völlig überarbeitet und wurde damit wesentlich flexibler. Das 1.1-Eventmodell arbeitete als Neuerung mit so genannten Delegates, d.h. Objekten, die die »Delegierten« von anderen Objekten sind. Ein Fenster erhält zum Beispiel ein Delegate-Objekt, an das dann eine Menge von Methoden geschickt wird, die das Delegate dann abarbeiten kann. Je nach dem Rückgabewert der Methode in dem Delegate wird das Fensterobjekt dann unterschiedlich reagieren. Das Delegate-Konzept an sich ist nicht neu und bereits ziemlich ausgereift, denn es wird schon seit Jahren unter dem Betriebsystem Nextstep, aber auch unter Windows NT und in der Entwicklungsumgebung OpenStep verwendet.

Die Win-32-lmplementation des AWT wurde ebenfalls komplett überarbeitet, da die alte Version zu langsam war und viele Inkonsistenzen im Vergleich mit anderen Plattformen hatte. Damit war bereits das AWT 1.1 insgesamt erheblich schneller und stabiler geworden.

Zu der Erweiterung des AWTs zählt gleichfalls das so genannte Input Method Framework. Darunter versteht man die Eingabe und Verwendung von Text, der in beliebigen Sprachen (etwa Japanisch, Chinesisch oder Koreanisch) geschrieben sein kann. Das Besondere daran ist, dass diese Zeichen über Tastenkombinationen eingegeben werden können. Sie können Tausende von Zeichen aus den unterschiedlichsten Sprachen mit Tastenkombinationen erzeugen und Java kann damit umgehen (sowohl bei der Eingabe, aber auch im AWT allgemein oder anderen Ausgaben).

Die Technik ist wichtig, um Geräte zu unterstützen, denen einige Tasten fehlen (etwa Handheld-Computern). Damit wird ein wichtiger Schritt in Richtung Plattformunabhängigkeit gemacht.

1.3.7 Java-Archive

Netscape hatte bereits im Navigator der Version 3.0 das Packen mehrerer Java-Kompilate (also .class-Dateien) in eine Datei implementiert. Umgesetzt hat Sun diese Idee seit der Version 1.1 in den so genannten JAR-Dateien (Java-Archive sind Dateien mit der Erweiterung .jar). In diesen JAR-Archiven können neben .class-Dateien gleichermaßen Image- und Sound-Dateien verpackt werden. Statt vieler einzelner und unkomprimierter Dateien wird beim Laden aus dem Netz ein gepacktes Archiv übertragen. Der Vorteil dieses Konzepts liegt darin, dass die Applikation in einer einzigen HTTP-Transaktion übertragen wird und nicht in vielen einzelnen Übertragungsschritten. Natürlich kann durch die Komprimierung der Daten zusätzlich die Transferzeit erheblich gesenkt werden. Die JAR-Funktionalität wird in dem ab der Version 1.1.x neu hinzugekommenen Package java.util.jar realisiert. Das zugehörige Java Archive Tool heißt jar. Das Tool wurde für das JDK 1.3 nochmals erheblich überarbeitet und arbeitet gegenüber den Vorgängerversionen bedeutend schneller.

1.3.8 Datenbankunterstützung

In Version 1.0 war für Java-Applikationen noch keine Datenbankunterstützung implementiert, was sich ab der Version 1.1 änderte. Das JDK bot nun die Möglichkeit, auf SQL-Datenbanken zuzugreifen. Bemerkenswert an dem JDK 1.2 waren insbesondere die neuen Zugriffsmöglichkeiten auf SQL-Datenbanken (inklusive SQL-3-Datentypen). Dazu dient auf der Seite von Java 2.0 die JDBC-2.0-Schnittstelle (Java Database Connectivity). Diese wiederum greift über die standardisierte ODBC-Schnittstelle auf eine SQL-Datenbank zu. Die ODB>-Schnittstelle (Open Database Connectivity) stammt von Microsoft und basiert auf dem gleichen Konzept wie JDBC - dem X/Open SQL CLI (Call Level Interface). In dem Packag> java.sql steckt die wesentliche JDBC-Funktionalität von Java.

1.3.9 Verteilte Programmierung und Object Serialization

Im Bereich der verteilten Programmierung entwickelte sich Java über die verschiedenen Versionen erheblich. Das Remote Method Invocation Interface (RMI) bietet die Möglichkeit, beliebige Java-Klassen, die auf einer anderen virtuellen Maschine laufen, anzusprechen. Dabei ist es egal, ob die virtuelle Maschine lokal vorhanden ist oder irgendwo im Internet ausgeführt wird.

Die Erweiterung des RMI-Konzeptes 1.2 erlaubt es nun, Objekte anhand einer Referenz zu reaktivieren, wenn diese zuvor persistent (dauerhaft gespeichert) gemacht wurden (Remote Object Activation).

Zwei neue Programme, rmic - der Java RMI Stub Compiler, der übrigens im JDK 1.3 diverse neue Optionen hinzugefügt bekam - und rmiregistry (Java Remote Object Registry) dienen ab der Version 1.1.x zur programmiertechnischen Umsetzung des RMI-Konzeptes. Neu im JDK 1.2 ist das Tool rmid (Java RMI Activation System Daemon).

In diesem Zusammenhang wurde gleichfalls das Konzept der so genannten Object Serialization aufgenommen. Es ermöglicht das Abspeichern der Inhalte eines Objekts in einen Stream. Dieser kann z.B. eine beliebige Datei sein. Ein Objekt kann in einem Stream zwischengespeichert und zu einem späteren Zeitpunkt daraus wieder aufgebaut werden. Die Lebensdauer eines Objekts kann also über die eigentliche Laufzeit eines Programms hinaus verlängert werden. Hauptanwendung hierfür ist das Versenden von Objekten über das Netzwerk im Zusammenhang mit dem RMI-Konzept.

Das Package java.io ist von den entsprechenden Erweiterungen betroffen. Das JDK 1.3 erlaubt es mittlerweile, dass auch Strings, die länger als 64 KByte sind, serialisiert werden können. Das Object Serialization Tool für Java heißt serialver.

1.3.10 Java IDL

Als eine logische Fortsetzung dieser RMI-Entwicklung folgte die Java IDL (Interfaces Definition Language), die es Java ermöglicht, eine Verbindung zu anderen Verteilungsplattformen wie zum Beispiel CORBA aufzubauen, d.h. entfernte Schnittstellen über IDL zu definieren. IDL ist eine Definitionssprache, die die Kommunikation zwischen verschiedenen Programmiersprachen über Schnittstellen ermöglicht und in das CORBA-Konzept (Common Object Request Broker Architecture) integriert.

CORBA liegt derzeit in der Version 2.0 vor und ist ein plattformunabhängiger Standard, der die Kommunikation von Objekten im Netzwerk definiert. Java 2.0 bietet vollständigen CORBA-Support, indem der CORBA-Standard mithilfe des CORBA IDL Compilers integriert wird. Die Internetadresse und einige andere interessante Links zu CORBA folgen in der Tabelle:

URL Beschreibung
http://siesta.cs.wustl.edu/~schmidt/corba.html Detaillierte Informationen zu CORBA
http://siesta.cs.wustl.edu/~schmidt/corba-urls.html Eine CORBA-Link-Sammlung
http://www.sun.com/ Die Homepage von Sun lässt ebenfalls eine Suche nach dem Begriff CORBA zu.

Tabelle 1.1:   CORBA-Quellen

Seit der Finalversion des JDK 1.2 haben sich in der Java IDL zahlreiche Veränderungen ergeben, die im Wesentlichen auf Grund der 2.3 OMG-Spezifikation notwendig waren. Das neue API des JDK 1.3 berücksichtigt die Neuerungen mit neuen Paketen bzw. Erweiterungen der bestehenden OMG-Pakete.

1.3.11 JavaBeans

In den letztgenannten RMI-Kontext fallen ebenso die so genannten JavaBeans - Java-Komponenten innerhalb eines Objektmodells. JavaBeans ist ein portables, plattformunabhängiges, in Java geschriebenes Komponentenmodell, das von JavaSoft in Kooperation mit führenden Industrieunternehmen der Computerbranche (klangvolle Beispiele sind Apple, Borland, IBM, JustSystem, Microsoft, Netscape, Rogue Wave, SunSoft, Symantec und viele andere) entwickelt wurde. Erstmals wurde das Modell am 4. September 1996 im Internet als Konzept vorgestellt, die konkrete Realisierung dauerte natürlich länger. Die JavaBeans sind eine der wichtigsten Erweiterungen des Java-SDK 1.1 (SDK steht für Software Development Kit). In das JDK 1.2 gehörte die nächste Generation der JavaBeans (Codename Glasgow) als fester Bestandteil. Vergleichbar sind JavaBeans mit ActiveX-Controls oder OCX-Controls. Sie können wie diese visuell manipuliert werden und bieten im Allgemeinen über so genannte Bridges eine Schnittstelle zu Komponenten wie ActiveX-Controls oder OLE-Komponenten an. Im Gegensatz zu diesen Komponenten sind JavaBeans jedoch explizit plattformunabhängig und vor allen Dingen im Sicherheitskonzept von Java integriert.

Häufig wird gefragt, ob JavaBeans nicht dasselbe wie Applets sind. JavaSoft gibt als wesentlichen Unterschied die Möglichkeit der visuellen Erstellung und eine relativ eng ausgelegte Zielfunktionalität von Beans an. Allerdings stellt JavaSoft ebenso fest, dass Applets so entwickelt werden können, dass sie wie Beans aussehen und arbeiten. Um JavaBeans entwickeln und dann zu komplexen Anwendungen kombinieren zu können, musste ein eigenes Beans Developement Kit (BDK 1.0) von Sun dem JDK 1.1 (und folgende) beigefügt werden. Dieses gehört nicht zum JDK 1.2 und ist eine der Erweiterungen, die den Unterschied zwischen der vollständigen Plattform und dem JDK ausmachen. Mittlerweile sind alle wichtigen kommerziellen Java-Entwicklungstools in der Lage, JavaBeans zu erstellen. Einmal entwickelte Beans werden üblicherweise in die oben beschriebenen JAR-Dateien verpackt und beim Enduser in das Applet oder die Applikation integriert.

1.3.12 Servlets

Das Java Servlet API erlaubt die Erstellung von so genannten Java Servlets. Eingeführt wurde diese Technologie während der 1.1.x-Upgrades und richtig manifestiert in der Version 1.2. Allerdings zählt im Rahmen der Java-2-Plattform auch das Servlet-API (javax.servlet.*) nicht mehr zum JDK (wie noch bis zur JDK-1.2-Beta-3-Version), sondern gilt als eigenständiges Produkt - das Java Servlet Development Kit. Es ist wie das JDK frei von Sun zur Verfügung gestellt und kann von der Servlet Product Page unter http://java.sun.com/products/servlet/index.html heruntergeladen werden.

Servlets bedeuten eine Verlagerung von Funktionalität vom Client auf den Server. Die Assoziation zu CGI-Scripts ist naheliegend. Servlets verbrauchen jedoch viel weniger Ressourcen und sind - da sie in Java geschrieben sind - im Gegensatz zu CGI-Scripts plattformunabhängig.

1.3.13 Inner Classes und Anonymous Classes

Neu in 1.1 wurden die so genannten Inner Classes eingeführt. Klassen und Interfaces können damit innerhalb anderer Klassen eingebettet werden. Solche Klassen werden innere Klassen genannt. Sie können ausschließlich die Klassen unterstützen, in die sie integriert sind.

Damit unterstützt Java die bisher schon bei vielen Programmiersprachen praktizierte Blockstruktur innerhalb einer Klasse bzw. das dort verwendete Konstrukt.

Anonymous Classes steht für eine Abart der inneren Klassen. Es handelt sich um eine Kurzform von inneren Klassen. Sie haben allerdings keinen Namen, nur eine Implementation mit new. Der Compiler generiert bei den anonymen Klassen eine namenlose Klasse, die wie spezifiziert eine bestehende Klasse dann überschreibt. Das Ende einer anonymen Klasse wird durch das Ende des mit new eingeleiteten Ausdrucks festgelegt.

1.3.14 Native Methoden

Das API, um C-Implementationen für Java-Methoden zu schreiben, ist seit der Version 1.1.x komplett gegenüber der Version 1.0.x geändert worden. Das Mapping wurde einheitlich geregelt und es ist nur ein innerer Bestandteil der Java Virtual Machine. Das Java Native Interface (JNI) ist viel einfacher anzuwenden und zu lernen als das davor verwendete Konzept. Das JNI ist eine Standardprogrammierschnittstelle, um native Java-Methoden zu schreiben und die JVM in native Applikationen einzubetten. Das primäre Ziel ist die binäre Kompatibilität von nativen Methodenbiliotheken über alle JVM-Implementationen auf den unterstützten Plattformen. JDK 1.2 erweiterte gegenüber dem JDK 1.1 das Java Native Interface mit einige neuen Features, es bleibt jedoch weitgehend gleich. Wichtig ist, dass es nun getrennte Unterstützung von dem Impelemntation von Native-Code über das JNI und älteren Schnittstellen gibt. Der resultierende Code ist erheblich effizienter als zuvor.

1.3.15 Reference Objects

Neu im JDK 1.2 wurde das Reference-Objects-Konzept eingeführt. Darunter versteht man, dass die Referenz auf ein Objekt wie ein Objekt selbst behandelt wird und damit genauso manipuliert und untersucht werden kann (siehe auch RMI). Dies funktioniert sogar noch dann, wenn auf das Objekt selbst gar nicht mehr zugegriffen werden kann (etwa, weil der Garbage Collector das Objekt gelöscht hat). Eine potenzielle Anwendung für diese Referenzobjekte ist der Aufbau eines einfachen Caches.

1.3.16 Multimedia-Unterstützung in Java 2

Multimedia nimmt in der Java-2-Plattform großen Raum ein. Mit der neuen Java-Version wird beispielsweise die Audio-Unterstützung erweitert. Sowohl in Applikationen als auch in Applets lassen sich nun MIDI-Dateien (Typ 0 und Typ 1) sowie RMF-, WAVE-, AIFF-, und AU-Dateien in hoher Tonqualität abspielen und zusammenmischen. Das JDK 1.3 stellt insbesondere für die Arbeit mit MIDI-Dateien einige neue Pakete zur Verfügung.

Das vollständige Java Sound API bleibt bei dieser Erweiterung weitgehend erhalten, nur die Engine wurde ausgetauscht. Sie wird als eigene Sammlung ausgeliefert. Allgemein wird die Multimedia-Unterstützung von Java immer mehr in ein eigenes Framework verlagert. Zu der Java-2-Plattform zählt als eigenes Paket das Java Media Framework (JMF), das eine sehr komfortable Verbindung von verschiedenen Mediatypen mit Java-Applets und -Applikationen erlaubt (http://java.sun.com/products/java-media/jmf/). Das JMF-API unterstützt eine einfache und vereinheitlichte Synchronisation, Kontrolle, Verarbeitung und Präsentation von komprimierten, Zeit-basierenden Mediadaten. Dies beinhaltet sowohl Javastreams als auch MIDI, Audio und Video auf allen Java-Plattformen.

1.3.17 Die Java-2D-API-Referenz

Das im JDK 1.3 enthaltene 2D-API bietet umfangreiche Klassen für die Erstellung und Entwicklung von grafischen Applikationen und Applets. Der Anspruch dieses APIs geht erheblich über das hinaus, was davor in der Grund-Java-Grafik vorgesehen war. So stehen dort primitive Grafikformen (etwa die verschiedensten Geometrieformen) sowie transparente Images (Alpha Channel) direkt als vorgefertigte Methoden zur Verfügung. Die 2D-API lässt sich zudem zur elektronischen Bildbearbeitung oder für Präsentationen in Java verwenden.

Leider muss man festhalten, dass das Java-2D-API seit der Finalversion des JDK 1.2 vielfach inkompatibel zu den davor verbreiteten Java-2D-APIs ist (sogar späten JDK-1.2-Betaversionen). Es gibt diverse Methoden, Felder und ganze Klassen, die nicht nur verlagert, sondern teilweise vollständig abgelöst wurden. Und nicht etwa, indem sie als deprecated erklärt wurden wie bei sonstigen Bestandteilen des JDK-APIs. Es gibt sie teilweise einfach nicht mehr. Man findet keinen Hinweis darauf, dass sie in einer Vorgängerversion verwendet wurden und was jetzt als Ersatz für die Funktionalität zu verwenden ist. Wenn Sie beispielsweise die Klasse java.awt.font.StyledString - eine finale Subklasse von font in der Beta 3-Version des JDK 1.2 - suchen, werden sie in der gesamten Dokumentation des JDK 1.2 bzw. 1.3 keinen Hinweis mehr darauf finden.

Zwar werden das Konzept von Java 2D und die allgemeinen Veränderungen über die einzelnen Versionen davon in der offiziellen Dokumentation recht ausführlich behandelt. Dies hilft aber herzlich wenig, wenn Sie einen Java-Quelltext nach dem alten Konzept erstellt haben, ihn mit dem neuen Compiler übersetzen und nur die nichtssagende Fehlermeldung erhalten, ein bestimmtes Element sei nicht vorhanden. Es gibt keinen Hinweis auf eine Veränderung der API, und der Anwender steht da, als ob er einen Fehler gemacht hätte. Obwohl das neue Java-2D-Konzept mit einigen Detailmängeln der Vorgängerversionen aufgeräumt hat (insbesondere in der Darstellung des Hintergrundes bei Rotationen), werden viele Anwender ihren Wortschatz an Flüchen herauskramen, wenn bisher fehlerfreie Quelltexte scheinbar ohne Grund nicht mehr zu übersetzen sind.

1.3.18 Swing JDK 1.2/1.3 und die Java Accessibility API

Swing ist der Teil der Java Foundation Classes (JFC), der einen vollständigen Satz von GUI-Komponenten (Graphical User Interface = grafische Benutzerschnittstelle) implementiert. Das Look and Feel von Java-Benutzerschnittstellen passt sich immer mehr den Standards der GUI-Welt an. Das Swing-Konzept geht jedoch noch weiter. Swing ist vollständig in reinem Java entwickelt und dort ohne Widersprüche implementiert. Swing basiert auf dem JDK 1.1 Lightweight UI Framework und versetzt Sie in die Lage, einen Satz von GUI-Komponenten zu entwickeln, die sich automatisch zur Laufzeit dem passenden Look and Feel für jede Betriebssystemplattform (Windows, Solaris, Macintosh) anpassen - wenn Sie es wollen. Swing-Komponenten beinhalten alle bereits vorher existierenden AWT-Komponentensätze (Button, Scrollbar, Label usw.) sowie einen großen Satz von Higher-Level-Komponenten (Baumansicht, Listboxen usw.).

Mit dem Java Accessibility API (ab 1.2) können Entwickler Java-Applikationen generieren, die mit innovativen Hilfstechnologien (etwa Spracheingabesystemen oder Blindensprache-Terminals) interagieren können. Die daraus resultierenden Applikationen sind nicht auf bestimmte technische Plattformen beschränkt, sondern können auf jeder Maschine eingesetzt werden, die die virtuelle Javamaschine unterstützt. Die neue Java Accessibility API ist nun eines der Kernbestandteile der Java Foundation Classes.

Die Finalversion des JDK 1.2 hat bezüglich der Swing- und Accessibility-Packages eine erhebliche Veränderung gegenüber den Vorgängerversionen (auch den Betaversionen des JDK 1.2 bis Beta 3) erfahren. Die vorher in dem Namensraum com.sun.java.* (oder kurz java.*) untergebrachten Pakete wurden samt und sonders in den Namensraum javax.* verlagert. Außerdem wurde die Paketstruktur erheblich verändert. Die alte Swing-API-Referenz (vor dem JDK 1.2 Final) sah wie folgt aus:

java.awt.swing 
java.awt.swing.basic 
java.awt.swing.beaninfo 
java.awt.swing.border 
java.awt.swing.event 
java.awt.swing.jlf 
java.awt.swing.motif 
java.awt.swing.multi 
java.awt.swing.plaf 
java.awt.swing.table 
java.awt.swing.target 
java.awt.swing.text 
java.awt.swing.undo

Die ehemalige Accessibility-API.Referenz war Folgende:

java.awt.accessibility

Ab dem JDK 1.2 Final und im JDK 1.3 gilt (inklusive der anderen in dem Namensraum javax.* vorhandenen Pakete) folgende Struktur (auch die wurde gegenüber dem JDK 1.2 Beta erweitert):

javax.accessibility
javax.naming
javax.naming.directory
javax.naming.event
javax.naming.ldap
javax.naming.spi
javax.rmi
javax.rmi.CORBA
javax.sound.midi
javax.sound.midi.spi
javax.sound.sampled
javax.sound.sampled.spi
javax.swing
javax.swing.border
javax.swing.colorchooser
javax.swing.event
javax.swing.filechooser
javax.swing.plaf
javax.swing.plaf.basic
javax.swing.plaf.metal
javax.swing.plaf.multi
javax.swing.table
javax.swing.text
javax.swing.text.html
javax.swing.text.html.parser
javax.swing.text.rtf
javax.swing.tree
javax.swing.undo
javax.transaction

1.3.19 Drag&Drop

Java unterstützt den Datenaustausch zwischen Programmen per Drag&Drop (kurz DnD). Das Drag&Drop-API der Java-2-Plattform zählt ebenfalls zu der JFC und ermöglicht den Datentransfer zwischen Java und Native-Applikationen. Die Integration in das Swingkonzept wurde bereits in den ersten Betaversionen des 1.2-JDK vollzogen. Es gab dort jedoch durch einen Fehler in dem Swing-Eventhandling in den ersten 1.2-Betaversionen noch diverse Probleme, sodass erst ab dem 1.2-Final von einer echten Implementation gesprochen werden kann. Vollständig unterstützt werden Drag&Drop für Win32 und OSF/Motif (auf Solaris), d.h., der Datentransfer innerhalb einer JVM, zwischen verschiedenen JVMs und sogar zwischen einer JVM und einer nativen Plattform, die ihrerseits DnD-fähige Applikationen beinhaltet.

Vollständig implementiert, getestet und unterstützt sind u.a. DnD-Transfers von Text (ASCII, ISO8859-1, Unicode). Transfer von Text der Form X11 Window System mit COMPOUND_TEXT-Verschüsselung wird nicht unterstützt (nicht kompatibel zu Unicode). Daneben können auch Dateien und Klassen per DnD transferiert werden (bis auf wenige Situationen getestet und vollständig unterstützt). DnD von Datentypen (plattformspezifisch oder selbst definiert), Instanzen oder serialisierten Java-Objekten sind in der Java-2-Plattform ebenfalls möglich.

1.3.20 Die Java-Standardklassen und die Datei classes.zip

Zwischen der Version 1.1 des JDK bzw. den ersten drei Betaversionen des JDK 1.2 auf der einen Seite und der Finalversion 1.2ff auf der anderen Seite hat sich der Zugriff auf die Laufzeitumgebung von Java erheblich verändert. Insbesondere wird seit dem JDK-1.2-Final die Datei classes.zip nicht mehr benötigt (sie wird auch nicht mehr zur Verfügung gestellt - Ersatz ist im Wesentlichen die Datei rt.jar). Diese hatte in den ersten Versionen von Java die Standardklassen von Java enthalten und war dementsprechend zwingend notwendig. Jedoch hat sich die Laufzeitumgebung von JDK 1.2 vollständig geändert.

Seit dem JDK 1.2 verwendet das JDK für den Zugriff auf die Systemklassen nun einen Bootstrap Class Loader, der seinen eigenen Pfad für die Suche der Systemklassen verwendet. Die Folge ist, dass im neuen JDK auch nur noch selbst erstellte Klassen bei Bedarf in den CLASSPATH aufgenommen werden müssen, wobei diese Bemerkung noch ausführlicher diskutiert werden muss. Das soll aber erst bei der Besprechung der JDK-Tools erfolgen.

1.3.21 Veränderungen bei den Tools

Nicht nur neue Klassen und Methoden kamen von der Java-Einführung bis hin zu der aktuellen Java-Version hinzu. Einige der neuen Java-Fähigkeiten konnten damit praktisch nutzbar gemacht werden, indem die bereits vorhandenen JDK-Programme erweitert wurden. Aber viele der neuen Funktionalitäten machten gänzlich neue Java-Tools notwendig. Die Programme werden ausführlich im Rahmen des Abschnitts über die JDK-Tools beschrieben. Hier ist jedoch schon einmal vorab eine Liste der Programme, die ab der Version 1.1 hinzukamen:

  • Das Java Archive Tool (jar)
  • Das Digital Signing Tool (javakey) - nur in der Version 1.1 vorhanden
  • Der Native-To-ASCII Converter (native2ascii)
  • Der Java RMI Stub Converter (rmic)
  • Das Tool Java Remote Object Registry (rmiregistry)
  • Das Serialisierungstool Serial Version Command (serialver)
  • Das Konvertierungstool AWT 1.1 Conversion Tool (updateAWT)
  • Das Programm extcheck, ein Diagnose-Tool für Jar-File-Versionskonflikte
  • Mit oldjava bzw. oldjavaw stehen zwei Versionen eines Javainterpreters zur Verfügung, der zum Ausführen von älteren Java-Applikationen genutzt werden kann. Dies ist unter anderem dann vonnöten, wenn diese über einen eigenen Sicherheitsmanager verfügen, der auf dem alten Sicherheitsmodell von Java beruht.
  • Das Tool tnameserv erlaubt den Zugriff auf den benannten Service.

Selbstverständlich wurden auch die bestehenden Tools im Laufe der Releasewechsel immer wieder überarbeitet, sodass hier nur ein paar besonders wichtige Details genannt werden sollen.

  • Der Java-Compiler javac wurde für das JDK 1.3 komplett überarbeitet und bzgl. der Performance verbessert. Bereits seit dem JDK 1.2 gibt es die Option -target version. Über die Versionsangaben kann festgelegt werden, auf welcher virtuellen Maschinen eine Applikation laufen soll.
  • Der Java-Interpreter und einige weitere Tools verstehen im JDK so genannte Non-Standard-Options. Neben dem normalen Satz von Standardoptionen gibt es die Möglichkeit, einen Satz von weitergehenden Kommandozeilenoptionen zu verwenden. Diese Non-Standard-Options beginnen fast immer mit einem -X, etwa -Xdebug oder -Xverify. Wichtigster Unterschied zwischen den Standardoptionen und den Nicht-Standardoptionen ist, dass die Unterstützung für die Standardoptionen im JDK 1.2 und allen zukünftigen Versionen der JVM von Sun garantiert wird. Eine Unterstützung für die Nicht-Standardoptionen wird jedoch ausdrücklich für zukünftige Versionen der JVM nicht garantiert.
  • In Bezug auf die Sicherheit von Java haben sich über die verschiedenen Versionen des JDK häufig Veränderungen ergeben. Besonders wichtig war die Ersetzung des javakey-Tools durch keytool, jarsigner und policytool im JDK 1.2.

1.3.22 Neues Lizenzierungsmodell für Java 2.0

Mit der neuen Java-Plattform 2.0 und dem JDK 1.2 wurde auch ein neues Lizenzierungsmodell eingeführt, das die Java-Entwicklung weiter vorantreiben sollte. Dieses erleichterte insbesondere die Unterstützung von nichtkommerziellen Entwicklungen.

Die Idee beruhte darauf, dass der Sourcecode des Java Runtime Environment im Internet bereitgestellt wird und von Entwicklern kostenlos benutzt und für eigene Zwecke erweitert werden darf. Und dies ohne die bis dahin vorhandene Verpflichtung, die Neuerungen von Sun wieder kostenlos zur Verfügung zu stellen. Für nichtkommerzielle Anwendungen beinhaltete das Lizenzierungsmodell auch keinerlei weitere Lizenzgebühren, wohingegen bei kommerziellen Entwicklungen - aber erst beim konkreten Vertrieb dieser Produkte - weiterhin Lizenzgebühren an Sun fällig wurden. Sun machte diese neue Lizenzpolitik folgendermaßen schmackhaft: »Das neue Modell ist eine Investition in die Zukunft unserer Kunden. Unter diesem neuen Modell verdienen auch wir kein Geld, bis diese mit Java Geld verdienen.«

Sun behielt sich ansonsten eine Kompatibilitätskontrolle von Weiterentwicklungen ihrer Java-Umgebung vor. Beides - die offene Lizenzpolitik auf der einen Seite und die Kontrolle von Kompatiblitätsstandards auf der anderen Seite - sollte nach Aussage von Sun eine Balance zwischen einer offenen Weiterentwicklung von Java und einem harmonischen Plattformstandard gewährleisten.

Diese Lizenzpolitik erwies sich aber entgegen der Marketingaussagen von Sun nicht als Initialzündung für das JDK 1.2 und Java 2, sondern das Gegenteil war der Fall. Die Industrie konnte sich mit dem Lizenzierungsmodell überhaupt nicht anfreunden und dementsprechend wurde der Java-2-Standard nur sehr langsam umgesetzt. Da das JDK 1.2 in Bezug auf Performance nicht das hielt, was man sich davon versprochen hatte, dauerte es bis zur Einführung des JDK 1.3, bis die Euphorie der ersten Java-Versionen die Java-2-Plattform erreichte. Das JDK 1.3 hat aber dann auch bei der bis dahin skeptischen Industrie für Java den endgültigen Durchbruch geschafft.

1.4 Zusammenfassung

Zusammenfassend wollen wir festhalten, dass Java 2.0 sehr viele Neuerungen gebracht hat. Zum großen Teil sind sie nur für fortgeschrittene Programmierer interessant, die vor allem im professionellen Bereich Anwendungen erstellen. Dazu zählen RMI, Sicherheitsaspekte, Datenbankzugriffe oder Reflection. Andere Neuerungen sind jedoch auch schon für den Otto-Normal-Programmier und sogar den Einsteiger sehr interessant. Insbesondere sollte die HotSpot-Technologie des JDK 1.3 zur Beschleunigung von Java-Prozessen den letzten echten Mangel von Java beseitigt haben.

1

Dies betrifft z.B. Anwender mit einem Internet Explorer, die nicht zusätzlich eine JRE von Sun installiert haben (das ist meist der Fall).

2

Das gleiche Verfahren findet man auch bei HTML.


© Copyright Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH
Elektronische Fassung des Titels: Java 2 Kompendium, ISBN: 3-8272-6039-6 Kapitel: 1 What's new?