3 Das JDK

Wir wollen in diesem Kapitel zu den Entwicklungstools für Java kommen. Das Java Development Kit (JDK) ist die Sun-Entwicklungsumgebung zum Erstellen von Java-Applikationen, -Applets und -Komponenten. Es ist Kern sämtlicher Java-Entwicklungswerkzeuge (gleichfalls von Fremdherstellern).

Das Kapitel ist relativ knapp gehalten und spricht nur die wichtigsten Tools an. Im Anhang gehen wir intensiver auf das JDK und ergänzende Entwicklungstools ein.

Das JDK wird in der aktuellen Version 1.3 (die - um es nochmals zu betonen - das aktuelle Entwicklungspaket der Java-2-Plattform ist) von Sun für Windows 95/98/ME/NT (ab der Version 4.0)/2000 sowie deren Nachfolger und das Solaris-Betriebssystem bzw. das in der letzten Zeit immer populärer werdenden Linux frei zur Verfügung gestellt. Genauere Informationen finden Sie unter http://java.sun.com/products/jdk/faq.html. Beachten Sie, dass das JDK 1.3 an diversen Stellen als SDK 2 - Software Development Kit - bezeichnet wird, womit streng genommen aber eine Obermenge des JDK gemeint ist.

Für die Windows-Versionen 3.x und früher gibt es keine JDK-Variante, was jedoch schon deswegen klar ist, da dort lange Dateinamen nicht unterstützt werden. Schwierigkeiten beim Erzeugen einer Multithreading-Umgebung in einer Betriebssystemumgebung, die nicht einmal preemptives Multitasking unterstützt, und fehlende direkte TCP/IP-Unterstützung bei Windows 3.x sind weitere Gründe. Allerdings können Windows 3.1x-Anwender seit einiger Zeit zumindest Java-Applets laufen lassen, denn es gibt sowohl von Netscape als auch von Microsoft mittlerweile Java-taugliche Browser für Windows 3.1x.

Das JDK ist bezüglich der minimalen Plattformvoraussetzungen genügsam. Nicht nur Java selbst ist klein, auch das JDK ist relativ klein und kompakt. Die Java-Gesamtkonzeption legt auf solche Eigenschaften ja sehr großen Wert. Das Win32-Release läuft sogar schon auf einem einfachen PC mit einem Pentium-Prozessor der ersten Generation mit nur 32 Megabyte recht gut. Wenn es sein muss, sogar bei noch sparsamerer Ausstattung. Das jeweilige Betriebssystem oder eine auf dem JDK aufbauende Entwicklungsumgebung wird statt dessen die notwendigen Minimalanforderungen für die Hardware festlegen.

Das JDK besteht fast ausschließlich aus Befehlszeilen-orientierten Tools und erreicht damit natürlich nicht den Komfortstandard integrierter Entwicklungsumgebungen (IDE), die eine grafische Benutzerumgebung (GUI - Graphical User Interface) haben.

Aber Befehlszeilen-Orientierung ist nicht immer schlecht. Man sollte nur daran erinnern, wie viele PC-Profis sogar heute noch lieber mit DOS-Befehlen, als mit den langsamen Stützrädern der Windows-Programme arbeiten. Die JDK-Werkzeuge (den Compiler eingeschlossen) können über eine einfache Befehlszeileneingabe auf Prompt-Ebene aufgerufen werden. Der Java-Source selbst (eine Datei mit Erweiterung .java) kann mit jedem einfachen Texteditor erstellt und bearbeitet werden. Im Anhang werden wir dennoch als Alternativen zu diesem rustikalen - und aus didaktischen Gründen sehr sinnvollen - Arbeiten einige frei verfügbare IDEs vorstellen.

Um nun das JDK auf einem lokalen Rechner zu installieren und anzupassen, sollte man in mehreren chronologischen Schritten vorgehen. Am Anfang steht natürlich der Bezug eines möglichst aktuellen JDKs.

3.1 Bezug des JDK

Natürlichste Quelle für ein Java-Entwicklungstool ist wohl das Internet. Immerhin hat dieses erst den Erfolg von Java ermöglicht und wer mit Java programmieren will, hat auch meistens einen funktionierenden Internetzugang. Es gibt nun zahlreiche Quellen, von wo Sie das jeweils aktuelle JDK (aber auch ältere Versionen) beziehen können. Am einfachsten ist der Weg über eine der vielen Seiten des Sun-Imperiums. Der sinnvollste Einstieg erfolgt über den Java-Bereich von Sun (http://java.sun.com). Dort finden Sie alles rund um Java und natürlich auch die neue Java-2-Plattform samt dem zugehörigen JDK 1.3.

Abbildung 3.1: Alles rund um Java direkt von Sun

Wenn Sie diese Java-Seiten aufrufen, folgen Sie einfach den entsprechenden Links für die gewünschte Java/JDK/SDK-Version und Ihrem Betriebssystem. In der Regel müssen einige übliche Copyright- und die Readme-Dateien auf dem Weg dorthin gelesen und bestätigt werden. Sie können die konkreten Seiten für das JDK natürlich auch direkt anwählen. Das erfolgt meist über eine URL wie die folgende: http://java.sun.com/j2se/

Abbildung 3.2: Hier gibt es das JDK.

Sie können das JDK auch von Seiten laden, die nicht zum offiziellen Sun-Internetbereich zählen. Etwa von gespiegelten FTP-Servern diverser Organisationen. Gerade die gespiegelten FTP-Server halten aber nicht immer, was diverse Quellen - sogar die offiziellen Sun-Unterlagen - versprechen. Prinzipiell sollte man ob der permanenten Umstrukturierungen auf den Servern bei Fehlermeldungen auf dem Root-Verzeichnis der jeweiligen Organisation einsteigen und dann sein Glück versuchen.

An dieser Stelle stehen Ihnen dann u.a. eine Liste der unterstützten Plattformen und die dafür vorhandenen Versionen des JDK zur Verfügung. Sie werden mit detaillierten Anweisungen und Hyperlinks zum Download für Ihre Version und Plattform geführt.

Auf der CD finden Sie ein 1.3-JDK. Allerdings kann es sein, dass es seit der Bucherstellung neuere Versionen gibt.

Über die angegebenen URLs laden Sie in der Regel ein selbstextrahierendes Archiv auf den lokalen Rechner, sofern es sich um eine ältere Version des JDK handelt. Ab der Version 1.2 (bzw. sogar schon in 1.1.x-Zwischenversionen) steht - zumindest in der Windows-Version - ein Standard-Setup zur Verfügung.

Auf den Sun-Downloadseiten stehen verschiedene Möglichkeiten zum Download des doch ziemlich großen JDK-Paketes zur Verfügung. Es gibt sowohl einen FTP-Download als auch einen HTTP-Download. Wenn es Ihnen möglich ist, sollten Sie einen FTP-Download durchführen. Der ist in der Regel schneller als ein HTTP-Download. Zusätzlich müssen Sie das gesamte Paket nicht als eine Datei laden. Es gibt das JDK auch in kleinen Häppchen.

Die genauen Größenangaben für das JDK können je nach Release variieren, aber grob sollte die Installationsdatei des JDK 1.3 ca. 29,4 MByte groß sein und mit allem Drum und Dran nach der Installation auf der Festplatte ca. 50 MByte belegen.

Da die genauen Größenangaben sich permanent verändern, macht eine genauere Angabe keinen Sinn. In der Regel wird sowieso immer die neueste Variante des JDK geladen und deren Größenangaben können immer wieder variieren. Bei der Kapazität heutiger Datenspeichermedien spielt dies kaum noch eine Rolle, und das JDK ist auf jeden Fall kleiner als übliche Entwicklungsumgebungen.

Abbildung 3.3: Eine Installationsdatei des JDK

3.2 Installation des JDK

Die Installation des JDK ist in neueren Versionen kein Problem mehr. Die ersten Versionen waren da nicht so einfach zu handhaben. Es ist jedoch zu empfehlen, ein neues JDK nicht über ein altes Release zu installieren. Wenn Sie eine ältere Version ersetzen wollen, werden als Installationsorte sowieso defaultmäßig verschiedene Verzeichnisstrukturen vorgeschlagen. Wollen Sie jedoch die bereits vorhandene Verzeichnisstruktur bzw. die bisherigen Namen der Verzeichnisse verwenden (etwa, um diverse Pfade und Einstellungen nicht mehr ändern zu müssen), sollten Sie vor der Installation einer neuen JDK-Version eine gegebenenfalls vorhandene Altversion vollständig beseitigen, damit die beiden Varianten sich nicht in die Quere kommen.

Falls Sie vor einer Installation die alte Version beseitigen, sollten Sie natürlich gegebenenfalls vorhandenen eigenen Java-Source und sonstige selbst erstellten Dokumente in dem Verzeichnis in Sicherheit bringen, bevor Sie das alte Verzeichnis liquidieren.

Die genauen Schritte bei der Installation sind für die unterschiedlichen Betriebssysteme leicht verschieden, entsprechen aber den üblichen Schrittfolgen bei Installationen unter den jeweiligen Plattformen. Die genauen Installationshinweise für jedes Release werden auf Java-Webseiten unter der zu jedem Release gehörenden Verzeichnisstruktur zur Verfügung gestellt.

Wir werden als Beispiel die Installation unter dem Betriebssystem Windows durchsprechen. Ab der Version 1.1.x verwendet das JDK den Standardvorgang zum Installieren unter Windows, den InstallShield. Positiv zu erwähnen ist dabei, dass selbst ein Aufruf des Installationsprogrammes auf Befehlzeilenebene keine sonst übliche Fehlermeldung der Art »This program requires Windows« erzeugt, sondern direkt zum InstallShield übergeht.

Abbildung 3.4: Der Beginn des Installationsvorgangs ist Windows-Anwendern bekannt

Der InstallShield bietet alle bekannten Einstellmöglichkeiten in Bezug auf das Installations-Verzeichnis und zu installierende Komponenten. Außerdem wird das Ziellaufwerk überprüft.

Abbildung 3.5: Standardeinstellungsmöglichkeiten

Ziemlich störend ab der Version 1.2 sind die zahlreichen Stellen, wo Sie Lizenzbedingungen akzeptieren müssen. Wenn man die zusätzlichen Bestätigungen der Lizenzbedingungen vor dem Download dazu zählt könnte man auf die Idee kommen, Sun würde einen Augapfel opfern.

Das Defaultverzeichnis setzt sich aus der Laufwerksangabe JDK und der Versionsnummer, durch Punkte getrennt, zusammen, zum Beispiel C:\JDK1.1.1 oder C:\JDK1.3. Dies erleichtert eine parallele Führung von mehreren Versionen erheblich.

Der Setup-Wizard installiert neben dem JDK noch zusätzlich eine Java-Laufzeitumgebung in ein separates Verzeichnis. Dies ist etwas ärgerlich, weil Sie diese zweite Laufzeitumgebung nicht benötigen - das JDK enthält sowieso eine solche.

3.2.1 classes.zip, src.zip, src.jar, rt.jar & Co.

Zwischen dem JDK 1.1 und der Finalversion 1.2 (bzw. natürlich auch dem Wechsel von JDK 1.2 auf JDK 1.3, aber diese sind nicht ganz so massiv) haben sich zahlreiche Veränderungen ergeben, die die interne Arbeitsweise der JDK-Tools und die Voraussetzungen für deren Aufruf betreffen. Hier soll ein wichtiges Detail hervorgehoben werden - die Dateien Classes.zip und Src.zip sowie die Laufzeitumgebung von Java.

Bis zu der JDK-Version 1.1.7 (und sogar den meisten Betaversionen des JDK 1.2) erzeugte das Extrahieren des JDK-Archives beim Installieren normalerweise (u.a.) zwei interessante Dateien bzw. Verzeichnisse:

Src.zip im Java-Verzeichnis selbst bzw. das Verzeichnis src und
Classes.zip in dessen Unterverzeichnis lib.

Beide ZIP-Dateien sollten normalerweise nicht (!) extrahiert werden. Classes.zip war wesentlicher Teil des RUNTIME-Moduls (die Systemklassen) von Java in den damaligen Versionen. Die Datei enthält den vollständigen, kompilierten Code von Java und muss in diesen Versionen des JDK einigen JDK-Tools (insbesondere dem Compiler und dem Interpreter) zur Laufzeit zur Verfügung stehen. Ein Entpacken der Datei ist so gut wie nie notwendig, denn Java kann ZIP-Dateien in komprimierter Form verwenden. Falls Sie die Datei dennoch entpacken, erreichen Sie nur eine geringfügige Steigerung der Performance und verlieren viel Platz auf der Festplatte.

Die Datei Src.zip beinhaltete in den älteren Versionen den eigentlichen Quellcode von Java. Normalerweise werden Sie diesen Quelltext nicht benötigen. Mit einer Ausnahme - diese Source-Files enthalten zum einen wichtige Informationen über Java, zum anderen können sie das Lernen von Java unterstützen, indem man den Source analysiert. Die Klassen sind in der API-Reference-Dokumentation beschrieben, die mit dem Tool javadoc erstellt wurde.

Aber um es nochmals zu betonen - ab der Finalversion des JDK 1.2 werden Sie die Dateien Src.zip und Classes.zip nicht mehr finden.

Die Datei Src.zip bzw. das Verzeichnis SRC ist durch die Datei Src.jar ersetzt worden. Diese ist in ihrer Funktionalität identisch. Sie können deren Installation im Setup-Programm mit angeben. Ein .jar-File ist ein Komprimierungsformat, mit dem Java direkt arbeiten kann. Es muss genauso wenig extrahiert werden, wie die bisherige ZIP-Dateien.

Die Laufzeitumgebung des JDK-1.2-Finalrelease hat sich ebenso vollständig gegenüber den Vorgängern geändert. Die Datei Classes.zip ist im Wesentlichen durch die Datei rt.jar (rt steht für RunTime) ersetzt worden. Darauf kommen wir aber gleich wieder zu sprechen.

3.2.2 Verzeichnisstruktur innerhalb des JDK-Verzeichnisses

Innerhalb des Installationsverzeichnisses des JDK wird von dem Setup-Programm eine Unterstruktur angelegt. Diese hat sich über die verschiedenen JDK-Versionen öfters verändert. Außerdem ist die genaue Verzeichnisstruktur davon abhängig, welche Optionen Sie bei der Installation angegeben haben. Sie werden bei einer vollständigen Installation des JDK 1.3 normalerweise die folgende Struktur finden:

Verzeichnis Inhalt

\bin In diesem Verzeichnis befinden sich (wie bei vielen Entwicklungsumgebungen anderer Sprachen) die JDK-Programme, also z.B. der Compiler, der Interpreter, ein Appletviewer, der Debugger, der Disassembler oder das Dokumentationstool. Dieses Verzeichnis ist immer vorhanden - es ist das JDK.

\lib In diesem Verzeichnis befinden sich defaultmäßig Standard-Java-Klassen des JDK. Im Wesentlichen ist das in den alten Versionen des JDK die Datei Classes.zip, ab dem JDK 1.2 (Final) sind es die Dateien Tools.jar, Jvm.lib und Dt.jar. Dazu kommem im JDK 1.3 die Dateien ir.idl, jawt.lib und orb.idl.

Tools.jar beinhaltet die Non-Core-Klassen zur Unterstützung der Tools und Utilities im JDK. Dt.jar (DesignTime-Archive) ist dafür da, über BeanInfo-Dateien interaktiven Entwicklungsumgebungen (IDE's) Informationen zur Verfügung zu stellen, wie sie die Java-Komponenten darstellen sollen und wie sie Entwickler dort für ihre Applikationen anpassen können.

Die Datei Jvm.lib ist eine Bibliothek für die virtuelle Maschine von Java. Auf diese Thematik werden wir gleich noch etwas näher eingehen.

Die beiden Dateien ir.idl und orb.idl dienen der Zusammenarbeit von Java mit der IDL-Sprache, jawt.lib mit dem AWT Native Interface.

Beachten Sie, dass zwar in den JDK-Versionen vor 1.2 in diesem Verzeichnis die Datei classes.zip zu finden war, aber in neuerern JDK-Versionen nicht deren wesentlicher Ersatz rt.jar. Diese befindet sich an anderer Stelle innerhalb der Verzeichnisstruktur (im Unterverzeichnis \jre).

\include Der C/C++-Programmierern sicher bekannte Ausdruck »include« steht für ein optionales Verzeichnis, das diverse Header-Dateien für die gemeinsame Verwendung von Java und C/C++ enthält. Außerdem gibt es dort ein Unterverzeichnis \win32, das weitere Header-Dateien beinhaltet. Die C-Headerfiles in diesem Verzeichnis sind ausschließlich für die Unterstützung von Nativecode-Programmierung über das Java Native Interface und das Java Virtual Machine Debugger Interface gedacht.

\include-old Ab dem JDK 1.2 (Final) gibt es optional dieses Verzeichnis, in dem aus Gründen der Abwärtskompatibilität Header-Dateien zur Unterstützung von Nativecode-Programmierung über ältere Schnittstellen zur Verfügung stehen. Diese Dateien gelten als deprecated (veraltet), werden nicht weiter unterstützt und stehen nicht auf allen Plattformen zur Verfügung.

\demo Das optionale Demoverzeichnis beinhaltet Beispielprogramme. Es hat einige Unterverzeichnisse (u.a. applets und jfc).

\src In der JDK-Version 1.1.x und den meisten Betaversionen des JDK 1.2 können Sie das Verzeichnis SRC mit installieren. Darin befinden sich dann die entkomprimierten Java-Dateien, die in diesen JDK-Versionen sonst nur im gepackten Zustand in der Datei Src.zip vorhanden sind. Das Verzeichnis ist durch die Datei Src.jar ab dem JDK 1.2 ersetzt worden, die seitdem im Hauptverzeichnis befindet.

\jre Das Verzeichnis beinhaltet die Laufzeitumgebung von Java. Es beinhaltet die zwei Unterverzeichnisse bin und lib. Im Wesentlichen finden Sie die Datei rt.jar in lib und in bin diejenigen Programme, die zum Ausführen von Java-Applikationen notwendig sind (ohne Entwicklungstools).

Verzeichnis	Inhalt
\bin	In diesem Verzeichnis befinden sich (wie bei vielen Entwicklungsumgebungen anderer Sprachen) die JDK-Programme, also z.B. der Compiler, der Interpreter, ein Appletviewer, der Debugger, der Disassembler oder das Dokumentationstool. Dieses Verzeichnis ist immer vorhanden - es ist das JDK.
\lib	In diesem Verzeichnis befinden sich defaultmäßig Standard-Java-Klassen des JDK. Im Wesentlichen ist das in den alten Versionen des JDK die Datei Classes.zip, ab dem JDK 1.2 (Final) sind es die Dateien Tools.jar, Jvm.lib und Dt.jar. Dazu kommem im JDK 1.3 die Dateien ir.idl, jawt.lib und orb.idl.
	Tools.jar beinhaltet die Non-Core-Klassen zur Unterstützung der Tools und Utilities im JDK. Dt.jar (DesignTime-Archive) ist dafür da, über BeanInfo-Dateien interaktiven Entwicklungsumgebungen (IDE's) Informationen zur Verfügung zu stellen, wie sie die Java-Komponenten darstellen sollen und wie sie Entwickler dort für ihre Applikationen anpassen können.
	Die Datei Jvm.lib ist eine Bibliothek für die virtuelle Maschine von Java. Auf diese Thematik werden wir gleich noch etwas näher eingehen.
	Die beiden Dateien ir.idl und orb.idl dienen der Zusammenarbeit von Java mit der IDL-Sprache, jawt.lib mit dem AWT Native Interface.
	Beachten Sie, dass zwar in den JDK-Versionen vor 1.2 in diesem Verzeichnis die Datei classes.zip zu finden war, aber in neuerern JDK-Versionen nicht deren wesentlicher Ersatz rt.jar. Diese befindet sich an anderer Stelle innerhalb der Verzeichnisstruktur (im Unterverzeichnis \jre).
\include	Der C/C++-Programmierern sicher bekannte Ausdruck »include« steht für ein optionales Verzeichnis, das diverse Header-Dateien für die gemeinsame Verwendung von Java und C/C++ enthält. Außerdem gibt es dort ein Unterverzeichnis \win32, das weitere Header-Dateien beinhaltet. Die C-Headerfiles in diesem Verzeichnis sind ausschließlich für die Unterstützung von Nativecode-Programmierung über das Java Native Interface und das Java Virtual Machine Debugger Interface gedacht.
\include-old	Ab dem JDK 1.2 (Final) gibt es optional dieses Verzeichnis, in dem aus Gründen der Abwärtskompatibilität Header-Dateien zur Unterstützung von Nativecode-Programmierung über ältere Schnittstellen zur Verfügung stehen. Diese Dateien gelten als deprecated (veraltet), werden nicht weiter unterstützt und stehen nicht auf allen Plattformen zur Verfügung.
\demo	Das optionale Demoverzeichnis beinhaltet Beispielprogramme. Es hat einige Unterverzeichnisse (u.a. applets und jfc).
\src	In der JDK-Version 1.1.x und den meisten Betaversionen des JDK 1.2 können Sie das Verzeichnis SRC mit installieren. Darin befinden sich dann die entkomprimierten Java-Dateien, die in diesen JDK-Versionen sonst nur im gepackten Zustand in der Datei Src.zip vorhanden sind. Das Verzeichnis ist durch die Datei Src.jar ab dem JDK 1.2 ersetzt worden, die seitdem im Hauptverzeichnis befindet.
\jre	Das Verzeichnis beinhaltet die Laufzeitumgebung von Java. Es beinhaltet die zwei Unterverzeichnisse bin und lib. Im Wesentlichen finden Sie die Datei rt.jar in lib und in bin diejenigen Programme, die zum Ausführen von Java-Applikationen notwendig sind (ohne Entwicklungstools).

Tabelle 3.1: Die Verzeichnisstruktur des JDK

Nach erfolgreicher Installation können Sie normalerweise das Setup-File des SDK von der Festplatte wieder löschen. Es wird nicht mehr benötigt und belegt nur Platz. Überdies ist es im Gegensatz zu gekaufter Software jederzeit erneut zu beziehen. Jedoch sollten Sie sich darüber im Klaren sein, dass Ihnen dann im Falle einer Neuinstallation erneut ein längerer Download bevorsteht.

3.2.3 Die Java-Laufzeitumgebung jre

Hinter dem Begriff Java Runtime Environment (JRE) verbirgt sich die Java-Laufzeitumgebung, der Minimalstandard, um Java-Programme laufen lassen zu können. Das Java Runtime Environment besteht aus der Java Virtual Machine, Java Core Classes und aufseiten der Tools hauptsächlich aus dem Java-Interpreter, ein paar ergänzenden Programmen sowie einigen dazu gehörenden DLLs. Insbesondere sind keinerlei Entwicklungstools enthalten und kein Tool zum Starten und Ansehen von Applets.

Laden können Sie das Java Runtime Environment separat von denselben Quellen, wo auch das JDK zu finden ist. Sie können (und müssen!!) es aber auch in der Setuproutine des JDK mit installieren. Das JRE wird dann wie oben beschrieben im Unterverzeichnis \jre installiert.

Sie werden auf Ihrem Rechner diverse Java-Laufzeitumgebungen finden. Das ist einmal diejenige, die vom JDK in dessen Installationsverzeichnis angelegt wird, aber auch an unterschiedlichsten anderen Stellen werden Sie - teils differierende Versionen - finden. Die verschiedensten Programme installieren eine solche Umgebung - in den unterschiedlichsten Versionen.

3.2.4 Das Java-Plug-In

Wir wollen hier den Einsatz des Java-Plug-In (siehe dazu auch Seite 29) durchspielen. Dies wird Ihnen dann die Möglichkeit eröffnen, ihre mit erweiterten Java-Technologien erstellten Java-Applets nicht nur im Appletviewer des JDK zu testen, sondern auch in einem (moderneren) Browser zu testen.

Zuerst laden Sie das Tool, das als ZIP-Datei bereitgestellt wird, von den Sun-Seiten.

Abbildung 3.6: Die Downloadseite des HTML-Converters

Es gibt dort verschiedene Möglichkeiten, von wo und wie Sie das Tool laden können. Am besten ist natürlich ein direkter FTP-Download.

Abbildung 3.7: Die Downloadseite des HTML-Converters 1.3

Danach entpacken Sie einfach die ZIP-Datei in leeres Verzeichnis auf Ihrem Rechner. Sie erhalten dort zwei Verzeichnisse. Im Verzeichnis classes befinden sich dann die eigentliche Java-Programmdatei HTMLConverter.class, die Sie mit dem Java-Interpreter direkt starten können (java HTMLConverter) sowie eine Batchdatei mit Namen HTMLConverter.bat, die diesen Vorgang ein wenig vereinfacht.

Abbildung 3.8: Das Unterverzeichnis classes

Wenn Sie das Tool gestartet haben, können Sie HTML-Dateien konvertieren und dabei diverse Konfigurationen vornehmen.

Abbildung 3.9: Konvertierung von einer HTML-Seite mit dem <APPLET>-Tag

Spielen wir die Situation mit einem vollständigen Applet durch. Der nachfolgende HTML-Code bindet ein Swing-Applet mittels des <APPLET>-Tags in eine Webseite ein.

<HTML>
<HEAD>
<TITLE>DemoApplet - Einbindung mit Applet-Tag
</TITLE>
</HEAD>
<BODY>
<APPLET CODEBASE = "." 
  CODE     = "DemoApplet.class"
  NAME     = "TestApplet"
  WIDTH    = 400  HEIGHT   = 300
  HSPACE   = 0  VSPACE   = 0  ALIGN    = middle>
</APPLET>
</BODY>
</HTML>

Im Appletviewer des JDK wird das Applet auch einwandfrei funktionieren.

Abbildung 3.10: Klick auf die eine Schaltfläche im Demo-Applet

Abbildung 3.11: Klick auf die andere Schaltfläche im Demo-Applet

Schauen wir uns die Webseite nun in halbwegs modernen Browsern an. Der Netscape Navigator 4.7 meldet einen Fehler in der Statuszeile und zeigt nichts an.

Abbildung 3.12: Netscape meldet Probleme im Demo-Applet.

Der Internet Explorer 5 meldet ebenso, dass er eine Klasse nicht finden kann und zeigt auch nichts an.

Abbildung 3.13: Der Explorer übt sich in Ignoranz.

Wenden wir das Tool nun auf die HTML-Datei an. Das kommt dabei heraus:

<HTML>
<HEAD>
<TITLE>DemoApplet - Einbindung mit Applet-Tag
</TITLE>
</HEAD>
<BODY>
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.3 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 400 HEIGHT = 300 NAME = "TestApplet" ALIGN = middle VSPACE = 0 HSPACE = 0  
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "DemoApplet.class" >
<PARAM NAME = CODEBASE VALUE = "." >
<PARAM NAME = NAME VALUE = "TestApplet" >
<PARAM NAME="type" 
  VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3"  CODE = "DemoApplet.class" CODEBASE = "." 
NAME = "TestApplet" WIDTH = 400 HEIGHT = 300 ALIGN = middle VSPACE = 0 HSPACE = 0  
scriptable=false pluginspage="http://java.sun.com/products/plugin/1.3/plugin-
install.html"><NOEMBED></COMMENT>
</NOEMBED></EMBED>
</OBJECT>
<!--
<APPLET CODE = "DemoApplet.class" CODEBASE = "." WIDTH = 400 HEIGHT = 300 NAME = "TestApplet" 
ALIGN = middle VSPACE = 0 HSPACE = 0>
</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->
</BODY>
</HTML>

Mit dieser Webseite läuft dann das Applet in den besagten Browsern einwandfrei. Der Appletviewer wird das Applet jedoch zweimal öffnen.

Bei der Auswahl der zu konvertierenden Dateien ist zu beachten, dass beim Durchsuchen der Festplatte das Verzeichnis mit den zu konvertierenden Dateien nicht per Mausklick geöffnet werden darf. Das ist etwas ungewöhnlich.

Ausführlichere Details und laufend aktuelle Informationen zu den gesamten Prozessen finden Sie auf der Sun-Webseite http://java.sun.com/products/jdk. Wir werden im Laufe des Buchs noch darauf zurückkommen.

3.3 Die JDK-Dokumentation

Für das JDK und die Java-Plattform wird von Sun eine umfangreiche (wenngleich oft recht verzweigte und daher unübersichtliche) Dokumentation zur Verfügung gestellt. Die Java-Dokumentation beinhaltet eine vollständige Beschreibung aller Pakete, Klassen, Methoden usw. sowie der JDK-Tools. Das JDK-Installationsfile alleine enthält diese Dokumentation jedoch nicht. Sie müssen sie (und sollten sie auf jeden Fall) separat von den Sun-Servern laden (ca. 21,2 MByte für die Zip-Datei unter Windows). Dazu gibt es auf den Downloadseiten des JDK Hyperlinks, die zu der Downloadseite für die Dokumentationen der einzelnen JDKs führen. Sie finden dort diverse Formate der Dokumentation für die unterschiedlichen Plattformen. Über die Auswahl der jeweiligen Version und der Zielplattform landen Sie auf der konkreten Downloadseite.

Abbildung 3.14: Die Online-Dokumentation zu Java und dem JDK

Zum Entpacken benötigen Sie ca. 110 MByte freien Platz auf dem Ziellaufwerk. Kaum zu glauben, wie groß eine Dokumentation werden kann. Aber die Dokumentation ist für eine effektive Arbeit mit Java unumgänglich! Und wenn man sich daran gewöhnt hat, ein vorzügliches Hilfsmittel. Sie sehen - es gibt mittlerweile ziemlich viel zu Java und dem JDK zu sagen und kein Buch zu Java kann das noch leisten, denn Java und die Dokumentation werden in Details permanent aktualisiert. Zudem ist es fraglich, ob die gleichen Informationen wie in der Online-Dokumentation in einem Buch aufbereitet werden sollten. Die Verknüpfung per Hyperlinks macht die Verwendung der Online-Dokumentation zum Nachschlagen von Details ideal. Bücher zu Java bieten nur dann einen Mehrwert, wenn sie mit übergeordneten Konzepten und Beispielen arbeiten und für die vollständigen Details auf die Online-Dokumentation verweisen. Wir wollen es so halten.

3.4 Fehlervorbeugung und Fehlerbehebung beim JDK

Die Installationsroutine des JDK legt wie gesagt eine Verzeichnisstruktur an, die Sie unter günstigen Umständen in die Lage versetzt, direkt die Installation zu testen und loszulegen. Die Tools des JDK lassen sich einfach auf Befehlszeilenebene aufrufen - etwa indem Sie unter Windows eine DOS-Box öffnen und dort die Programme aufrufen. Davor ist es jedoch sinnvoll, eine Anpassung der Java-Umgebung vorzunehmen. Unterlassen Sie dies, werden Sie unter Umständen immer wieder durch überflüssige Fehlersituationen genervt. Dabei kann eine Reihe von einfachen, vorab ausgeführten Schritten diese potenziellen Fehlerquellen erst gar nicht entstehen lassen.

Einfach installieren und loslegen ist also bei der Arbeit mit dem JDK und Java nicht immer zu empfehlen. Vorher sollten einige Einstellungen überprüft und ggf. gesetzt sowie andere potenzielle Fehlerquellen vorab analysiert werden. Sie sparen sich später viel Zeit und Ärger.

Zwischen den Tools des JDK 1.1.x (bzw. den Betaversion des JDK 1.2) auf der einen und den Tools der Nachfolgeversionen auf der anderen Seite haben sich einige schwerwiegende Veränderungen bezüglich ihres Aufrufs und den Voraussetzungen für eine korrekte Verwendung ergeben. Es gilt zwar prinzipiell, dass die Aufrufparameter bei Tools weitgehend unverändert blieben, wenn sie noch die gleiche Funktion wie bei dem zugehörigen Tool der Vorgängerversion haben. Außerdem sollten neue JDKs soweit wie möglich abwärtskompatibel sein. Einige wichtige Details sind jedoch verändert.

3.4.1 Pfad-Angaben

Da Sie in der Regel die JDK-Programme auf Befehlszeilenebene ausführen werden, ist es im Allgemeinen sinnvoll, die in der JDK-Umgebung verfügbaren Werkzeuge von allen Verzeichnissen auf Ihrem System aus zugänglich zu machen. Dies realisiert ein Eintrag in den Suchpfad des Computersystems. Für Windows-Anwender wird dies am sinnvollsten erreicht, indem man das Verzeichnis, das die Werkzeuge enthält, in die Pfadangaben (Set path) einträgt. Die Pfadangabe sollte ungefähr so aussehen:

SET PATH= C:\;D:\;C:\JDK1.3\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND

In unserem Beispiel ist C:\JDK1.3\BIN das Verzeichnis der JDK-Umgebung. In einer DOS/Windows-Umgebung werden Verzeichnisse mit Backslash getrennt, die einzelnen Einträge im Pfad mit Semikolon.

Sie können den Pfad auf Kommandozeilenebene jederzeit überprüfen, indem Sie path ohne weitere Parameter eingeben.

Sie können auch unter Windows einfach den aktuellen Pfad mit der folgenden Anweisung erweitern:

path=%path%;C:\JDK1.3\BIN

Wenn Sie diese Anweisung mit einem entsprechend konfigurierten DOS-Fenster für Java koppeln (eine Batch-Datei oder etwas Ähnliches), sparen Sie sich die jeweils notwendige Eingabe bei einem neuen Öffnen der DOS-Box.

Auch unter Solaris können Sie die Pfadangabe setzen. Unix verwendet den normalen Slash zum Trennen der Verzeichnisebenen. Wenn Sie z.B. eine C-Shell (csh) verwenden, können Sie die Pfadangabe in der Startup-Datei (~/.cshrc) wie folgt setzen (Beispiel mit dem Verzeichnis jdk1.3):

set path=($path /usr/local/jdk1.3/bin)

Anschließend laden Sie die Startup-Datei erneut (bzw. neu einloggen) und überprüfen, ob der Pfad richtig gesetzt ist.

Wenn Sie später versuchen, innerhalb eines bestimmten Unterverzeichnisses zu kompilieren und die Fehlermeldung »Bad command or filename« (»Ungültiger Befehl oder Dateiname«) unter Windows bzw. »File not found« unter Unix bekommen, liegt das wahrscheinlich daran, dass diese Pfadangabe nicht korrekt ist.

Es gibt diverse Gründe, warum man verschiedene Versionen des JDK gleichzeitig auf dem Rechner verwenden möchte. In diesem Fall sollten Sie jedoch unbedingt mit verschiedenen Umgebungen (z.B. DOS-Fenster unter Windows oder Shell-Fenster unter Solaris) arbeiten, die mit unterschiedlichen Pfadangaben konfiguriert sind. Es langt definitiv nicht, sämtliche parallel vorhandenen JDK-Verzeichnisse für die unterschiedlichen JDK-Versionen in den Suchpfad aufzunehmen. Der Kommando-Interpreter wird immer zuerst im aktuellen Verzeichnis und dann entsprechend der Reihenfolge der eingetragenen Verzeichnisse nach einem Programm suchen. Er wird immer die erste gefundene Version eines Tools verwenden. Es wird also immer nur die Tool-Version ausgeführt, die im aktuellen Verzeichnis vorhanden ist oder die zuerst in der Pfadangabe aufgelistet wird.

3.4.2 CLASSPATH

Die besprochenen Schwierigkeiten mit der CLASSPATH-Umgebungsvariable bei verschiedenen JDK-Versionen sind ein noch entscheidenderes Argument für die Verwendung mehrerer Umgebungen.

Bei der Angabe CLASSPATH handelt es sich um eine Pfadangabe, über die Java (genau genommen bestimmte Tools von Java, aber wir wollen der Einfachkeit halber von Java reden) Klassen sucht, die es zur Laufzeit benötigt. Dabei muss ganz massiv zwischen dem JDK ab der Version 1.2 (Final) und seinen Vorgängerversionen (inklusive der meisten Betaversionen des JDK 1.2) unterschieden werden. Mit der Finalversion des JDK 1.2 wurde ein neues Suchpfad-Konzept für Klassen eingeführt. Aber der Reihe nach - schauen wir uns an, wie es davor war:

Es gibt den Suchpfad für Java-Klassen in Rahmen des Java-Konzeptes in zwei Varianten. Bei CLASSPATH handelt es sich einmal um eine so genannte Umgebungsvariable. Umgebungsvariablen sind Einstellungen, mit denen Sie Ihr System spezifizieren können. Man kann sie sich als speicherresidente Variablen des Betriebssystems vorstellen, die globale Einstellungen festlegen. Sie werden z.B. unter der Windows-Plattform im Allgemeinen auf Befehlezeilenebene oder in der Autoexec.Bat mit der Anweisung »SET [Umgebungsvariable] = ...« gesetzt.

Die globale Pfadangabe setzen Sie in einer Windows-Umgebung also wie folgt: Set CLASSPATH=c:\java\lib\classes.zip;.

oder

Set CLASSPATH=c:\jdkx.x.x\lib\classes.zip;.

x.x.x ist dabei wieder die konkrete Versionsangabe, die defaultmäßig den Namen des JDK-Verzeichnisses festlegt. Classes.zip ist das RUNTIME-Modul (die Systemklassen) von Java in den früheren Versionen. Dabei fällt wahrscheinlich auf, dass explizit eine ZIP-Datei angegeben ist. Java ist in der Lage, diese ZIP-Dateien direkt zu nutzen. Der nach dem Semikolon folgende Punkt gehört ebenfalls zur CLASSPATH-Umgebungsvariable und steht für das aktuelle Verzeichnis. Damit werden JDK-Programme noch einmal ausdrücklich angewiesen, das aktuelle Verzeichnis zu durchsuchen.

Neben dem globalen CLASSPATH gibt es einen weiteren Suchpfad für die Systemklassen, der als Option -classpath bei den entsprechenden Tools individuell gesetzt werden kann und die globale Angabe überschreibt. In den alten Versionen des JDK wurden alle Java-Klassen mithilfe des Pfades gesucht, der über die Option -classpath bei einem Tool oder der CLASSPATH-Umgebungvariable gesetzt war.

Über die Angagen bestimmen Sie in diesen älteren Versionen der Java-Umgebung, von wo aus Java-Klassen importiert werden. Verwenden Sie unter Windows das Semikolon, um die Liste von Verzeichnissen (und ZIP-Dateien, die Java direkt verwenden kann) voneinander zu trennen. Unix benötigt Doppelpunkte. Um sich das Verfahren klar zu machen, denken Sie einmal daran, wie normal ausführbare Dateien aus der Befehlszeile aufgerufen werden. Wenn ein DOS- oder Unix-Anwender den Namen eines Programms eingibt und auf die Eingabetaste drückt, sucht der Befehls-Interpreter nach einem ausführbaren Programm für den angegebenen Namen, lädt das Programm, wenn er es findet, in den Speicher und beginnt mit der Ausführung. Die Path-Variable bestimmt, wo und in welcher Reihenfolge der Befehlsinterpreter nach dem ausführbaren Programm sucht. Bei dem Suchkonzept für Java-Klassen ist es zwar ähnlich, wobei aber Java-Programme nicht direkt ausgeführt werden, sondern indirekt vom Java-Interpreter. Sie werden dazu vom Interpreter, einem Browser oder einem Hilfsprogramm wie dem Appletviewer (Teil des Java Development Kits) geladen und dort dann ausgeführt. Da diese Dateien also nicht direkt vom Betriebssystem ausgeführt werden können, wird die Path-Variable des Betriebssystems keinen Effekt mehr haben (darüber würde nur der Interpreter gefunden). Aus diesem Grund wird für diese Funktionalität Ersatz benötigt. Wo ein Betriebssystem die Path-Variable verwendet, um ausführbare Dateien zu finden, nimmt Java einen internen Suchpfad, um Klassen zu finden. Java durchsucht die angegebenen Verzeichnisse, um geeignete .class-Dateien zu finden.

Wenn Sie verschiedene Versionen des JDK gleichzeitig auf dem Rechner verwenden möchte, sollten Sie wie gesagt mit zwei oder mehr verschiedenen Umgebungen arbeiten. Ganz wichtig ist dann jedoch, dass bei älteren JDK-Versionen auch die CLASSPATH-Angaben unterschiedlich konfiguriert sind. Dazu sollten Sie in jeder DOS-Box bzw. jedem Shell-Fenster die CLASSPATH-Angaben explizit setzen. Am besten löschen Sie mit set CLASSPATH= (Windows) bzw. % unsetenv CLASSPATH (Solaris) zuerst eine evtl. vorhandene Umgebungsvariable und setzen sie dann auf das aktuelle JDK-Verzeichnis. Man kann zwar die CLASSPATH-Angabe über getrennte Einträge auf verschiedene Verzeichnisse erweitern. Davon ist aber dringend abzuraten. Aus zwei Gründen: zum einen wird es aus ähnlichen Gründen wie bei der Path-Angabe nicht einwandfrei funktionieren, zum anderen sollte aus Sicherheitsgründen die CLASSPATH-Angabe nicht unnötig erweitert werden. Eine Klasse, die in einem mit der CLASSPATH-Angabe spezifizierten Verzeichnis steht, wird beim Laden vom Classloader nicht mehr auf Viren und Fehler geprüft. Deshalb sollten dort ausschließlich absolut vertrauenswürdige Klassen stehen.

Nochmals zu Verdeutlichung: Die bisherigen Ausführungen zum CLASSPATH betreffen die JDK-Version 1.1.x und die meisten 1.2-Betaversionen, haben also die grundsätzliche Vorgehensweise und die Hintergründe der früheren JDKs behandelt. Ein wesentliches Problem bei diesen Versionen des CLASSPATH war die Tatsache, dass es zu Konflikten zwischen der dauerhaft gesetzten Angabe und der -classpath-Option einzelner Tools kommen konnte (Versionskonflikte der Laufzeitumgebung usw.).

Sun empfiehlt prinzipiell für neue JDKs, die globale Angabe überhaupt nicht mehr zu setzen und die individuelle Variante zu verwenden, sofern Klassen nicht gefunden werden. Diese Aussage muss aber sogar noch verschärft werden (trotz anders lautender Beteuerungen von Sun). In neuen Versionen des JDK kann die CLASSPATH-Umgebungsvariable eine Menge Ärger bereiten. Sie sollten unbedingt darauf verzichten und bei scheinbar unerklärlichen Fehlern beim Finden von Klassen die Umgebungsvariablen überprüfen. Setzen Sie die Umgebungsvariable explizit auf leer (Set CLASSPATH=).

Java geht ab dem JDK 1.2 (Final) beim Finden von Klassen prinzipiell einen neuen Weg. Leider dokumentiert Sun dies nicht so deutlich und leicht verständlich, wie es wünschenswert wäre. Das kurz nach der Freigabe des JDK-1.2-Finals vor Hilferufen überquellende Usenet verdeutlichte dies recht drastisch. Die meisten Hilferufe in allen Sprachen waren der Art »Ich habe gerade das JDK 1.2 geladen und installiert und nichts geht mehr« oder »Ich habe gerade das JDK 1.2 installiert und finde die Datei classes.zip nicht. Ich verwende aber das Entwicklungstool xyz, das diese Datei benötigt«. Eine Suche nach anderen Schlagworten rund um die Laufzeitumgebung von Java führte zu zahlreichen weiteren (oft ziemlich verzweifelten) JDK-1.2-Anwendern.

Aber es ist alles halb so schlimm - nur komplett anders als in den früheren JDK-Versionen. Die meisten Probleme waren ziemlich überflüssig und wären bei einer besseren Bekanntmachung durch Sun nie aufgetreten. Zwar hat Sun ziemlich brutal Dinge im JDK verändert, aber die Probleme beruhten auf der unverständlichen Dokumentation dieser Veränderungen nach außen. Probleme hatten vor allem die JDK-Anwender, die bereits mit einem älteren JDK arbeiteten. Diese suchten analog den bisherigen JDKs die Datei classes.zip und fanden sie nicht mehr. Worauf sollte also der CLASSPATH gesetzt werden?

Die Antwort auf alle Fragen¹ ist so einfach, dass Sun es wohl nicht für nötig erachtet hat, dieses richtig deutlich zu machen - das JDK ab der Version 1.2 (Final) benötigt die Datei classes.zip nicht mehr und der CLASSPATH muss (und darf - beachten Sie den Hinweis) gar nicht mehr gesetzt werden. Nicht mehr und nicht weniger.

Die Veränderungen fanden genau genommen in der Beta-4-Version des JDK 1.2 statt. Dies dürfte auch einer der Hauptgründe für die allgemeine Verwirrung um den CLASSPATH und die Datei classes.zip sein. Zum Zeitpunkt des Erscheinens der letzten Betaversion wartete die ganze Welt bereits auf das Finalrelease. Immerhin war es bereits mehr als ein halbes Jahr überfällig. Die letzte Betaversion wurde deshalb nicht so stark beachtet und die massiven Veränderungen fielen nur wenigen Anwendern auf. In der Finalversion wurden diese Beta-4- Veränderungen dann nur noch sehr mager deutlich gemacht.

Dass die CLASSPATH-Angabe nicht gesetzt wird (bzw. werden darf), bedeutet nicht, dass die Tools des JDK die Systemklassen nicht mehr benötigen. Die Systemklassen (in der Datei rt.jar) finden sie nur nach einer erfolgreich durchgeführten Installation des JDK automatisch, wenn sie im lib-Verzeichnis von jre (die Laufzeitumgebung) vorhanden sind. Dabei ist es belanglos, ob es sich um das jre-Verzeichnis innerhalb des JDK-Verzeichnisses handelt oder das eigenständige jre-Verzeichnis einer Installation durch andere Programme.

Ab dem JDK 1.2 gibt es nun ein Konzept mit drei Suchpfaden, die zum Auffinden von Klassen verwendet werden². Die Suche erfolgt streng hierarchisch nach folgendem Ablauf:

1. Die erste Stelle, an der Java nach Klassen sucht, ist der bootstrap Classpath - der Standardpfad zu den Systemklassen, der bereits nach der erfolgreichen Installation des JDK festliegt. Das aktuelle Verzeichnis ist immer darin enthalten. Der Wert dieser Pfadangabe kann über System.getProperty("sun.boot.class.path") ermittelt werden. Diese Pfadangabe sollte beim Aufruf eines Tools normalerweise nicht verändert werden. Die Option -classpath überschreibt diesen Pfad nicht mehr (wie etwa im alten Konzept), sondern gibt nur an, wo die anwenderdefinierten Klassen zusätzlich zu suchen sind. Zum Überschreiben des bootstrap Classpath (was so gut wie nie notwendig sein sollte) gibt es die neu eingeführte Aufrufoption -Xbootclasspath/-bootclasspath.
2. Der zweite Suchpfad sind die optionalen Java-Erweiterungsverzeichnisse. Die Liste dieser Verzeichnisse kann über System.getProperty("java.ext.dirs") ermittelt werden.
3. Die dritte und letzte Stelle, wo Java nach Klassen sucht, ist der »Applikations-Classpath« (also der von der Applikation individuell durch eine Option gesetzte Suchpfad, der auf anwenderdefinierte Klassen verweist). Der Wert von dieser Pfadangabe kann über System.getProperty("java.class.path") ermittelt werden. Falls die Option bei einem Tool-Aufruf nicht gesetzt wird, werden Sie für diesen Wert einen Punkt erhalten.

Wenn Sie sich bereits mit Java und den Tools ein wenig auskennen, können Sie das nachfolgende Testprogramm ausprobieren. Wenn Sie den Java-Quelltext selbst eingeben wollen, starten Sie bitte einen beliebigen ASCII-Editor und geben Folgendes ein (Name der Datei: Pfade.java):

class Pfade {
public static void main(String argv[]){
System.out.println("Der bootstrap Classpath: " + System.getProperty("sun.boot.class.path"));
System.out.println("Die optionalen Java-Erweiterungsverzeichnisse: " + 
System.getProperty("java.ext.dirs"));
System.out.println("Der Applikations-Classpath: " + System.getProperty("java.class.path"));
} }

Über den Aufruf javac Pfade.java können Sie den Compiler anweisen, die Datei zu übersetzen. Anschließend rufen Sie das Programm über java Pfade auf. Sie finden den Quelltext samt bereits übersetztem Programm auch auf der CD in dem Begleitmaterial zu diesem Kapitel.

Abbildung 3.15: Pfadeinstellungen

3.4.3 Verwendung von mehreren JDK-Versionen unter Windows

Wenn Sie unter Windows verschiedene Versionen des JDK gleichzeitig auf dem Rechner verwenden möchten und deshalb unterschiedlich konfigurierte DOS-Boxen benötigen, sind zwei (oder entsprechend mehr) kleine Batchdateien vielleicht sehr hilfreich.

Tragen Sie in der Autoexec.Bat keine um das Verzeichnis der JDK-Tools erweiterte Pfadangabe und keine CLASSPATH-Umgebungsvariable ein (dies ist sowieso nur noch nötig, falls Sie mit einem älteren JDK arbeiten) ein. Statt dessen erstellen Sie entsprechend der Zahl Ihrer gewünschten JDK-Versionen die folgenden Batchdateien:

Für JDK-Versionen vor 1.2:

PATH=%path%;[Verzeichnis der JDK-Tools];
SET CLASSPATH=[Verzeichnis der Systemdateien]\classes.zip;.

Für JDK-Versionen ab 1.2:

PATH=%path%;[Verzeichnis der JDK-Tools];
SET CLASSPATH=

Speichern Sie die Dateien in Ihrem BATCH-Verzeichnis (wenn Sie ein solches haben) oder in einem Verzeichnis in dem Suchpfad des Kommando-Interpreters Ihres Betriebssystems.

Ihr Pfad kann nicht beliebig lang werden. Sonst bekommen Sie irgendwann die Fehlermeldung »Kein Platz im Umgebungsbereich«. Arbeiten Sie mit nicht zu langen Pfadangaben (bzw. setzten Sie Ihren Pfad aus mehreren einzelnen Teilstücken, die in verschiedenen Variablen gespeichert werden, zusammen) oder konfigurieren Sie Ihren Rechner mittels der Umgebungsparameter so, dass er einen größeren Umgebungsbereich nutzen kann. Dazu muss jedoch im Rahmen eines Java-Buchs auf entsprechende Literatur zum Betriebssystem verwiesen werden.

Wenn Sie nun eine DOS-Box für die Arbeit mit dem JDK öffnen, rufen Sie einfach zuerst die passende Batchdatei auf und die Pfad- und Umgebungsangaben sind korrekt gesetzt.

Noch komfortabler unter Windows ist die Erstellung eines eigenen Programmsymbols für die jeweilige JDK-DOS-Box im Arbeitsplatz oder Windows-Startmenü mit der direkten Übergabe der passenden Batchdatei als Programmaufruf-Parameter.

Die DOS-Boxen werden in Windows über so genannten PIF-Dateien (Program Interfaces) realisiert. Erstellen Sie zuerst für jede JDK-DOS-Box im Windows-Startmenü einen eigenen Eintrag oder erstellen Sie im Arbeitsplatz bzw. Explorer ein Icon für einen Programmaufruf. Am einfachsten geht das, wenn Sie die Orginal-DOS-Eingabeaufforderung duplizieren und nur mit neuen Namen versehen. Sie können folgendermaßen vorgehen:

1. Öffnen Sie zuerst den Arbeitsplatz.
2. Wechseln Sie in das gewünschte Verzeichnis.
3. Erstellen Sie dort eine Verknüpfung zum DOS-Prompt. Dazu suchen Sie sich ein bestehendes Symbol für das DOS-Prompt und klicken beispielsweise mit der rechten Maustaste darauf. Im Kontextmenü finden Sie dann einen Eintrag zur Erstellung einer Verknüpfung.
4. Benennen Sie die Verknüpfung um (z.B. JDK 1.0 oder JDK 1.3).
5. Wiederholen Sie den Vorgang für alle JDK-Versionen, die Sie verwenden wollen.
6. Nun müssen die PIF-Dateien entsprechend angepasst werden. Die Bearbeitung von solchen PIF-Dateien erfolgt in Windows-Versionen vor Windows 95 bzw. NT 4 in dem so genannten PIF-Editor. Das Eigenschaftenfenster ersetzt ab Windows 95 und Windows NT ab der Version 4.0 den PIF-Editor. Der PIF-Editor soll noch kurz am Ende des Abschnitts erklärt werden, wir setzen den Vorgang mit dem Eigenschaftenfenster fort. Klicken Sie mit der rechten Maustaste im Arbeitsplatz auf das Symbol für das Programm.
7. Klicken Sie im Menü Datei oder im Kontextmenü auf Eigenschaften.
8. Wählen Sie dort das Registerblatt Programm.
9. Tragen Sie die gewünschte Programmbezeichnung ein.
10. Legen Sie bei Bedarf ein Anfangsverzeichnis fest.
11. Jetzt kommt das Wichtigste: Im Textfeld Stapelverarbeitungsdatei muss die passende Batchdatei (am besten mit vollständiger Pfadangabe) als Programmaufruf-Parameter eingetragen werden.
12. Wenn Sie wollen, können Sie mit der Schaltfäche Anderes Symbol noch ein schöneres Icon wählen.
13. Sie können festlegen, ob die JDK-BOX in einem Fenster oder als Vollbild gestartet wird, indem Sie die Eigenschaften für Ausführen in der Registerkarte Bildschirm ändern. Vollbild ist in der Regel zu empfehlen.
14. Wiederholen Sie den Vorgang für alle JDK-Versionen, die Sie verwenden wollen.

Die angegebenen Einstellungen werden mit der Batchdatei immer dann verwendet, wenn Sie das Programm durch Doppelklicken auf das zugehörige Symbol starten. Es sollten alle Pfad- und Set-Angaben nun für jede JDK-Version passen.

In Windows werden Programme meist mit dem Startmenü gestartet. Deshalb wollen wir nun noch die JDK-Boxen dort eintragen:

1. Klicken Sie mit der rechten Maustaste auf eine freie Stelle der Taskleiste.
2. Wählen Sie dort Eigenschaften aus.
3. Wählen Sie das Registerblatt Programme im Menü »Start«.
4. Wählen Sie die Schaltfäche Hinzufügen.
5. Geben Sie die Befehlszeile für die DOS-Eingabeaufforderung ein oder verwenden Sie die Durchsuchen-Schaltfäche. Auf jeden Fall sollte eine PIF-Datei für die jeweilige Version des JDK dort verwendet werden.
6. Im nächsten Schritt legen Sie fest, wo genau das Programmsymbol im Startmenü positioniert werden soll.
7. Im letzten Schritt muss noch die Bezeichnung für die JDK-Box gewählt werden.

Den PIF-Editor unter Windows NT vor der Version 4.0 rufen Sie in der Programmgruppe Hauptgruppe oder mit dem Befehl PIFEDIT auf. Laden Sie dort die Datei DOSPRMPT.PIF als Schablone. Verfahren Sie dann analog wie oben beschrieben. Statt im Textfeld Stapelverarbeitungsdatei tragen Sie die passende Batchdatei (am besten mit vollständiger Pfadangabe) als die Batchdateien im Textfeld Programmparameter ein.

Es funktioniert nicht, wenn Sie eine DOS-Box öffnen, dort eine der Batchdateien aufrufen und mit der einen JDK-Version arbeiten und anschließend dort eine der anderen Batchdateien aufrufen, um in der gleichen DOS-Box mit einer anderen JDK-Version zu arbeiten. Der Grund ist der Pfad, der dann nur um das andere JDK-Verzeichnis erweitert wird. Sie haben dann oben beschriebene Probleme mit dem Suchpfad. Sie müssen explizit eine neue DOS-Box öffnen.

3.4.4 »Class not found« und andere Fehlermeldungen

Häufig auftretende Fehlermeldungen beim Arbeiten mit dem JDK - hauptsächlich dem Java-Interpreter oder einem Browser - sind »Class not found«, »Unable to initialize threads« oder »Can't find class ...«. Dies kann leider diverse Ursachen haben.

Dabei ist die einfachste Lösung, dass Sie beim Aufruf des Java-Interpreters einen Schreibfehler gemacht haben oder die Groß- und Kleinschreibung beim Namen der Klasse nicht genau eingehalten haben. Java unterscheidet strikt zwischen groß und klein geschriebenen Namen.

Ein fehlender Eintrag der JDK-Tools in den Suchpfad kann ebenso für diese Meldungen verantwortlich sein.

Ein weiterer einfacher Fehler ist, dass beim Aufruf des Java-Interpreters die Erweiterung .class mit eingegeben wurde. Es darf aber nur der Klassennamen spezifiziert werden und nicht die Klassenerweiterung. Dazu mehr bei der Besprechung der einzelnen JDK-Werkzeuge.

Ein anderer Grund betrifft die Systemklassen. Stellen Sie sicher, dass sich Ihre Systemklassen auch in dem Verzeichnis befinden, in dem Sie sie installiert haben.

Leider müssen diese unliebsamen Fehlermeldungen bei nicht richtig eingerichteten Entwicklungsplattformen unter Umständen noch anderen potenziellen Fehlerquellen zugeschrieben werden. Es gibt viel heimtückischere Fehlerkonstellationen, die eigentlich nichts direkt mit dem JDK zu tun haben. Besonders, wenn man mit Windows 95/98 und einigen »älteren« 16-Bit-Programmen arbeitet (was heute zwar selten vorkommen sollte, aber nicht auszuschließen ist). Es gibt einige Arbeitsschritte, die bei solchen Mischkonstellationen .class-Dateien oder andere Objekte so beeinflussen, dass sie nicht mehr korrekt verwendet werden können. Zwei potenzielle Fehlersituationen folgen, aber das gilt in demselben Maße für analoge Situationen.

Wenn man Dateien mit schnellen und einfachen DOS-(16-Bit-) Programmen kopiert, wird die 16-Bit-Software die Dateien zwar korrekt kopieren, dabei jedoch eventuell auftretende lange Dateinamen (unter anderem die Endung .class) verstümmeln (auf die Kennung .cla, und das langt weder einem Browser noch dem Java-Interpreter). Außerdem sind lange Namen vor dem Punkt auf maximal 8 Zeichen verkürzt, was jedoch nicht so schwerwiegend sein muss (dies hat beispielsweise keine Auswirkung, wenn der Name sowieso kürzer war). Deshalb ist es notwendig, Dateien mit langen Dateinamen unbedingt mit 32-Bit-Software zu kopieren. Dieses Problem entsteht übrigens in gleicher Weise, wenn man mit 16-Bit-Komprimierungsprogrammen oder anderen datenverarbeitenden 16-Bit-Programmen arbeitet.

Eine weitere Fehlerquelle hat mit dem eben beschriebenen Problem viel gemeinsam, obwohl nicht mit 16-Bit-Software kopiert wird. Sie ist daher noch heimtückischer. Wenn auf einem PC mit DOS oder Windows 3.x neuere Windows-Versionen installiert werden, wird bei der Installation eine Hardware-Erkennung durchgeführt. Dieser Mechanismus arbeitet (vor allem unter Windows 95) nur mäßig stabil, sodass ein CD-Laufwerk oft nicht korrekt identifiziert wird. Dennoch wird es unter Umständen anzusprechen sein, denn beim Start von Windows 95 werden die eventuell vorhandene alte AUTOEXEC.BAT und die CONFIG.SYS abgearbeitet und alte 16-Bit-Treiber für das CD-Laufwerk eingerichtet. In diesem Fall kann man relativ problemlos auf eine CD zugreifen. Wenn man wie üblich auf CDs arbeitet und höchstens ein Programm mit einem maximal 8 Zeichen langen Namen (normalerweise auf CDs ein Setup-Programm) startet, werden kaum Probleme auftreten.

Anders sieht es aus, wenn man zum Beispiel von einer CD Dateien kopiert. Dann werden die Dateinamen durch die 16-Bit-Treiber wie oben verstümmelt. Sogar, wenn man mit den Windows 95-eigenen Tools wie dem Windows Explorer oder dem Windows-Arbeitsplatz arbeitet. Diese Tools interpretieren durch die falsche Hardware-Erkennung des CD-Laufwerks alle Objekte auf einer CD nur mit den DOS-Namenskonventionen. Das führt beispielsweise dazu, dass ein Doppelklick auf eine auf der CD befindliche HTML-Datei den verknüpften Browser korrekt startet, die HTML-Datei wahrscheinlich sauber lädt, aber dann alle über lange Dateinamen angesprochene Objekte (Java-Applets, jedoch auch zum Beispiel Grafiken mit langen Namen) nicht finden kann.

Erkennen kann man diese Situation relativ einfach, da lange Dateinamen in Anzeigefenstern in der typischen 8-Bit-Schreibweise mit dem ~-Zeichen auftreten. Leider hat man oft eine Anzeigeform gewählt, die dazu führt, dass man sich bei Auftreten des Zeichens nichts denkt und vor lauter Wald die Bäume nicht sieht.

Abbildung 3.16: Die Schlange bei den Dateinamen macht das Problem sogar im Windows Explorer deutlich.

Bei Vorliegen dieser Fehlerkonstellation muss das CD-Laufwerk neu unter Windows angemeldet werden. Dazu ist es am besten, wenn beim Starten von Windows die Abarbeitung von der alten AUTOEXEC.BAT und der CONFIG.SYS mit der F8-Taste unterbunden wird, dann aus dem Bootmenü die Einzelbestätigung ausgewählt und bei der Frage nach Ausführen der AUTOEXEC.BAT und CONFIG.SYS verneint wird. Wundern Sie sich nicht, wenn Ihr CD-Laufwerk anschließend nicht mehr erkannt wird, denn in der beschriebenen Fehlersituation war die Erkennung ja nur durch alte DOS-Treiber gewährleistet. Führen Sie die Hardware-Erkennung von Windows manuell durch. Danach ist das Problem (hoffentlich) beseitigt.

Die Meldungen »Applet can't start« oder »Applet not initializied« gehören gleichfalls in diese Reihe von Meldungen, die oft auf eine Mischkonstellation bei der Software zurückzuführen sind. Ein weiterer Grund für Fehler beim Starten von Applets und für Fehler des Java-Interpreters kann sein, dass das Applet/die Java-Anwendung in einem falschen Verzeichnis gesucht wird.

Im Fall von Applets und HTML-Quelltext ist die Situation beispielsweise die folgende: Es wird im <APPLET>-Tag mit CODEBASE=[Verzeichnis] auf ein konkretes Verzeichnis verwiesen (absolut oder meist relativ), wo sich das Applet befinden muss. Falls die CODEBASE=[Verzeichnis]-Angabe im <APPLET>-Tag der HTML-Datei fehlt (Regelfall), wird davon ausgegangen, dass sich das Applet im selben Verzeichnis wie die HTML-Datei befindet. Falls dies nicht der Fall ist, kommt eine Fehlermeldung.

Die Fehlermeldung »net.socketException: errno = 10047« oder »Unsupported version of Windows Socket API« kann auftauchen, wenn Sie die falschen TCP/IP-Treiber verwenden. Die Meldung »System Error during Decompression« kann angezeigt werden, wenn nicht genug Platz auf der Festplatte mit Ihrem TEMP-Verzeichnis vorhanden ist.

Die Meldung »This program cannot be run in DOS mode« erscheint, wenn die DOS-Shell falsch konfiguriert ist.

Wenn der Appletviewer keine Applets lädt, müssen unter Umständen einige Umgebungsvariablen gesetzt werden. Etwa so:

set HOMEDRIVE=c:
set HOMEPATH=\

oder

set HOME=c:\

und anschließendem Neustart des Appletviewers. Falls das nicht hilft, versuchen Sie über java -verbose sun.applet.AppletViewer herauszufinden, welche Klassen von wo geladen werden. Anhand der ausgegebenen Liste können Sie überprüfen, ob alle Klassen vorhanden sind. Damit kann auch die allgemeine Funktion des Appletviewers überprüft werden.

3.4.5 Die Java-Umgebungsvariablen

Java besitzt einige Umgebungsvariablen, die in früheren Versionen des JDK gesetzt werden mussten (was immer noch von Interesse ist, wenn man verschiedene Versionen des JDK führen muss). Die meisten Umgebungsvariablen werden nicht mehr verwendet. Hauptsächlich der HotJava-Browser in der alten Version benötigt sie. Seit der parallel zum JDK 1.1.1 oder höher vertriebenen Version des HotJava ist es nicht mehr notwendig, die Browser-Umgebungsvariablen zu setzen. Die CLASSPATH- und die JAVA_HOME-Umgebungvariable allerdings haben nichts damit zu tun und sind oft bei fehlerhafter Zuweisung Quelle diverser Fehlermeldungen. Unter Umständen können Sie die folgende Auflistung von Umgebungsvariablen setzen und einige Probleme bei alten Versionen beheben. Schaden kann ein Setzen der Umgebungsvariablen selten.

WWW_HOME: Setzt eine Standard-URL für die Start-Homepage des HotJava-Browsers.

HOTJAVA_HOME: Einstellung des Verzeichnisses, in dem HotJava nach den Dateien sucht, die notwendig sind, um den Browser korrekt ablaufen zu lassen.

HOTJAVA_READ_PATH: Diese Umgebungsvariable legt für HotJava das Verzeichnis fest, in dem Applets auf Dateien einen Zugang mit Leserechten haben. Dies kann als Sicherheitsvorkehrung für Applets, die möglicherweise nicht autorisierte Informationen lesen könnten, verwendet werden.

HOTJAVA_WRITE_PATH: Das Analogon zur HOTJAVA_READ_PATH-Umgebungsvariable für den Fall von Schreibvorgängen.

CLASSPATH: Der Suchpfad für Klassen (wir sind darauf bereits eingegangen).

JAVA_HOME: Normalerweise muss das Verzeichnis des JDK nicht explizit in dieser Umgebungsvariable gespeichert werden. Falls Sie allerdings die Fehlermeldung »Error Message: Could not read properties file« erhalten, kann es in einigen Versionen des JDK daran liegen, dass diese Umgebungsvariable nicht gesetzt ist. In diesem Fall können Sie testweise JAVA_HOME auf das JDK-Verzeichnis setzen. Auch die Meldung »Error message: Invalid JAVA_HOME« deutet auf einen Fehler in der Umgebungsvariable JAVA_HOME hin. Sie ist dann zwar gesetzt, jedoch auf das falsche Verzeichnis.

3.4.6 Unbekannte Fehler

Natürlich gibt es in dem JDK Fehler und Probleme, die man noch nicht erkannt bzw. beseitigt hatte, als die jeweilige Version der Software auf den Markt kam. Es gibt deshalb seit der ersten Version des JDK immer eine aktuelle Liste der wichtigen neu erkannten und der für das nächste Update bereinigten Fehler. Unter http://java.sun.com/products/jdk/ finden Sie aktuelle Fehlermeldungen. Besser ist jedoch, wenn Sie als registriertes Mitglied an die Bug-Database der Developer-Connection (unter http://developer.java.sun.com/developer/) kommen.

3.5 Die wichtigsten JDK-Tools

Das JDK besteht aus einer ganzen Reihe von Tools. Die wichtigsten Tools waren schon Bestandteil der 1.x-Versionen, viele kamen jedoch erst in der 1.1-Version dazu. Natürlich brachten Folgeversionen weitere Neuerungen (insbesondere wurden Tools der Version 1.1 wieder beseitigt, weil sie nicht so funktioniert hatten wie geplant oder weil sie nicht mehr benötigt wurden). Der Java-Interpreter und der Java-Compiler sind ja schon mehrfach aufgetaucht. Auch der Begriff Appletviewer ist schon gefallen. Es gibt aber noch weitere Tools, die sich im JDK-Unterverzeichnis \bin befinden sollten. An dieser Stelle wollen wir die Basis-Tools samt der wichtigsten Optionen besprechen. Im Anhang gehen wir dann noch intensiver auf die JDK-Programme ein.

Zu den Basis-Programmen des JDK 1.3 (also denjenigen, die Sie zum Erstellen von Java-Applets und -Applikationen brauchen) zählen die folgenden:

Der Appletviewer, um Java-Applets stand-alone zu betrachten
Der Java-Compiler Javac
Der Java-Interpreter Java und sein nahezu identisches Schwesterprogramm Javaw

Diese Programme werden den Schwerpunkt der nachfolgenden detaillierteren Beschreibung der JDK-Tools bilden. Sie sind für die meisten Entwickler von zentraler Bedeutung.

Neben den Basistools beinhaltet das JDK eine Vielzahl an weiteren Programmen, die die zusätzlichen Funktionalitäten von Java abdecken. Diese Programme werden wir im Anhang besprechen.

3.5.1 Ein paar allgemeine Hinweise zu den JDK-Programmen

Bei der Arbeit mit den JDK-Programmen gibt es ein paar Punkte zu beachten. Teilweise sind sie nur von allgemeinem Interesse, einige Details sollte man jedoch kennen. Und zu guter Letzt können Sie sich bei der Arbeit mit den JDK-Programmen mit ein paar Tricks viele monotone Arbeitsvorgänge ersparen.

Wenn man ein Programm des JDK ohne irgendwelche Parameter aufruft, bekommt man manchmal die notwendigen Angaben für die korrekte Syntax in Kurzform aufgelistet. Die Betonung liegt bedauerlicherweise auf »manchmal«. Die JDK-Programme erweisen sich in der Handhabung leider als nicht vollständig aufeinander abgestimmt. Ein Aufruf ohne Parameter schadet zwar nie, aber das Resultat ist nicht immer befriedigend. Der Interpreter beispielsweise erzeugt eine recht ausführliche Hilfe auf dem Bildschirm, der Compiler zumindest noch eine Kurzhilfe, während andere Programme in einigen Versionen des JDK mit Fehlermeldungen reagieren. Auch die manchmal existente Option -Help funktioniert in einigen JDK-Versionen beim Schwesterprogramm unter Umständen nicht. Die Option -version, die mal funktioniert, mal nicht, zählt zu den weiteren Kinderkrankheiten von einigen Versionen des JDK. Die unterschiedliche Handhabung bei der Angabe von Dateierweiterungen gehört ebenfalls zu dieser inkonsequenten Logik. Andererseits darf man bei einem kostenlosen Entwicklungswerkzeug dieser Mächtigkeit in Details keine Perfektion erwarten. Hauptsache, man kann Java nutzen.

Für die eigentlichen Programmaufrufe ist eine Arbeit auf Befehlszeilenebene auf jeden Fall zu empfehlen (so lange man ohne IDE arbeitet). Zwar kann man aus einer grafischen Oberfläche wie Windows Befehle mit Optionen und Parametern eingeben. Beispielsweise mit dem Ausführen-Befehl im Windows-Startmenü. Anzuraten ist eine solche Vorgehensweise jedoch nicht, da eventuelle Rückmeldungen des Systems schlecht oder gar nicht auszuwerten sind. Meist ist das Fenster schon wieder geschlossen, bevor man die Rückmeldung gelesen hat. Ein permanent offenes Befehlszeilenfenster ist auf jeden Fall besser. Ein - wahrscheinlich ziemlich trivialer - Hinweis muss dabei jedoch unter Windows unbedingt beachtet werden: Sie dürfen wegen der langen Dateinamen auf keinen Fall mit einer alten 8-Bit-DOS-Version arbeiten, sondern nur mit der Windows-Eingabeaufforderung bzw. der DOS-Version für Windows 95/98.

Migrationen

Grundsätzlich muss man sich Gedanken machen, wenn man eine Migration von einem JDK auf eine Nachfolgeversion vollziehen will. Dabei kann es einmal vorkommen, dass bisher verwendete Programme in der neuen Version nicht mehr vorzufinden sind. So lagen einige der Programme des JDK 1.1 jeweils in zwei Versionen vor. Es handelte sich jedes Mal um eine Standardvariante und eine mit _g erweiterte, nicht optimierte Spezialversion, die hauptsächlich für das Debugging eingesetzt werden konnte (die Syntax war immer identisch mit der Standardversion). Im JDK 1.2 wurden sie weggelassen. Wenn so etwas vorkommt, werden die Standardprogramme meist um die Funktionalität der weggelassenen Programme erweitert oder die Funktionalität macht keinen Sinn mehr.

Recht analog verhält es sich mit Optionen. Ab dem JDK 1.2 verstehen einige Tool so genannte Non-Standard-Options. Neben dem Satz von Standardoptionen gibt es nun die Möglichkeiten, einen Satz von weitergehenden Kommandozeilenoptionen zu verwenden. Diese Non-Standard-Options beginnen bis auf wenige, explizit gekennzeichnete Ausnahmen 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 jeweiligen JDK und allen zukünftigen Versionen der JVM durch Sun garantiert wird. Eine Unterstützung für die Nicht-Standardoptionen wird jedoch ausdrücklich für zukünftige Versionen der JVM nicht garantiert. Beim Wechsel auf das JDK 1.3 wurden wieder diverse Optionen weggelassen, verändert oder nicht mehr dokumentiert. Dafür gibt es dann aber einige neue Tools, deren Zweck die Simulation der alten Tools ist.

Auf den Webseiten von Sun finden Sie einen Abschnitt mit den häufig zu den JDK-Programmen und Java gestellten Fragen (FAQ). Schauen Sie sich einfach mal die Seite http://java.sun.com/products/jdk/faq.html an.

DOSKEY

Bei der Arbeit auf Befehlszeilenebene kann man sich viel Arbeit und Zeit sparen, indem man einen Tastaturpuffer für die letzten Eingaben verwendet. Unter NT und Windows 2000 steht ein solcher Puffer immer zur Verfügung, nicht aber unter Windows 95 oder 98. DOSKEY ist ein solcher Tastaturpuffer, der seit DOS-Urzeiten vorhanden ist und Befehlseingaben bearbeitet, Befehle erneut aufruft und Makros erstellt.

Für die Verwendung von DOSKEY gilt folgende Syntax:

DOSKEY [/Optionen] [Makroname=[Text]]

Die Optionen können nach Wahl frei kombiniert werden und die Reihenfolge ist ebenfalls beliebig.

Optionen Beschreibung

/BUFSIZE:Größe Definiert die Größe des Befehlsspeichers (Standardgröße ist 512).

/ECHO:on|off Aktiviert/deaktiviert das Echo von Makroerweiterungen (Standardeinstellung ist on).

/FILE:Datei Datei mit einer Makroliste.

/HISTORY Zeigt alle gespeicherten Befehle an.

/INSERT Neu eingegebener Text wird in den vorhandenen eingefügt.

/KEYSIZE:Größe Definiert die Größe des Tastaturspeichers (Standardgröße ist 15).

/LINE:Größe Definiert die maximale Größe des Zeilenspeichers (Standardgröße ist 128).

/MACROS Zeigt alle DOSKEY-Makros an.

/OVERSTRIKE Neu eingegebener Text überschreibt vorhandenen (Standard).

/REINSTALL Installiert eine neue Kopie von DOSKEY.

[Makroname] Name für ein zu erstellendes Makro.

[Text] Befehle, die durch das Makro auszuführen sind.

Optionen	Beschreibung
/BUFSIZE:Größe	Definiert die Größe des Befehlsspeichers (Standardgröße ist 512).
/ECHO:on\|off	Aktiviert/deaktiviert das Echo von Makroerweiterungen (Standardeinstellung ist on).
/FILE:Datei	Datei mit einer Makroliste.
/HISTORY	Zeigt alle gespeicherten Befehle an.
/INSERT	Neu eingegebener Text wird in den vorhandenen eingefügt.
/KEYSIZE:Größe	Definiert die Größe des Tastaturspeichers (Standardgröße ist 15).
/LINE:Größe	Definiert die maximale Größe des Zeilenspeichers (Standardgröße ist 128).
/MACROS	Zeigt alle DOSKEY-Makros an.
/OVERSTRIKE	Neu eingegebener Text überschreibt vorhandenen (Standard).
/REINSTALL	Installiert eine neue Kopie von DOSKEY.
[Makroname]	Name für ein zu erstellendes Makro.
[Text]	Befehle, die durch das Makro auszuführen sind.

Tabelle 3.2: Die Optionen von DOSKEY

Die Bedienung von DOSKEY erfolgt im Wesentlichen mit den Pfeiltasten, ESC und den Funktionstasten. Hier folgen die vollständigen Tastenkombinationen:

Tastenkombination Beschreibung

NACH-OBEN Ruft den vorherigen Befehl ab.

NACH-UNTEN Ruft den nächsten Befehl (wenn vorhanden) ab.

ESC Löscht den aktuellen Befehl.

F7 Zeigt die gespeicherten Befehle an.

ALT+F7 Löscht die gespeicherten Befehle.

[Zeichen]F8 Sucht nach einem Befehl, der mit [Zeichen] beginnt.

F9 Wählt einen Befehl anhand seiner Nummer aus.

ALT+F10 Löscht die Makrodefinitionen.

Tastenkombination	Beschreibung
NACH-OBEN	Ruft den vorherigen Befehl ab.
NACH-UNTEN	Ruft den nächsten Befehl (wenn vorhanden) ab.
ESC	Löscht den aktuellen Befehl.
F7	Zeigt die gespeicherten Befehle an.
ALT+F7	Löscht die gespeicherten Befehle.
[Zeichen]F8	Sucht nach einem Befehl, der mit [Zeichen] beginnt.
F9	Wählt einen Befehl anhand seiner Nummer aus.
ALT+F10	Löscht die Makrodefinitionen.

Tabelle 3.3: Die Tastenkombinationen von DOSKEY

In der Makrodefinition von DOSKEY gibt es einige besondere Zeichenfolgen:

Zeichenfolge Beschreibung

$T Befehlstrennzeichen. Ermöglicht die Verwendung von mehreren Befehlen in einem Makro.

$1-$9 Ersetzbare Parameter. Sie entsprechen ungefähr den Parametern %1 - %9 bei Stapelverarbeitungsdateien.

$* Symbol für Elemente, die in der Befehlszeile dem Makro-namen folgen.

Zeichenfolge	Beschreibung
$T	Befehlstrennzeichen. Ermöglicht die Verwendung von mehreren Befehlen in einem Makro.
$1-$9	Ersetzbare Parameter. Sie entsprechen ungefähr den Parametern %1 - %9 bei Stapelverarbeitungsdateien.
$*	Symbol für Elemente, die in der Befehlszeile dem Makro-namen folgen.

Tabelle 3.4: Die Makrodefinitionen von DOSKEY

3.5.2 Der Appletviewer

Kommen wir zum ersten JDK-Tool. Der Appletviewer ermöglicht es, ohne die Hinzuziehung eines Java-fähigen Browsers ein Applet während der Laufzeit zu betrachten. Er benötigt dazu nur eine rudimentäre HTML-Datei, die eigentlich ausschließlich ein Tag mit Angabe des anzuschauenden Applets sowie eventuell benötigten Parametern enthalten muss. Er lädt alle Applets innerhalb der Webseite und führt sie - sofern es mehrere korrespondierende Applets gibt - jeweils in einem separaten Fenster aus. Wenn eine HTML-Datei kein Tag mit Angabe eines Applets enthält, bewirkt der Aufruf des Appletviewers nichts.

In den neuen Varianten versteht der Appletviewer sowohl das ursprünglich ausschließlich zu verwendende <APPLET>-Tag als auch die Tags <OBJECT> und <EMBED> zum Einbinden.

Der Appletviewer war ursprünglich das einzige Tool der JDK-Sammlung, das eine grafische Benutzerschnittstelle (GUI) besitzt. Im JDK 1.2 ist noch ein neues Sicherheitsprogramm mit GUI hinzugekommen, aber darüber hinaus finden Sie keine weiteren Programme mit GUI.

Der Appletviewer hat nur wenige Aufrufoptionen. Es gibt nur die folgende einfache Syntax:

Appletviewer [Optionen] [URL der HTML-Datei]

[URL der HTML-Datei] wird in der Regel einfach die HTML-Datei ohne irgendwelche Pfadangaben (wenn man in dem entsprechenden Verzeichnis steht) oder mit einfachen Pfadangaben auf dem lokalen Rechner (absolut oder relativ) sein. Die allgemeine Formulierung soll jedoch darauf hinweisen, dass dies natürlich nicht zwingend ist und der Appletviewer ebenso in der Lage ist, bei einer Online-Verbindung eine HTML-Datei samt Applet von einem beliebigen Server zu laden. Beachten Sie, dass die HTML-Datei mit der Endung einzugeben ist. Im Fehlerfall (auch bei falschen Optionen) erhalten Sie die Meldung »Make sure that [Name der HTML-Datei] is a file and is rendable« oder etwas Ähnliches.

Ab der Version 1.2 des JDK gibt es eine Neuerung. Sie müssen beim ersten Start des Appletviewers die Lizensbedingungen von Sun akzeptieren.

Folgende Optionen für den Appletviewer gibt es:

Optionen Beschreibung

-debug Diese Option gibt man an, wenn man den Appletviewer innerhalb des Java-Debuggers laufen lassen möchte. Als direkten Aufruf erzeugt der Appletviewer nur eine kurze Ausgabe auf Befehlszeilenebene.

-encoding [Verschlüssel_name] Spezifiziert den Verschlüsselungsnamen der HTML-Datei, der bei der Konvertierung verwendet wird. Die Option ist erst seit der Version 1.1.x sinnvoll, denn erst dort wurde die Verschlüsselungsfähigkeit in verschiedene Zeichen in Java integriert. Dieser Verschlüssel_name-String muss als korrektes Argument der Klasse CharacterEncoding definiert sein.

-J Javaoption Gibt den String Javaoption als ein einzelnes Argument an den Java-Interpreter weiter, der wiederum den Compiler startet. Das Argument darf keine Leerräume enthalten. Mehrere Argumente müssen jeweils mit dem Präfix -J beginnen. Dieses Präfix trennt die Argumente. Die Option ist erst seit der Version 1.1.x vorhanden.

Optionen	Beschreibung
-debug	Diese Option gibt man an, wenn man den Appletviewer innerhalb des Java-Debuggers laufen lassen möchte. Als direkten Aufruf erzeugt der Appletviewer nur eine kurze Ausgabe auf Befehlszeilenebene.
-encoding [Verschlüssel_name]	Spezifiziert den Verschlüsselungsnamen der HTML-Datei, der bei der Konvertierung verwendet wird. Die Option ist erst seit der Version 1.1.x sinnvoll, denn erst dort wurde die Verschlüsselungsfähigkeit in verschiedene Zeichen in Java integriert. Dieser Verschlüssel_name-String muss als korrektes Argument der Klasse CharacterEncoding definiert sein.
-J Javaoption	Gibt den String Javaoption als ein einzelnes Argument an den Java-Interpreter weiter, der wiederum den Compiler startet. Das Argument darf keine Leerräume enthalten. Mehrere Argumente müssen jeweils mit dem Präfix -J beginnen. Dieses Präfix trennt die Argumente. Die Option ist erst seit der Version 1.1.x vorhanden.

Tabelle 3.5: Die Optionen des Appletviewers

Abbildung 3.17: Der Appletviewer

Das Menü des Appletviewers

Beim Menü des Appletviewers handelt es sich um ein einfaches GUI-Menü. Sämtliche Einträge verbergen sich hinter dem Hauptmenü Applet. Von der ersten Version des Appletviewers bis zu den aktuellen Versionen sind einige Erweiterungen dazu gekommen.

Restart startet ein Applet mit den aktuellen Einstellungen neu. Eventuelle Veränderungen der zugehörigen Klassendatei (*.class) werden nicht berücksichtigt.
Reload lädt das Applet erneut. Bei diesem Vorgang kommen im Gegensatz zum Restart die Veränderungen in der Klassendatei zum Tragen.
Clone dupliziert das aktuelle Applet und ein weiterer Appletviewer (also ein neues Fenster) mit den gleichen Einstellungen wird gestartet.
Print... erzeugt einen Standarddialog zum Drucken des Applets. Der Eintrag ist nur in neueren Versionen des Appletviewers vorhanden und gibt Hintergrundinformationen des Applets aus.
Stop ist nur in neueren Versionen des Appletviewers vorhanden und stoppt das Applet. Wichtig ist, dass dies nicht Beenden bedeutet, sondern das Applet nur angehalten wird. Mehr dazu im Abschnitt über Applets. Der Menüeintrag ist nur dann aktivierbar, wenn das Applet läuft.
Start ist nur in neueren Versionen des Appletviewers vorhanden und startet ein gestopptes Applet erneut. Wichtig ist, dass dies nur für per Stop angehaltene Applets funktioniert. Mehr dazu bei dem Abschnitt über Applets. Der Menüeintrag ist nur dann aktivierbar, wenn das Applet per Stop angehalten wurde.
Save... erzeugt einen Standarddialog zum Speichern des Applets. Dabei wird eine Datei mit der Defaultendung .SER (das kommt von Serializible) erzeugt, die diverse Hintergrundinformationen (etwa Felder einer Komponente) des Applets speichert. Der Eintrag ist nur in neueren Versionen des Appletviewers vorhanden.
Der Befehl Tag zeigt in einem eigenen Fenster sowohl das HTML-Tag zum Einbinden des Applets als auch die zugehörigen Parameter für das Applet an, also einen Ausschnitt aus der aufrufenden HTML-Datei.
Innerhalb von Java kann man eine Standardmethode für Informationen über das Applet (public String getAppletInfo()) verwenden. Diese enthält beispielsweise Angaben über den Namen des Applets und den Autor. Der Menüeintrag Info zeigt diese Angaben in einem eigenen Fenster an. Falls die Informationen in dem Applet-Programm gesetzt wurden, werden sie dort aufgelistet, ansonsten werden in dem Info-Fenster nur »no applet info« und »no parameter info« angezeigt.
Properties zeigt in einem neuen Fenster die Sicherheitseigenschaften des Appletviewers an. Wie bereits erklärt, ist der Appletviewer in der Lage, HTML-Dateien und Applets aus einer Netzwerkumgebung zu laden. In diesem Menü ist er entsprechend zu konfigurieren. Die Angaben betreffen in der Version 1.1 des JDK sowie den meisten Betaversionen des JDK 1.2 einen Firewall-Proxy oder einen HTTP-Proxy. Ab der Finalversion des JDK 1.2 können Sie nur noch einen HTTP-Proxyserver konfigurieren. Sie können jeweils einen Proxyserver und den Proxy-Port in den dafür vorgesehen Feldern eintragen. In dem Feld für den Netzwerkzugang können Sie den Netzwerktyp auswählen, auf den ein Applet im Appletviewer zugreifen darf. Sie können in den 1.1/1.2-Betaversionen wählen zwischen keinem Netzwerkzugang (None), Applet Host - also dem Host, von dem das Applet stammt - (Standardfall) und uneingeschränktem Netzwerkzugang (Unrestricted). Neuere JDK-Versionen lassen nur noch die Auswahl Restricted und Unrestricted zu. Anhand der Box für den Klassenzugang können Sie also für Ihren Appletviewer beschränkten oder uneingeschränkten Zugang zu anderen Klassen einstellen. Wenn Sie hier Eintragungen vornehmen, werden diese in einer Properties-Datei gespeichert, auf die gleich noch eingegangen wird.
Character encoding gibt den Verschlüsselungscode für die Zeichen an, die in dem Applet verwendet werden. Wenn dieser Befehl aktiviert wird, sieht man am unteren Rand die verwendete ISO-Norm der Zeichen. 8859_1 ISO Latin-1 ist üblich im deutschsprachigen Raum. Dieser Befehl ist nur in neueren Versionen des Appletviewers vorhanden, denn in JDK-Version 1.0.x war diese unterschiedliche Verschlüsselung noch nicht vorhanden.
Close schließt ein Appletfenster.
Quit schließt wie üblich das Programm und beendet damit zugleich das Applet.

Interne Arbeitsweise des Appletviewers

Wenn der Appletviewer zum ersten Mal gestartet wird, generiert er - falls nicht vorhanden - unter Windows im JDK bis Version 1.2 die Datei \.hotjava\properties bzw. unter Unix die Datei ~/.hotjava/properties. Im JDK 1.3 wurde die Datei sowohl in .appletviewer umbenannt als auch auf das Unterverzeichnis .hotjava verzichtet. Sie befindet sich jetzt im Verzeichnis C:\Windows.

Diese Datei liest das Programm bei jedem Start. Dort befinden sich die wichtigsten Sicherheitseinstellungen für das Laden fremder Applets. Dies betrifft unter anderem Schreib- und Leserechte, jedoch auch Einschränkungen der Verbindungsaufnahme von Applets. Da diese Sicherheitseinstellungen des Appletviewers gleichfalls für die Sicherheitseinstellungen eines Browsers von Bedeutung sind, ist eine etwas genauere Beschäftigung damit sicher ganz interessant. Zwar greifen wir damit dem Abschnitt über das Java-Sicherheitskonzept ein wenig vor, andererseits wird durch die praktische Anwendung im Appletviewer das Verständnis für diese Vorgänge leichter.

Die Datei könnte etwa so aussehen:

#AppletViewer
#Sun Feb 28 19:09:42 GMT+01:00 2001
package.restrict.access.sun=false
package.restrict.access.netscape=false
appletviewer.version=1.2

Oder so:

#User-specific properties for AppletViewer
#Mon Jan 29 12:26:16 GMT+00:00 2001
http.proxyPort=80
package.restrict.access.sun=false
http.proxyHost=

Bei der Generierung der Properties-Datei (erster Start des Appletviewers) werden Defaulteinstellungen für den Appletviewer in die Datei geschrieben, die so lange gelten, bis Sie diese verändern. Genaugenommen werden Sie innerhalb der Datei außer einer Datumsangabe und einer Versionsnummer des Appletviewers vorerst nicht viel finden. Sofern Sie jedoch individuelle Einstellungen für den Appletviewer vornehmen (Menüpunkt Properties), wird die Datei entsprechend gefüllt.

Soweit zu den Sicherheitseinstellungen des Appletviewers. Die konkreten Einstellungen werden von einer abstrakten Java-Klasse, die als Hintergrundprozess immer mitläuft, wenn der Appletviewer gestartet ist, überwacht. Sie heißt SecurityManager und ist schon beim Start eines Browsers automatisch aktiv. Viele Browser haben ähnliche Sicherheitseinstellungsmöglichkeiten wie der Appletviewer. In manchen Bereichen sind Browser sogar noch restriktiver, in anderen dafür freier. Mehr zur Thematik Sicherheit folgt in einem eigenen Abschnitt.

3.5.3 Der Java-Compiler Javac

Der Java-Compiler kompiliert die als Parameter angegebene(n) Datei(en) mit der Dateierweiterung .java in den Java-Bytecode mit der Erweiterung .class. Der Namensstamm der Datei wird für die Klassendatei (nicht den Dateinamen) übernommen. Es können sowohl Applets als auch Anwendungen kompiliert werden.

Java ist keine kompilierte Programmiersprache wie C oder PASCAL. Der Quellcode wird also nicht in Maschinencode kompiliert, der spezielle Prozessorbefehle für die Zielplattform enthält. Java ist jedoch auch keine vollständig interpretierte Sprache wie Basic oder Lisp. Der Java-Quellcode wird also schon in gewisser Weise übersetzt, bevor er von einem Interpreter ausgeführt wird.

Java ist statt dessen kompiliert und interpretiert und versucht damit, das Beste aus beiden Welten zu vereinen. Der Java-Compiler übersetzt den Java-Quellcode in einen Zwischencode namens Bytecode. Dieser Bytecode kann nicht direkt auf jeder Hardwareplattform ausgeführt werden. Der Code wird vielmehr vom Java-Interpreter interpretiert, der dabei eigenständig oder als Teil eines Browsers arbeiten kann. Java-Programme benötigen also immer einen Container.

Es können im Prinzip beliebig viele Dateien als Parameter für die Übersetzung angegeben werden, die jedoch alle mit der Erweiterung .java enden müssen. Javac produziert für jede Datei eine Bytecode-Datei mit gleichem Namen wie die darin enthaltenen Klassen und der Erweiterung .class. Es allerdings ist zu beachten, dass Javac nur eine public-Klasse pro Quelldatei erlaubt.

Ohne entsprechende Option erzeugt der Compiler die .class-Datei(en) in demselben Verzeichnis, in dem sich auch die Quelldateien befinden.

Falls innerhalb einer Quelldatei auf eine Klasse verwiesen wird, die nicht in der Kommandozeile mit angegeben wurde, so durchsucht der Compiler alle Verzeichnisse oder die Systemklassen mithilfe seines Suchkonzeptes. Individuell können Sie den Parameter -classpath angegeben, um weitere Verzeichnisse zu spezifizieren.

Javac-Syntax:  javac [Optionen] [Dateiname] [@files]

Beachten Sie, dass der Dateiname zwingend mit der Erweiterung .java eingegeben werden muss.

Bei neueren Versionen des Compilers kann über das Zeichen @ eine Datei angegeben werden, die selbst in jeder Zeile den Namen einer .java-Datei enthält. Damit kann verhindert werden, dass die maximale Länge der Kommandozeile überschritten wird.

Im JDK 1.3 gibt es übrigens noch das Tool oldjavac, das für einige ältere Optionen eingesetzt werden kann.

Die Optionen für den Compiler werden mit einem Minuszeichen eingeleitet und können beliebig kombiniert und angeordnet werden. Folgende Optionen gibt es:

Optionen Beschreibung

-nowrite Eine Option, um die Syntax einer Java-Datei zu testen. Der Compiler wird bei gesetzter Option zwar den Code kompilieren, aber keine Datei mit der Erweiterung .class erstellen. Damit wird auch eine eventuell bereits bestehende Datei nicht überschrieben. Diese Option wird in den neuen Versionen des JDK nicht mehr unterstützt. Im JDK 1.2 wurde sie in offiziellen Quellen schon nicht dokumentiert, hat aber noch funktioniert.

-nowarn Mit dieser Option können Sie Warnmeldungen des Compilers abstellen. Echte Fehlermeldungen werden jedoch weiter ausgegeben.

-verbose Diese Option weist den Compiler und den Linker an, während des Kompilierungsvorgangs laufend Statusinformationen über die Quelldatei anzuzeigen. Diese Information umfasst alle geladenen Klassen, die nötige Zeit in Millisekunden, um die Klassen zu laden, und auch die Gesamtzeit, die für die Kompilierung des Quellcodes in Millisekunden wahrscheinlich benötigt wird.

-sourcepath sourcepath Spezifiziert den Pfad zum Sourcecode.

-d [Verzeichnis] Diese Option weist den Compiler an, das angegebene Verzeichnis als Zielverzeichnis für eine zu erstellende .class-Datei zu verwenden. Das Verzeichnis ist als Relativangabe zu verstehen. Ohne diese Option erzeugt der Compiler die class--Datei(en) in demselben Verzeichnis, in dem sich auch die Quelldateien befinden. Alle class-Files werden in diesem Verzeichnis oder in einem da-runter liegenden Verzeichnis abgelegt - in Abhängigkeit von dem Paketnamen der jeweiligen Klassen. Falls Verzeichnisstrukturen noch nicht vorhanden sind, legt der Compiler sie an.

-classpath [Verzeichnisse] Diese Angabe teilt dem Compiler mit, in welchen Verzeichnissen nach Klassen zu suchen ist. Die Verzeichnisse werden in der Unix-Syntax durch Doppelpunkte getrennt, Windows benutzt das Semikolon. Gleichfalls ist für Pfadangaben zu beachten, dass die Komponenten eines Pfades unter Unix mittels Slash und unter Windows mittels Backslash voneinander getrennt werden. Die angegebenen Pfade werden in der Reihenfolge ihres Auftretens durchsucht.

-debug Diese Option lässt den Compiler im Debug-Modus laufen, geht den Quellcode durch und fügt Compiler-Kommentare ein. Wird ab dem JDK 1.3 nicht mehr vom Standardcompiler, sondern nur noch von oldjavac unterstützt.

-O Durch diese Option wird die bestmögliche Optimierung der Klassendateien erreicht. Die statischen, finalen und privaten Methoden werden als Inlinemethoden behandelt und beschleunigen somit die Ausführung des generierten Codes, da der gesamte Methodenkörper eingefügt wird, wo auch immer er im Programm aufgerufen wird - anstatt mehrere Aufrufe zu haben, die sich auf eine Methode beziehen. Man sagt dazu ebenfalls, dass der Code zur Laufzeit ohne den zusätzlichen Overhead eines Funktionsaufrufs erzeugt wird. Ein kleiner Nachteil der Inlinekompilierung ist, dass der erzeugte Bytecode leicht größer wird. Zusätzlich werden bei gesetztem Flag keinerlei Informationen für den Debugger generiert, was die Ausführung ebenfalls beschleunigt. Wichtiger Hinweis: Die Option -O hat seit dem JDK 1.2 eine andere Bedeutung als in den Vorgängerversionen und hat eine verschiedene Auswirkung auf den generierten Code. Außerdem schaltet die Option -O nun nicht mehr implizit die Option -depend an. Diese wird im JDK 1.3 nicht mehr unterstützt.

-deprecation Zeigt eine Beschreibung von jedem verwendeten oder überschriebenen Klassenbestandteil oder einer Klasse an, die(r) als deprecated gekennzeichnet ist. Ohne die Option wird nur der Names der Quelldatei angezeigt, die ein solches Element verwendet.

-g Diese Option bereitet den Bytecode für das Debugging vor. Das bedeutet, dass der Compiler Zeilennummern und Informationen über lokale Variablen in dem Bytecode mit angibt. Es gibt die Option auch noch mit zusätzlichen Angaben none oder einer Liste von Schlüsselworten (per Doppelpunkt angefügt).

-encoding [encoding name] Geben Sie hier den Source-Verschlüsselungsnamen (etwa EUCJIS \ SJIS) an. Wenn diese Option nicht angegeben wird, wird der defaultmäßige Converter der jeweiligen Plattform verwendet.

-depend Bewirkt eine Rekompilierung von Klassendateien, auf die die Quelldateien einen rekursiven Aufruf implementiert haben. Ohne diese Option werden nur die fehlenden oder veralteten Dateien mit direktem Aufruf erneut kompiliert. Diese Option gab es in den 1.0.x-Versionen nicht, und das JDK 1.3 entfernt sie wieder.

-target version Generiert .class-Dateien, die auf der spezifizierten JVM laufen. Defaulteinstellung ist, dass die .class-Dateien auf allen JVMs laufen sollen. Die Angabe einer niedrigen Version stellt sicher, dass die .class-Dateien sowohl auf JVMs der entsprechenden Version als auch der Folgeversionen laufen. Die Angabe einer höheren Version hingegen legt fest, dass die generierten .class-Dateien nur auf JVMs der höheren Versionen, nicht aber der Vorgängerversionen laufen.

-bootclasspath bootclasspath Setzen des Suchpfades für die Systemklassen.

-extdirs directories Setzen von Erweiterungsverzeichnissen. Jedes JAR-Archive in den angegebenen Verzeichnissen wird nach .class-Dateien durchsucht.

-JJavaoption Die in der Hilfe des 1.3-Compilers undokumentierte Option gibt den String Javaoption als ein einzelnes Argument an den Java-Interpreter weiter, der von javac aufgerufen wird. Das Argument darf keine Leerräume enthalten. Mehrere Argumente müssen jeweils mit dem Präfix -J beginnen. Dieses Präfix trennt die Argumente. Die Option ist erst seit der Version 1.1.x vorhanden. Beispiel: -J-Xms48m setzt den Startupmemory auf 48 Megabytes. Obwohl diese Option nicht mit einem -X beginnt, ist sie keine Standardoption von Javac.

Optionen	Beschreibung
-nowrite	Eine Option, um die Syntax einer Java-Datei zu testen. Der Compiler wird bei gesetzter Option zwar den Code kompilieren, aber keine Datei mit der Erweiterung .class erstellen. Damit wird auch eine eventuell bereits bestehende Datei nicht überschrieben. Diese Option wird in den neuen Versionen des JDK nicht mehr unterstützt. Im JDK 1.2 wurde sie in offiziellen Quellen schon nicht dokumentiert, hat aber noch funktioniert.
-nowarn	Mit dieser Option können Sie Warnmeldungen des Compilers abstellen. Echte Fehlermeldungen werden jedoch weiter ausgegeben.
-verbose	Diese Option weist den Compiler und den Linker an, während des Kompilierungsvorgangs laufend Statusinformationen über die Quelldatei anzuzeigen. Diese Information umfasst alle geladenen Klassen, die nötige Zeit in Millisekunden, um die Klassen zu laden, und auch die Gesamtzeit, die für die Kompilierung des Quellcodes in Millisekunden wahrscheinlich benötigt wird.
-sourcepath sourcepath	Spezifiziert den Pfad zum Sourcecode.
-d [Verzeichnis]	Diese Option weist den Compiler an, das angegebene Verzeichnis als Zielverzeichnis für eine zu erstellende .class-Datei zu verwenden. Das Verzeichnis ist als Relativangabe zu verstehen. Ohne diese Option erzeugt der Compiler die class--Datei(en) in demselben Verzeichnis, in dem sich auch die Quelldateien befinden. Alle class-Files werden in diesem Verzeichnis oder in einem da-runter liegenden Verzeichnis abgelegt - in Abhängigkeit von dem Paketnamen der jeweiligen Klassen. Falls Verzeichnisstrukturen noch nicht vorhanden sind, legt der Compiler sie an.
-classpath [Verzeichnisse]	Diese Angabe teilt dem Compiler mit, in welchen Verzeichnissen nach Klassen zu suchen ist. Die Verzeichnisse werden in der Unix-Syntax durch Doppelpunkte getrennt, Windows benutzt das Semikolon. Gleichfalls ist für Pfadangaben zu beachten, dass die Komponenten eines Pfades unter Unix mittels Slash und unter Windows mittels Backslash voneinander getrennt werden. Die angegebenen Pfade werden in der Reihenfolge ihres Auftretens durchsucht.
-debug	Diese Option lässt den Compiler im Debug-Modus laufen, geht den Quellcode durch und fügt Compiler-Kommentare ein. Wird ab dem JDK 1.3 nicht mehr vom Standardcompiler, sondern nur noch von oldjavac unterstützt.
-O	Durch diese Option wird die bestmögliche Optimierung der Klassendateien erreicht. Die statischen, finalen und privaten Methoden werden als Inlinemethoden behandelt und beschleunigen somit die Ausführung des generierten Codes, da der gesamte Methodenkörper eingefügt wird, wo auch immer er im Programm aufgerufen wird - anstatt mehrere Aufrufe zu haben, die sich auf eine Methode beziehen. Man sagt dazu ebenfalls, dass der Code zur Laufzeit ohne den zusätzlichen Overhead eines Funktionsaufrufs erzeugt wird. Ein kleiner Nachteil der Inlinekompilierung ist, dass der erzeugte Bytecode leicht größer wird. Zusätzlich werden bei gesetztem Flag keinerlei Informationen für den Debugger generiert, was die Ausführung ebenfalls beschleunigt. Wichtiger Hinweis: Die Option -O hat seit dem JDK 1.2 eine andere Bedeutung als in den Vorgängerversionen und hat eine verschiedene Auswirkung auf den generierten Code. Außerdem schaltet die Option -O nun nicht mehr implizit die Option -depend an. Diese wird im JDK 1.3 nicht mehr unterstützt.
-deprecation	Zeigt eine Beschreibung von jedem verwendeten oder überschriebenen Klassenbestandteil oder einer Klasse an, die(r) als deprecated gekennzeichnet ist. Ohne die Option wird nur der Names der Quelldatei angezeigt, die ein solches Element verwendet.
-g	Diese Option bereitet den Bytecode für das Debugging vor. Das bedeutet, dass der Compiler Zeilennummern und Informationen über lokale Variablen in dem Bytecode mit angibt. Es gibt die Option auch noch mit zusätzlichen Angaben none oder einer Liste von Schlüsselworten (per Doppelpunkt angefügt).
-encoding [encoding name]	Geben Sie hier den Source-Verschlüsselungsnamen (etwa EUCJIS \ SJIS) an. Wenn diese Option nicht angegeben wird, wird der defaultmäßige Converter der jeweiligen Plattform verwendet.
-depend	Bewirkt eine Rekompilierung von Klassendateien, auf die die Quelldateien einen rekursiven Aufruf implementiert haben. Ohne diese Option werden nur die fehlenden oder veralteten Dateien mit direktem Aufruf erneut kompiliert. Diese Option gab es in den 1.0.x-Versionen nicht, und das JDK 1.3 entfernt sie wieder.
-target version	Generiert .class-Dateien, die auf der spezifizierten JVM laufen. Defaulteinstellung ist, dass die .class-Dateien auf allen JVMs laufen sollen. Die Angabe einer niedrigen Version stellt sicher, dass die .class-Dateien sowohl auf JVMs der entsprechenden Version als auch der Folgeversionen laufen. Die Angabe einer höheren Version hingegen legt fest, dass die generierten .class-Dateien nur auf JVMs der höheren Versionen, nicht aber der Vorgängerversionen laufen.
-bootclasspath bootclasspath	Setzen des Suchpfades für die Systemklassen.
-extdirs directories	Setzen von Erweiterungsverzeichnissen. Jedes JAR-Archive in den angegebenen Verzeichnissen wird nach .class-Dateien durchsucht.
-JJavaoption	Die in der Hilfe des 1.3-Compilers undokumentierte Option gibt den String Javaoption als ein einzelnes Argument an den Java-Interpreter weiter, der von javac aufgerufen wird. Das Argument darf keine Leerräume enthalten. Mehrere Argumente müssen jeweils mit dem Präfix -J beginnen. Dieses Präfix trennt die Argumente. Die Option ist erst seit der Version 1.1.x vorhanden. Beispiel: -J-Xms48m setzt den Startupmemory auf 48 Megabytes. Obwohl diese Option nicht mit einem -X beginnt, ist sie keine Standardoption von Javac.

Tabelle 3.6: Die Optionen des Compilers

3.5.4 Der Java-Interpreter

Java ist ein Kommandozeilen-Interpreter zur Ausführung von eigenständigen Java-Anwendungen (keine Applets, dafür ist der Appletviewer zuständig). Jedes Java-Programm wird durch Klassennamen definiert. Dieser Klassenname muss dementsprechend vollständig mit dem Paketnamen der Klasse angegeben werden.

Die Syntax für den Interpreter, den es in mehreren Versionen gibt:

java [Optionen] [Klassenname] [Argumente]
java [Optionen] -jar file.jar [ argument ... ]
javaw [Optionen] [Klassenname] [Argumente]
javaw [Optionen] -jar file.jar [ argument ... ]
oldjava [Optionen] [Klassenname] [Argumente]
oldjavaw [Optionen] [Klassenname] [Argumente]

Diese sechs Versionen vom Java-Interpreter müssen ein wenig erklärt werden. Erst einmal gibt es dabei vier verschiedene Versionen des Interpreters:

java und javaw sind identisch bis auf eine Ausnahme: javaw erzeugt keine dem Befehlsaufruf folgende Ausgabe in einem Fenster (noconsole window). Die javaw-Variante des Interpreters gibt es nur unter Windows.
oldjava und oldjavaw unterscheiden sich genauso wie der normale Interpreter (auch die oldjavaw-Variante des Interpreters gibt es nur unter Windows). Ihre Hauptfunktion ist die Ausführung von Applikationen, 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 mit dem normalen Interpreter java eine Exception auswerfen und nicht starten. Auch sonstiger alter Java-Code kann unter Umständen damit ausgeführt werden, wenn der normale Interpreter damit nicht zurechtkommt.

Es gibt einige spezifische Unterschiede zwischen java und oldjava. oldjava unterstützt nicht den Extension-Mechanismus. Weiterhin nutzt oldjava den bootstrap-Classloader für alle Klassen, während java diesen nur für Systemklassen nutzt. Unter dem neuen java des JDK 1.2 spezifizieren die Optionen -classpath und -cp nur einen Suchpfad für anwenderdefinierte bzw. Nichtsystem-Klassen. Die Optionen können nicht dafür verwendet werden, solche bootstrap-Klassen zu lokalisieren. oldjava verwendet diese Optionen (wie auch früher java selbst), um alle Klassen zu lokalisieren. Dabei gilt es zu beachten, dass sich java und oldjava nicht in der Verwendung der Umgebungsvariablen CLASSPATH unterscheiden (ein entscheidender Unterschied zwischen dem alten java und oldjava). Bis die Variable durch -classpath oder -cp überschrieben wird, spezifiziert CLASSPATH immer den Ort, wo die anwenderdefinierten Klassen zu finden sind (aber nicht, wo die bootstrap Klassen sind). Obwohl oldjava im Wesentlichen zur Unterstützung von älterem Javasource gedacht ist, werden von ihm alle aktuellen Securityfeatures unterstützt.

Ansonsten ist bei allen Syntaxangaben zu beachten, dass Optionen für den Interpreter diverse Übergabewerte sind und Klassenname der Name der auszuführenden Klasse. Defaulteinstellung ist, dass das erste Argument, das keine Option ist, von dem Interpreter als Name der Klasse interpretiert wird.

Unbedingt zu beachten ist, dass beim Klassenname nicht nur die .class-Erweiterung nicht eingegeben werden muss, sondern sogar gar nicht darf. Dies ist deshalb eine häufige Fehlerquelle, weil es von der Syntaxlogik dem Compiler widerspricht, wo explizit die Erweiterung einzugeben ist.

Wichtig ist, dass die Komponenten von Paket- und Klassennamen durch Punkt und nicht durch Slash oder Backslash getrennt werden.

Die optionale Angabe file.jar ist der Name der .jar-Datei, die ausgeführt werden soll. Diese Anweisung kann nur in Verbindung mit der vorangestellten Angabe -jar verwendet werden.

Argumente bezeichnen den oder die an die main()-Methode weitergegebene(n) Übergabewert(e). Jede Klasse, die in dem Aufruf durch den Klassenname spezifiziert wird, benötigt eine Methode namens public static void main(String argv[]). Sämtliche Argumente, die hinter dem Parameter Klassenname stehen, werden an die Methode main() in gleicher Reihenfolge übergeben, wenn java aufgerufen wird. Wenn mit main() Threads erzeugt werden, so läuft der Interpreter so lange, bis der letzte Thread beendet wird. Ansonsten endet java nach der vollständigen Abarbeitung von main(). Eventuell benötigte weitere Klassen werden automatisch geladen. Die nachzuladenden Klassen müssen sich allerdings im selben Verzeichnis oder im Zugriffspfad befinden. In ehemaligen Java-Versionen vorhandene Bugs konnten diese Restriktion zwar aushebeln, aber dies soll hier keine Rolle spielen.

Der Java-Interpreter hat bereits einige wichtige Sicherheitsvorkehrungen eingebaut. Diese gehören zum zentralen Sicherheitskonzept der Sprache. So überprüft der Java-Interpreter standardmäßig jede Klasse während des Ladevorgangs. Die Klassen werden diversen Verifizierungen unterzogen. Darunter fällt auch ein Virentest. Durch einzelne folgende Parameter können die Verifizierungen ausgelöst, aber auch eingeschränkt werden, was die Programmausführung natürlich beschleunigt.

Bei den Optionen zeigen sich ganz massive Veränderungen zwischen den Interpreter-Version des JDK 1.1 und 1.2 (Beta) auf der einen Seite sowie Folgeversionen auf der anderen Seite. Die Standardoptionen des Interpreters wurden erheblich reduziert und viele Optionen, die früher dazu zählten, werden entweder nicht mehr unterstützt oder nur noch als Non-Standard-Optionen geführt.

Optionen Beschreibung

-classpath [Verzeichnis] -cp Diese Angabe korrespondiert wie bereits beim Compiler mit der gleichnamigen Umgebungsvariable und teilt dem den Interpreter mit, in welchen Verzeichnissen, JAR-Archiven und ZIP-Archiven nach .class-Dateien zu suchen ist. In Verbindung mit java oder javaw werden nur anwenderdefinierte Klassen spezifiziert, in Verbindung mit oldjava oder oldjavaw alle Klassen. Die Verzeichnisse werden in der Unix-Syntax durch Doppelpunkte getrennt, Windows benutzt das Semikolon. Auch ist für Pfad-angaben zu beachten, dass die Komponenten eines Pfades unter Unix mittels Slash und unter Windows mittels Backslash voneinander getrennt werden. Die angegebenen Pfade werden in der Reihenfolge ihres Auftretens durchsucht.

-help -? Wie sehr oft üblich, kann mit diesen gleichwertigen Optionen eine Ausgabe sämtlicher Optionen erzwungen werden.

-version -showversion Diese Optionen veranlasen den Interpreter, die Version des JDK anzuzeigen. Sie können diese Option auch ohne .class-Datei verwenden. Unterschied zwischen beiden Varianten ist, dass -version den Programmablauf abbricht, während -showversion das Programm startet.

-verbose -v Diese Option weist den Interpreter an, während des Ladevorgangs laufend Statusinformationen über die Klassen anzuzeigen (jedes Mal, wenn eine neue Klasse geladen wird). Es gibt die folgenden Spezialfälle: -verbose:class - Anzeige jeder geladenen Klasse. -verbose:gc - Anzeige jedes Garbage collection-Events. Diese Option weist den Interpreter an, jedes Mal eine Meldung auf dem Bildschirm auszugeben, wenn es zu einer Speicherbereinigung durch die Garbage Collection kommt. -verbose:jni - Anzeige über die Verwendung von nativen Methoden und andere JNI-Aktivitäten.

-[DpropertyName] = [NeuerWert] Es gibt im Prinzip die Möglichkeit, selbst definierte Systemeigenschaften an ein interpretierendes Java-Programm zu übergeben, indem beliebige Eigenschaften und Werte als Optionen mit einem Minuszeichen und D abgetrennt an den Aufruf angehängt werden. Das Java-Programm muss natürlich diese Parameter verwenden können. propertyName ist der Name der Eigenschaft, deren Wert Sie verändern wollen und NeuerWert ist der geänderte Wert der Eigenschaft. Beispiel: % java -Dawt.button.color=red ... setzt den Wert der Eigenschaft awt.button.color auf red (rot) - das Prozentzeichen ist UNIX-Syntax. java akzeptiert im Prinzip eine beliebige Anzahl von -D-Optionen in der Befehlszeile.

-jar Führt ein Programm aus, das in ein JAR-Archiv verpackt ist. Das erste nachfolgende Argument ist der Name von einen JAR-Archiv (anstelle eines Klassennames). oldjava und oldjavaw verstehen diese Option nicht.

-X Anzeige der nicht-standard-Optionen.

Optionen	Beschreibung
-classpath [Verzeichnis] -cp	Diese Angabe korrespondiert wie bereits beim Compiler mit der gleichnamigen Umgebungsvariable und teilt dem den Interpreter mit, in welchen Verzeichnissen, JAR-Archiven und ZIP-Archiven nach .class-Dateien zu suchen ist. In Verbindung mit java oder javaw werden nur anwenderdefinierte Klassen spezifiziert, in Verbindung mit oldjava oder oldjavaw alle Klassen. Die Verzeichnisse werden in der Unix-Syntax durch Doppelpunkte getrennt, Windows benutzt das Semikolon. Auch ist für Pfad-angaben zu beachten, dass die Komponenten eines Pfades unter Unix mittels Slash und unter Windows mittels Backslash voneinander getrennt werden. Die angegebenen Pfade werden in der Reihenfolge ihres Auftretens durchsucht.
-help -?	Wie sehr oft üblich, kann mit diesen gleichwertigen Optionen eine Ausgabe sämtlicher Optionen erzwungen werden.
-version -showversion	Diese Optionen veranlasen den Interpreter, die Version des JDK anzuzeigen. Sie können diese Option auch ohne .class-Datei verwenden. Unterschied zwischen beiden Varianten ist, dass -version den Programmablauf abbricht, während -showversion das Programm startet.
-verbose -v	Diese Option weist den Interpreter an, während des Ladevorgangs laufend Statusinformationen über die Klassen anzuzeigen (jedes Mal, wenn eine neue Klasse geladen wird). Es gibt die folgenden Spezialfälle: -verbose:class - Anzeige jeder geladenen Klasse. -verbose:gc - Anzeige jedes Garbage collection-Events. Diese Option weist den Interpreter an, jedes Mal eine Meldung auf dem Bildschirm auszugeben, wenn es zu einer Speicherbereinigung durch die Garbage Collection kommt. -verbose:jni - Anzeige über die Verwendung von nativen Methoden und andere JNI-Aktivitäten.
-[DpropertyName] = [NeuerWert]	Es gibt im Prinzip die Möglichkeit, selbst definierte Systemeigenschaften an ein interpretierendes Java-Programm zu übergeben, indem beliebige Eigenschaften und Werte als Optionen mit einem Minuszeichen und D abgetrennt an den Aufruf angehängt werden. Das Java-Programm muss natürlich diese Parameter verwenden können. propertyName ist der Name der Eigenschaft, deren Wert Sie verändern wollen und NeuerWert ist der geänderte Wert der Eigenschaft. Beispiel: % java -Dawt.button.color=red ... setzt den Wert der Eigenschaft awt.button.color auf red (rot) - das Prozentzeichen ist UNIX-Syntax. java akzeptiert im Prinzip eine beliebige Anzahl von -D-Optionen in der Befehlszeile.
-jar	Führt ein Programm aus, das in ein JAR-Archiv verpackt ist. Das erste nachfolgende Argument ist der Name von einen JAR-Archiv (anstelle eines Klassennames). oldjava und oldjavaw verstehen diese Option nicht.
-X	Anzeige der nicht-standard-Optionen.

Tabelle 3.7: Die Standardoptionen des Interpreters

Neben den Standardoptionen des Interpreters gibt es zahlreiche Non-Standard-Optionen:

Optionen Beschreibung

-Xbootclasspath:bootclasspath Spezifiziert einen durch Trennzeichen getrennte Suchpfad von Verzeichnissen, JAR-Archiven und ZIP-Archiven.

-Xnoclassgc Diese Option (entspricht der in früheren Versionen verwendeten Option -noasyncgc, die nicht mehr unterstützt wird) unterbindet das asynchrone Ausführen der Garbage Collection. Die Folge ist, dass dieser nur dann ausgeführt wird, wenn er explizit im Programm aufgerufen wird (System.gc()) oder wenn der zu Verfügung stehende Speicherplatz zu gering wird. Wenn diese Option nicht gesetzt ist, verfolgt die Laufzeitumgebung alle Referenzen auf ein Objekt in dem Heap nach und gibt automatisch den Speicher frei, der von Objekten belegt wird, die nicht mehr länger referenziert werden. Dies geschieht, sobald die CPU dafür Kapazität frei hat und läuft als permanenter, paralleler Hintergrundthread mit geringer Priorität ab.

-Xmx [MaximalMemory] Mit dieser Option (früher nur -mx) stellt man die maximale Größe des Heap-Speichers ein. MaximalMemory ist der maximale Wert in Bytes, den der Interpreter für dynamisch allokierte Objekte und Arrays nutzen kann. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist jedoch die Einheit Byte. Die minimale Heap-Größe ist ein Kilobyte (-Xmx 1k), die Standardgröße des maximalen Heaps liegt bei 16 Megabyte (-Xmx 16m).

-Xms [Memory] Diese Option (früher nur -ms) stellt die anfängliche Heap-Größe ein, wenn der Interpreter startet. Memory ist die Angabe in Bytes, die bestimmt, wie viel Speicher der Interpreter allokieren soll. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist jedoch die Einheit Byte. Die minimale Heap-Größe ist ein Kilobyte (-ms 1k), die Standardgröße des anfänglichen Heaps ist 1 Megabyte (-Xms 1m) und wird immer dann genommen, wenn der Parameter nicht angegeben wird. Bei großen Java-Programmen sollte die anfängliche Heap-Größe erweitert werden, um die Performance zu verbessern.

-Xdebug Diese Option (früher nur -debug) veranlasst den Interpreter ein Passwort zu erzeugen, nachdem er gestartet wurde. Es wird auf dem Bildschirm angezeigt und kann in der Passwortoption (-password) des Debuggers jdb verwendet werden, um sich nachträglich in die Sitzung einzuklinken (Remote-Zugriff).

-Xrunhprof[:help][:<option>=
<value>,...] Erlaubt die Beobachtung von dem Prozessor, dem Heap oder Monitor.

-Xmixed Mixedmode-Ausführung.

-Xint Nur interpretierte Ausführung.

Optionen	Beschreibung
-Xbootclasspath:bootclasspath	Spezifiziert einen durch Trennzeichen getrennte Suchpfad von Verzeichnissen, JAR-Archiven und ZIP-Archiven.
-Xnoclassgc	Diese Option (entspricht der in früheren Versionen verwendeten Option -noasyncgc, die nicht mehr unterstützt wird) unterbindet das asynchrone Ausführen der Garbage Collection. Die Folge ist, dass dieser nur dann ausgeführt wird, wenn er explizit im Programm aufgerufen wird (System.gc()) oder wenn der zu Verfügung stehende Speicherplatz zu gering wird. Wenn diese Option nicht gesetzt ist, verfolgt die Laufzeitumgebung alle Referenzen auf ein Objekt in dem Heap nach und gibt automatisch den Speicher frei, der von Objekten belegt wird, die nicht mehr länger referenziert werden. Dies geschieht, sobald die CPU dafür Kapazität frei hat und läuft als permanenter, paralleler Hintergrundthread mit geringer Priorität ab.
-Xmx [MaximalMemory]	Mit dieser Option (früher nur -mx) stellt man die maximale Größe des Heap-Speichers ein. MaximalMemory ist der maximale Wert in Bytes, den der Interpreter für dynamisch allokierte Objekte und Arrays nutzen kann. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist jedoch die Einheit Byte. Die minimale Heap-Größe ist ein Kilobyte (-Xmx 1k), die Standardgröße des maximalen Heaps liegt bei 16 Megabyte (-Xmx 16m).
-Xms [Memory]	Diese Option (früher nur -ms) stellt die anfängliche Heap-Größe ein, wenn der Interpreter startet. Memory ist die Angabe in Bytes, die bestimmt, wie viel Speicher der Interpreter allokieren soll. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist jedoch die Einheit Byte. Die minimale Heap-Größe ist ein Kilobyte (-ms 1k), die Standardgröße des anfänglichen Heaps ist 1 Megabyte (-Xms 1m) und wird immer dann genommen, wenn der Parameter nicht angegeben wird. Bei großen Java-Programmen sollte die anfängliche Heap-Größe erweitert werden, um die Performance zu verbessern.
-Xdebug	Diese Option (früher nur -debug) veranlasst den Interpreter ein Passwort zu erzeugen, nachdem er gestartet wurde. Es wird auf dem Bildschirm angezeigt und kann in der Passwortoption (-password) des Debuggers jdb verwendet werden, um sich nachträglich in die Sitzung einzuklinken (Remote-Zugriff).
-Xrunhprof[:help][:<option>= <value>,...]	Erlaubt die Beobachtung von dem Prozessor, dem Heap oder Monitor.
-Xmixed	Mixedmode-Ausführung.
-Xint	Nur interpretierte Ausführung.

Tabelle 3.8: Die Nicht-Standardoptionen des Interpreters

Es gab über die zahlreichen Varianten des JDK diverse Interpreter-Optionen, die mittlerweile nicht mehr dokumentiert werden. Diese werden aber teilweise immer noch unterstützt und sind natürlich dann interessant, wenn Sie mit einem älteren Interpreter arbeiten.

Die nicht mehr unter dem JDK 1.3 dokumentierten Optionen:

Optionen Beschreibung

-Xrs Reduziert Systemsignale.

-Xcheck:jni Zusätzliche Checks für Java Native Interface-Funktionen.

Optionen	Beschreibung
-Xrs	Reduziert Systemsignale.
-Xcheck:jni	Zusätzliche Checks für Java Native Interface-Funktionen.

Tabelle 3.9: Die zusätzlichen Nicht-Standardoptionen des Interpreters 1.2

Optionen Beschreibung

-verify Wenn diese Option gesetzt ist, wird der Bytecode-Verifizierer des Java-Interpreters jedes Mal ausgeführt, sobald eine neue Klassen geladen wird. Diese Klasse wird damit explizit überprüft (Defaulteinstellung). Die Option wird an verschiedenen Stellen der JDK-Dokumentation auch als Nicht-Standardoption -Xverify geführt. Da ist die Dokumentation leider nicht einheitlich. Manche Interpreter-Versionen führen beide Varianten ohne Fehlermeldung aus.

-noverify Diese Option stellt die Verifizierung der Klassen durch den Bytecode-Verifizierer ab.

-verifyremote Diese Option weist den Interpreter an, Klassen, die über den Classloader geladen werden (und nur diese), mit dem Bytecode-Verifizierer zu überprüfen. Dies sind im Allgemeinen Klassen, die von einem fremden Host über das Netz importiert oder vererbt worden sind.

-ss [StackGröße] Dieser Parameter legt den Wert für die Stack-Größe eines Threads für einen C-Prozess (Native Code) fest. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist jedoch wie bei den anderen Optionen die Einheit Byte. Die Stack-Größe muss mehr als 1 Kilobyte (-ss 1k) betragen. Standardwert ist 128 Kilobyte.

-oss [StackGröße] Dieser Parameter legt den Wert für die Stack-Größe eines Java-Threads fest. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist wie bei den anderen Optionen die Einheit Byte. Die Stack-Größe muss mehr als 1 Kilobyte (-oss 1k) betragen. Standardwert ist 400 Kilobyte.

Optionen	Beschreibung
-verify	Wenn diese Option gesetzt ist, wird der Bytecode-Verifizierer des Java-Interpreters jedes Mal ausgeführt, sobald eine neue Klassen geladen wird. Diese Klasse wird damit explizit überprüft (Defaulteinstellung). Die Option wird an verschiedenen Stellen der JDK-Dokumentation auch als Nicht-Standardoption -Xverify geführt. Da ist die Dokumentation leider nicht einheitlich. Manche Interpreter-Versionen führen beide Varianten ohne Fehlermeldung aus.
-noverify	Diese Option stellt die Verifizierung der Klassen durch den Bytecode-Verifizierer ab.
-verifyremote	Diese Option weist den Interpreter an, Klassen, die über den Classloader geladen werden (und nur diese), mit dem Bytecode-Verifizierer zu überprüfen. Dies sind im Allgemeinen Klassen, die von einem fremden Host über das Netz importiert oder vererbt worden sind.
-ss [StackGröße]	Dieser Parameter legt den Wert für die Stack-Größe eines Threads für einen C-Prozess (Native Code) fest. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist jedoch wie bei den anderen Optionen die Einheit Byte. Die Stack-Größe muss mehr als 1 Kilobyte (-ss 1k) betragen. Standardwert ist 128 Kilobyte.
-oss [StackGröße]	Dieser Parameter legt den Wert für die Stack-Größe eines Java-Threads fest. Die Größenangabe kann auch in Kilobyte (k an die Zahl angehängt) oder in Megabyte (m an die Zahl angehängt) erfolgen. Voreinstellung ist wie bei den anderen Optionen die Einheit Byte. Die Stack-Größe muss mehr als 1 Kilobyte (-oss 1k) betragen. Standardwert ist 400 Kilobyte.

Tabelle 3.10: Die nicht mehr unter dem JDK 1.2 dokumentierten Optionen

Es gibt auch einige Optionen, die in neuen Versionen des JDK effektiv keinen Sinn haben, da dort die entsprechenden Tools nicht mehr vorhanden sind. In den früheren JDKs sind sie aber von Interesse.

Optionen Beschreibung

-prof Anhand dieser Option wird der Interpreter angewiesen, so genannte Profilinformationen in die Datei \java.prof (Defaulteinstellung) auszugeben. Die Option funktioniert nur mit java_g und javaw_g.

-prof:[Datei] Anhand dieser Option wird der Interpreter angewiesen, so genannte Profilinformation alternativ in eine sellbst definierte Datei auszugeben. Die Option funktioniert nur mit java_g und javaw_g.

-t Gibt eine Spur der abgearbeiteten Anweisungen aus. Die Option funktioniert nur mit java_g und javaw_g und ist erst in der Version 1.1.x eingeführt worden.

Optionen	Beschreibung
-prof	Anhand dieser Option wird der Interpreter angewiesen, so genannte Profilinformationen in die Datei \java.prof (Defaulteinstellung) auszugeben. Die Option funktioniert nur mit java_g und javaw_g.
-prof:[Datei]	Anhand dieser Option wird der Interpreter angewiesen, so genannte Profilinformation alternativ in eine sellbst definierte Datei auszugeben. Die Option funktioniert nur mit java_g und javaw_g.
-t	Gibt eine Spur der abgearbeiteten Anweisungen aus. Die Option funktioniert nur mit java_g und javaw_g und ist erst in der Version 1.1.x eingeführt worden.

Tabelle 3.11: Optionen des Interpreters vor 1.2

3.6 Zusammenfassung

Wenn Sie in Java programmieren wollen, wird das JDK die Basis sein, auch wenn Sie auf ergänzende Tools umsteigen. Diese nutzen das JDK meist direkt. Das kostenlos von Sun bereitgestellte JDK beinhaltet eine Vielzahl von Tools, von denen der Compiler, der Interpreter und der Appeltviewer die wichtigsten sind. Die zusätzlich von Sun bereitgestellte Online-Dokumentation ist eine nahezu unumgängliche Basis zum Nachschlagen von Details zu Java oder den JDK-Tools.

natürlich 42, aber darum geht es hier nicht ;-)

Damit soll diversen Problemen begegnet werden, die beim bisherigen Konzept auftauchten.

© Copyright Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH
Elektronische Fassung des Titels: Java 2 Kompendium, ISBN: 3-8272-6039-6 Kapitel: 3 Das JDK