Anmerkung: Vor Verwendung dieser Informationen und des dazugehörigen Produkts sollten Sie die allgemeinen Informationen im Abschnitt Bemerkungen lesen.
Diese Ausgabe des Benutzerhandbuchs bezieht sich auf IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 und auf alle nachfolgenden Releases, Änderungen und Serviceaktualisierungen bis zur Herausgabe neuer Dateiversionen.
(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Alle Rechte vorbehalten.
(c) Copyright International Business Machines Corporation, 1999, 2005. Alle Rechte vorbehalten.
(c) Copyright IBM Deutschland GmbH 1999, 2004. Alle Rechte vorbehalten.
In diesem Benutzerhandbuch erhalten Sie allgemeine Informationen zu IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) 2 Technology Edition, Version 5.0 sowie spezielle Informationen zu allen Unterschieden zwischen der IBM Implementierung und der Sun-Implementierung. Lesen Sie dieses Benutzerhandbuch zusammen mit der ausführlicheren Dokumentation auf der folgenden Website von Sun Microsystems: http://java.sun.com.
SDK und Runtime Environment werden unter folgenden Betriebssystemen unterstützt:
Beachten Sie, dass IP Version 6 nur unter Windows XP und Windows Server 2003 unterstützt wird.
Das Handbuch Diagnostics Guide enthält weitere Informationen zu IBM Virtual Machine für Java.
Technische Änderungen, die in diesem Benutzerhandbuch zu Version 5.0 enthalten sind, mit Ausnahme von unwichtigen oder offensichtlichen Änderungen, wie beispielsweise die Aktualisierung von "1.4.2" in "5.0", sind rot dargestellt, wenn sie als HTML-Datei angezeigt oder als Farbkopie ausgedruckt werden. Außerdem wird durch vertikale Balken am linken Rand auf diese Änderungen hingewiesen.
Die Begriffe "Runtime Environment" und "Java Virtual Machine" sind in diesem Handbuch gleichbedeutend.
Bei IBM SDK handelt es sich um eine Entwicklungsumgebung zum Schreiben und Ausführen von Applets und Anwendungen, die der IBM Java 5.0 Core-API (Application Programming Interface - Anwendungsprogrammierschnittstelle) entsprechen.
SDK umfasst Runtime Environment for Windows. Mit dieser Komponente können Sie nur Java-Anwendungen ausführen. Wenn Sie SDK installiert haben, ist auch Runtime Environment enthalten.
Runtime Environment enthält Java Virtual Machine sowie unterstützende Dateien, wie z. B. Klassendateien. Runtime Environment enthält nur eine Untergruppe der Klassen, die in SDK enthalten sind. Mit dieser Komponente können Sie ein Java-Programm in der Laufzeit verwenden, jedoch keine Java-Programme kompilieren. Runtime Environment for Windows enthält kein Entwicklungstool, wie z. B. appletviewer.exe oder den Java-Compiler (javac.exe), bzw. keine Klassen, die nur für Entwicklungssysteme konzipiert sind.
Außerdem wird das Paket mit der Java Communications API zur Verwendung mit Runtime Environment for Windows bereitgestellt. Informationen hierzu finden Sie unter Verwenden der Java Communications API (JavaComm).
Normalerweise müssten alle Applets oder Anwendungen, die mit einer Vorversion von SDK ausgeführt wurden, zusammen mit IBM 32-bit SDK for Windows, v5.0 ordnungsgemäß ausgeführt werden. Es ist nicht gewährleistet, dass Klassen, die auf der Grundlage dieses Releases kompiliert wurden, zusammen mit früheren Releases eingesetzt werden können.
|IBM 32-bit SDK for Windows V5.0 basiert auf |Microsoft Visual Studio .NET 2003.
Die Sun-Dokumentation zur Kompatibilität finden Sie auf der Sun-Website unter http://java.sun.com.
Wenn Sie ein Upgrade von einem früheren SDK-Release ausführen, sichern Sie alle Konfigurations- und Sicherheitsrichtliniendateien, bevor Sie mit dem Ausführen des Upgrades fortfahren.
Nach dem Ausführen des Upgrades müssen Sie diese Dateien eventuell wiederherstellen oder neu konfigurieren, da sie beim Upgradeprozess möglicherweise überschrieben wurden. Prüfen Sie die Syntax der neuen Dateien, bevor Sie die ursprünglichen Dateien wiederherstellen, da sich das Format oder die Optionen für die Dateien geändert haben können.
In Version 5.0 enthält IBM Runtime Environment for Windows neue Versionen von IBM Java Virtual Machine und des JIT-Compilers (Just-In-Time). Wenn Sie von einer älteren IBM Runtime Environment-Version migrieren, beachten Sie Folgendes:
SDK enthält mehrere Entwicklungstools und Java Runtime Environment (JRE). Dieser Abschnitt enthält Erläuterungen zum Inhalt der SDK-Tools und von Runtime Environment.
Anwendungen, die vollständig in Java geschrieben sind, sollten keine Abhängigkeiten von der IBM SDK-Verzeichnisstruktur (oder Dateien in diesen Verzeichnissen) aufweisen. Abhängigkeiten von der SDK-Verzeichnisstruktur (oder den Dateien in diesen Verzeichnissen) können zu Fehlern bei der Portierbarkeit von Anwendungen führen. JNI-Anwendungen (Java Native Interface) weisen geringfügige Abhängigkeiten auf.
Anmerkung: SDK for Windows enthält lediglich die Benutzerhandbücher, die Javadoc-Komponente und die zugehörige Lizenz, die zugehörigen Copyrightdateien sowie das Demoverzeichnis. Sie können die Sun-Softwaredokumentation über die Sun-Website aufrufen oder das Dokumentationspaket zur Sun-Software über die Sun-Website herunterladen: http://java.sun.com.
Laden Sie zum Installieren des SDK- oder Runtime Environment-Pakets das entsprechende Installationspaket herunter. Stellen Sie sicher, dass Sie alle Pakete in dasselbe Verzeichnis herunterladen. Die Pakete und die zugehörigen Dateinamen sind im Abschnitt Überwachte (interaktive) Installation aufgeführt. Sie dürfen die Dateinamen der Pakete nicht ändern.
Stellen Sie vor dem Start der Installation sicher, dass im Verzeichnis C:\WINDOWS\TEMP genügend Speicherplatz für die Installation zur Verfügung steht. Während der Installation wird im Verzeichnis TEMP der folgende temporäre Speicherplatz benötigt:
Wenn nicht genügend temporärer Speicherplatz zur Verfügung steht, zeigt das Installationsprogramm einen Fehler an, und die Installation wird beendet. Wenn Ihr System über genügend temporären Speicherplatz verfügt, diese Nachricht jedoch weiterhin angezeigt wird, prüfen Sie, ob die Pakete, die Sie installieren wollen, vollständig heruntergeladen wurden. Dies ist möglich, indem Sie die Dateigröße des Pakets mit der Dateigröße vergleichen, die auf den Webseiten angezeigt wird, über die Sie das Paket heruntergeladen haben.
Sie können die folgenden Pakete installieren:
Andere Pakete werden als ZIP-Dateien zur Verfügung gestellt:
Runtime Environment wird standardmäßig im Verzeichnis C:\Programme\IBM\Java50\jre installiert.
Wenn Sie das installierbare SDK-Paket heruntergeladen haben, können Sie auswählen, welche Komponente installiert werden soll:
Sie können die Komponenten einzeln oder kombiniert installieren.
Im Installationsassistenten werden folgende Optionen angezeigt:
Bei der Installation von Runtime Environment (entweder als Teil des installierbaren SDK-Pakets oder aus dem installierbaren Runtime Environment-Paket) werden Sie gefragt, ob Sie Runtime Environment als System-JVM (Java Virtual Machine) installieren wollen. Soll die Installation als System-JVM erfolgen, kopiert das Installationsprogramm die Dateien java.exe und javaw.exe in das Windows-Systemverzeichnis. Wenn eine Version von java.exe oder javaw.exe bereits im Windows-Systemverzeichnis vorhanden ist, werden Sie gefragt, ob die vorhandene Version mit der aktuellen Version überschrieben werden soll. Beim Installieren dieser Dateien in dem Windows-Systemverzeichnis wird diese Version von Runtime Environment zur Standard-JVM des Systems. Außerdem wird der Registrierungsschlüssel "Current Version" dieser Installation entsprechend festgelegt.
Wenn Sie eine nicht überwachte Installation erstellen wollen, müssen Sie zunächst eine nicht überwachte Installation vollständig ausführen und eine Antwortdatei (setup.iss) erstellen, in der die Optionen aufgeführt sind, die Sie während der Installation ausgewählt haben. Die Antwortdatei muss für die Computer, auf denen sie verwendet werden soll, ordnungsgemäß erstellt werden. Erstellen Sie gegebenenfalls mehrere Antwortdateien, die zum Installieren der Pakete auf Computern mit unterschiedlichen Konfigurationen verwendet werden können.
Wenn Sie während der Installation eine Antwortdatei erstellen wollen, geben Sie Folgendes an einer Eingabeaufforderung ein:
ibm-java2-sdk-50-win-i386 /r
oder
ibm-java2-jre-50-win-i386 /r
Je nach dem verwendeten Windows-Produkt wird eine Antwortdatei (setup.iss) entweder im Verzeichnis C:\Windows oder C:\Winnt erstellt. Dabei ist C: das Bootlaufwerk.
Während einer interaktiven Installation wird möglicherweise folgende Nachricht angezeigt:
Eine andere Version von Java Runtime Environment ist momentan als System-JVM installiert. Wollen Sie die vorige System-JVM mit dieser JRE-Version überschreiben?
Wenn diese Nachricht angezeigt wird, wählen Sie Nein aus, und beenden Sie die Installation. Wechseln Sie in das Windows-Systemverzeichnis, und löschen Sie die beiden folgenden Dateien:
Nachdem Sie die Dateien gelöscht haben, starten Sie die interaktive Installation erneut mit dem oben aufgeführten Befehl.
Kopieren Sie auf dem System, auf dem Sie die nicht überwachte Installation ausführen wollen, die Antwortdatei setup.iss in das Verzeichnis C:\Windows. Nachdem Sie die Datei kopiert haben, geben Sie Folgendes an einer Eingabeaufforderung ein:
ibm-java2-sdk-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java2-jre-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Wenn die Installation erfolgreich durchgeführt wurde, enthält die Protokolldatei die Zeichenfolge ResultCode=0.
IBM Accessibility Bridge wird installiert, ist jedoch standardmäßig inaktiviert. Wenn Sie IBM Accessibility Bridge aktivieren wollen, löschen Sie das Nummernzeichen, das sich am Anfang der folgenden Zeile in der Datei Accessibility.properties im Verzeichnis jre/lib befindet:
#assistive_technologies=JawBridge
Auf der folgenden Website finden Sie weitere Informationen zu den Accessibility-Dienstprogrammen:
http://java.sun.com/products/jfc/accessibility.html
Sie können die Unterstützung von Java Accessibility inaktivieren, um die JVM-Ladeleistung der Java-Anwendungen zu verbessern, die keine Unterstützung der Java-Technologie für behindertengerechte Bedienung insbesondere über Netzverbindungen bieten.
Wenn Sie die Unterstützung von Java Accessibility inaktivieren wollen, setzen Sie den Wert für die Umgebungsvariable JAVA_ASSISTIVE auf OFF. Technologie für behindertengerechte Bedienung, wie z. B. JawBridge, ist nicht verfügbar, wenn für diese Umgebungsvariable OFF angegeben ist, obwohl die Technologie in der Datei Accessibility.properties aktiviert ist.
Unter Windows weist ein Prozess zwei Codepages auf: die ANSI- (oder Windows-)Codepage und die OEM- (oder DOS-)Codepage.
Das Befehlsfenster verwendet normalerweise die OEM-Codepage. In der Java-Konsolausgabe wird die Codepage des Befehlsfensters verwendet, über das Java gestartet wird. Für den Befehl javaw wird jedoch immer die ANSI-Codepage verwendet. Sie können die Codepage, die für die Konsolausgabe verwendet werden soll, mit der Option -Dconsole.encoding im Befehl java angeben. Beispielsweise wird mit -Dconsole.encoding=Cp1252 angegeben, dass für alle Konsolausgaben die Codepage Windows ANSI Latin1 (1252) verwendet werden soll.
Beachten Sie, dass alle vorhandenen ausführbaren Java-Dateien in dem von Ihnen verwendeten Pfad überschrieben werden, wenn Sie die Umgebungsvariable PATH wie unten beschrieben ändern.
Nach der Installation von SDK können Sie ein Tool ausführen, indem Sie an einer Eingabeaufforderung den Namen des Tools zusammen mit einem Dateinamen als Argument eingeben.
Geben Sie den Pfad für ein Tool immer so an, dass der Pfad vor dem Toolnamen steht. Wenn beispielsweise SDK for Windows im Verzeichnis C:\Programme\IBM\Java50\bin installiert ist, können Sie eine Datei mit dem Namen MeineDatei.java kompilieren, indem Sie Folgendes an einer Eingabeaufforderung eingeben:
"C:\Programme\IBM\Java50\bin\javac" MeineDatei.java
Gehen Sie wie folgt vor, um nicht jedesmal den vollständigen Pfad eingeben zu müssen:
Wenn SDK oder Runtime Environment in einem anderen Verzeichnis installiert sind, ersetzen Sie C:\Programme\IBM\Java50\ durch das Verzeichnis, in dem SDK oder Runtime Environment installiert sind.
javac MeineDatei.java
Mit der Umgebungsvariablen PATH können unter Windows ausführbare Dateien, wie z. B. javac, java und javadoc, in allen aktuellen Verzeichnissen gesucht werden. Geben Sie zum Anzeigen des aktuellen Werts der Umgebungsvariablen PATH Folgendes an einer Eingabeaufforderung ein:
echo %PATH%
Die Umgebungsvariable CLASSPATH teilt den SDK-Tools (z. B. java, javac und javadoc) die Speicherposition der Java-Klassenbibliotheken mit.
Sie müssen die Umgebungsvariable CLASSPATH nur festlegen, wenn eine der folgenden Aussagen zutrifft:
Geben Sie zum Anzeigen des aktuellen Werts der Umgebungsvariablen CLASSPATH Folgendes an einer Eingabeaufforderung ein:
echo %CLASSPATH%
Wenn Sie Anwendungen entwickeln und ausführen wollen, die unterschiedliche Laufzeitumgebungen verwenden, wie z. B. andere Versionen, die separat installiert wurden, müssen Sie CLASSPATH (und PATH) für jede Anwendung explizit festlegen. Wenn Sie mehrere Anwendungen gleichzeitig ausführen und unterschiedliche Laufzeitumgebungen verwenden wollen, muss jede Anwendung in einem separaten Befehlsfenster ausgeführt werden.
Wenn Sie nur jeweils eine Version von Java ausführen wollen, können Sie mit Hilfe eines Batch-Scripts zwischen den verschiedenen Laufzeitumgebungen umschalten.
Gehen Sie wie folgt vor, um SDK zu deinstallieren, abhängig davon, ob Sie eine überwachte oder nicht überwachte Installation durchgeführt haben:
Diese Prozedur löscht alle Pakete vom System, die mit dem Installationsprogramm installiert wurden. Das Java Communications API-Paket (siehe Java Communications API) oder zusätzliche Dateien, die aus den Zip-Paketen extrahiert wurden, werden nicht gelöscht.
Wenn auf dem System mehrere Installationen zwischen IBM 32-bit SDK for Windows, v5.0 und V1.3.1 (oder ältere Versionen) vorhanden sind und Sie die älteren Version deinstallieren, während V5.0 weiterhin auf dem System vorhanden ist, löscht das Deinstallationsprogramm zu V1.3.1 die nachfolgend aufgeführten Registrierungsschlüssel und alle Unterschlüssel, die für V5.0 erforderlich sind. Dadurch wird die Installation von V5.0 beschädigt:
Installieren Sie daher V5.0 erst dann erneut, wenn Sie Version 1.3.1 deinstalliert haben. Diese Einschränkung in Bezug auf das Deinstallationsprogramm wurde für V1.4.0 und alle nachfolgenden Versionen behoben.
Mit dem Tool java wird durch Starten von Java Runtime Environment und Laden einer angegebenen Klasse eine Java-Anwendung gestartet.
JVM sucht in den drei folgenden Positionsgruppen nach der ursprünglichen Klasse (und anderen verwendeten Klassen): im Klassenpfad des Bootprogramms, in den installierten Erweiterungen und im Benutzerklassenpfad. Die nach dem Klassennamen oder JAR-Dateinamen angegebenen Argumente werden an die Hauptfunktion übermittelt.
Der Befehl javaw ist identisch mit dem Befehl java, außer dass beim Verwenden des Befehls javaw kein zugeordnetes Konsolfenster angezeigt wird. Verwenden Sie den Befehl javaw, wenn kein Fenster mit einer Eingabeaufforderung angezeigt werden soll. Der Startbefehl javaw zeigt im Falle eines fehlgeschlagenen Starts ein Dialogfenster mit Fehlerinformationen an.
Die Befehle java und javaw haben folgende Syntax:
java [ Optionen ] Klasse [ Argumente ... ] java [ Optionen ] -jar Datei.jar [ Argumente ... ] javaw [ Optionen ] Klasse [ Argumente ... ] javaw [ Optionen ] -jar Datei.jar [ Argumente ... ]
Elemente in eckigen Klammern sind optional.
Wenn die Option -jar angegeben wurde, enthält die benannte JAR-Datei Klassen- und Ressourcendateien für die Anwendung, wobei die Systemstartklasse über den Manifestheader für die Hauptklasse angegeben wird.
Das Startprogramm verfügt über mehrere Standardoptionen, die in der aktuellen Laufzeitumgebung und auch in zukünftigen Releases unterstützt werden. Daneben gibt es mehrere vom Standard abweichende Optionen. Die Standardoptionen wurden für die beste allgemeine Verwendung ausgewählt. Gehen Sie deshalb bei Änderungen vorsichtig vor.
Sie können Java-Optionen und Systemmerkmale auf drei verschiedene Arten angeben. Diese sind im Folgenden aufgelistet (nach Priorität):
Die Optionen, die in der Befehlszeile ganz rechts stehen, haben Vorrang vor den Optionen, die ganz links stehen. Wenn Sie z. B. die Optionen -Xint -Xjit meineKlasse angeben, hat -Xjit Vorrang.
Bei den unten aufgelisteten -X-Optionen handelt es sich um Optionen, die vom Standard abweichen und jederzeit ohne vorherige Ankündigung geändert werden können.
In Optionen, die den Parameter <Größe> enthalten, müssen Sie der Zahl ein "k" oder "K" für Kilobyte, ein "m" oder "M" für Megabyte oder ein "g" oder "G" für Gigabyte voranstellen.
Geben Sie den folgenden Befehl an einer Eingabeaufforderung ein, um die IBM Build- und Versionsnummer abzurufen:
java -version
Mit dem Befehl java und mit anderen Java-Startbefehlen (wie beispielsweise javaw) kann ein Klassenname mit beliebigen Zeichen angegeben werden, die im Zeichensatz der aktuellen Ländereinstellung enthalten sind.
Mit Hilfe von Java-Escapezeichenfolgen können Sie auch alle im Klassennamen und in den Argumenten enthaltenen Unicode-Zeichen angeben. Für diesen Vorgang müssen Sie die Option -Xargencoding angeben. Verwenden Sie zum Angeben eines Unicode-Zeichens Escapezeichenfolgen im Format \u####. Dabei ist # eine Hexadezimalziffer (0-9, A-F).
Wenn Sie angeben möchten, dass der Klassenname und die Befehlsargumente im UTF8-Code verschlüsselt sind, verwenden Sie -Xargencoding:utf8 oder -Xargencoding:latin für die ISO8859_1-Verschlüsselung.
Wenn Sie beispielsweise eine Klasse mit dem Namen "HelloWorld" angeben möchten und für die beiden Großbuchstaben die Unicode-Verschlüsselung verwenden, müssen Sie den folgenden Befehl ausführen:
java -Xargencoding '\u0048ello\u0057orld'
Mit den Befehlen java und javaw werden übersetzte Ausgabenachrichten angezeigt. Diese Nachrichten unterscheiden sich je nach der Ländereinstellung, in der Java ausgeführt wird. Die ausführlichen Fehlerbeschreibungen und andere Debuginformationen, die vom Befehl java zurückgegeben werden, werden in Englisch angezeigt.
Klicken Sie zum Definieren einer Java-Klasse oder JAR-Datei, damit diese automatisch über die Datei ausgeführt wird, im Windows-Explorer Extras->Ordneroptionen->Dateitypen an. Sie können auch Folgendes an einer Eingabeaufforderung eingeben:
assoc .class=javaclass ftype javaclass=C:\Programme\IBM\Java50\jre\bin\java.exe %l %*
Sun stellt das Produkt Java Access Bridge bereit, mit dem native Windows-Technologien für behindertengerechte Bedienung, z. B. Sprachausgabesysteme (Screen Reader), auf die Java Accessibility-Unterstützung in einer Java-Anwendung zugreifen können. Diese nativen Windows-Technologien für behindertengerechte Bedienung müssen Aufrufe an Java Access Bridge unterstützen.
Java Access Bridge ist bei Sun erhältlich und umfasst ein Installationsprogramm, das die folgenden fünf Dateien in die richtigen Verzeichnisse kopiert: access-bridge.jar, jaccess.jar, accessibility.properties, JavaAccessBridge.dll und WindowsAccessBridge.dll. IBM stellt eine Kopie der Datei jaccess.jar im entsprechenden Verzeichnis für die Verwendung mit JawBridge zur Verfügung.
Wenn IBM Accessibility Bridge (JawBridge), das die Verwendung von Windows 2000 Magnifier zusammen mit Swing-Anwendungen ermöglicht, bereits aktiviert ist, und wenn Sie JawBridge und Java Access Bridge gleichzeitig aktivieren wollen, editieren Sie die folgende Zeile in der Datei accessibility.properties:
assistive_technologies=com.sun.java.accessibility.AccessBridge, JawBridge
Sie können die beiden Bridges inaktivieren, indem Sie am Anfang der Zeile ein Nummernzeichen # eingeben. Auf der folgenden Website finden Sie Informationen zum Herunterladen der Java Access Bridge:
http://java.sun.com/products/jfc/accessibility.html
Der IBM JIT-Compiler (Just-In-Time) generiert dynamisch Maschinencode für häufig verwendete Bytecodesequenzen in Java-Anwendungen und Java-Applets, während diese ausgeführt werden. |Der JIT-Compiler Version 5.0 bietet neue Optimierungen als Ergebnis der Compiler-Forschung, verbessert Optimierungen, die in vorherigen Versionen des JIT-Compilers implementiert wurden, und bietet bessere Hardware-Nutzung.
IBM SDK und Runtime Environment enthalten den JIT-Compiler, der standardmäßig in Benutzeranwendungen und in SDK-Tools aktiviert ist. In der Regel besteht keine Notwendigkeit, den JIT-Compiler explizit aufzurufen. Die Kompilierung des Java-Bytecodes in Maschinencode erfolgt transparent. Wenn jedoch ein Problem mit Runtime Environment bei der Ausführung einer Java-Anwendung oder eines Java-Applets auftritt, können Sie den JIT-Compiler inaktivieren, um das Problem leichter eingrenzen zu können. Der JIT-Compiler sollte nur vorübergehend inaktiviert werden, da er für eine adäquate Leistung erforderlich ist.
Zum Inaktivieren des JIT-Compilers haben Sie drei Möglichkeiten:
Geben Sie an der Eingabeaufforderung, an der die Anwendung ausgeführt wird, Folgendes ein:
set JAVA_COMPILER=NONE
Sie können JAVA_COMPILER auch permanent über die grafische Benutzerschnittstelle festlegen. Öffnen Sie Systemsteuerung, wählen Sie System aus, zeigen Sie die Indexzunge Erweitert an, und wählen Sie Umgebungsvariablen aus.
java -Djava.compiler=NONE MeineAnwendung
java -Xint MeineAnwendung
Beide Befehlszeilenoptionen überschreiben die Umgebungsvariable JAVA_COMPILER.
Setzen Sie zum expliziten Aktivieren des JIT-Compilers die Umgebungsvariable JAVA_COMPILER auf "jitc", oder verwenden Sie die Option -D, um das Merkmal java.compiler auf "jitc" zu setzen. Sie können in der JVM-Befehlszeile auch die Option -Xjit verwenden (und die Option -Xint weglassen), um den JIT-Compiler zu aktivieren.
Wenn die Umgebungsvariable JAVA_COMPILER oder das Merkmal java.compiler auf "" (leere Zeichenfolge) gesetzt ist, bleibt der JIT-Compiler inaktiviert. Geben Sie set JAVA_COMPILER= an der Eingabeaufforderung ein, um die Einstellung der Umgebungsvariablen ordnungsgemäß aufzuheben.
Wenn Sie prüfen wollen, ob der JIT-Compiler aktiviert ist, geben Sie an der Eingabeaufforderung Folgendes ein:
java -version
Wenn der JIT-Compiler derzeit nicht verwendet wird, wird folgende Nachricht angezeigt:
(JIT disabled)
Wenn der JIT-Compiler verwendet wird, wird folgende Nachricht angezeigt:
(JIT enabled)
Weitere Informationen zum JIT-Compiler finden Sie im Handbuch Diagnostics Guide.
Der Garbage-Collector verwaltet den von Java und von den Anwendungen verwendeten Speicher, die mit VM ausgeführt werden.
Sobald der Garbage-Collector eine Speicheranforderung empfängt, wird hierfür nicht verwendeter Freispeicher vorgesehen. Dies wird auch als "Zuordnung" bezeichnet. Der Garbage-Collector prüft außerdem, ob Speicherbereiche vorhanden sind, auf die nicht mehr verwiesen wird, und gibt sie zur erneuten Verwendung frei. Dies wird auch als "Erfassung" bezeichnet.
Die Erfassungsphase kann durch einen Fehler bei der Hauptspeicherzuordnung ausgelöst werden, der dann auftritt, wenn für Speicheranforderungen kein weiterer Speicherbereich mehr vorhanden ist. Sie kann aber auch über einen expliziten System.gc()-Aufruf ausgelöst werden.
Die Garbage-Collection kann erhebliche Auswirkungen auf die Anwendungsleistung haben. IBM VM stellt daher verschiedene Methoden zur Verfügung, über die die Ausführung der Garbage-Collection optimiert werden kann. Dadurch verringern sich die Auswirkungen auf Ihre Anwendungen.
Ausführliche Informationen zur Garbage-Collection finden Sie im Handbuch Diagnostics Guide.
Die Option -Xgcpolicy gibt die Garbage-Collection-Richtlinie an.
-Xgcpolicy nimmt die Werte optthruput (Standardwert und empfohlener Wert), optavgpause oder gencon an. Die Option steuert das Verhalten der Garbage-Collection, so dass zwischen dem Durchsatz der Anwendung und des Gesamtsystems und den durch die Garbage-Collection verursachten Pausezeiten abgewogen werden kann.
Das Format der Option und der zugehörigen Werte lautet wie folgt:
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
Wenn eine Anwendung wegen des verfügbaren Freispeichers nicht sofort ein Objekt erstellen kann, ist der Garbage-Collector für die Erkennung von Objekten ohne Verweis (Garbage) zuständig sowie für deren Löschung und für die Wiederherstellung eines Freispeicherstatus, mit dem sofortige und nachfolgende Zuordnungsanforderungen schnell beantwortet werden können. Solche Garbage-Collection-Zyklen ergeben gelegentliche unerwartete Pausen bei der Ausführung des Anwendungscodes. Wenn sich die Größe und Komplexität der Anwendungen erhöht und wenn die Freispeicher entsprechend umfangreicher werden, tendiert diese Pausezeit der Garbage-Collection dazu, größer zu werden. Der Standardwert -Xgcpolicy:optthruput für die Garbage-Collection bietet Anwendungen einen sehr hohen Durchsatz, verursacht jedoch gelegentliche Pausen. Diese Pausen können wenige Millisekunden bis zu mehreren Sekunden dauern, je nachdem, wie groß der Freispeicher und das Garbagevolumen ist.
JVM verwendet zwei Verfahren zur Verringerung von Pausezeiten:
Die Befehlszeilenoption -Xgcpolicy:optavgpause fordert die Verwendung der gleichzeitig ablaufenden Garbage-Collection an, um die Pausezeit der Garbage-Collection (GC) erheblich zu verringern. Die gleichzeitig ablaufende GC verringert die Pausezeit, indem die Ausführung einiger GC-Aktivitäten zur gleichen Zeit wie die normale Programmausführung erfolgt. Dabei wird die durch die Erfassung des Freispeichers verursachte Unterbrechung minimiert. Die Option -Xgcpolicy:optavgpause begrenzt außerdem den Effekt eines höheren Freispeicherumfangs während der Garbage-Collection-Pause. Die Option -Xgcpolicy:optavgpause ist für Konfigurationen mit großen Freispeichern am nützlichsten. Die Verringerung der Pausezeit hat möglicherweise einen reduzierten Anwendungsdurchsatz zur Folge.
Während der gleichzeitig ablaufenden Garbage-Collection wird viel Zeit für die Identifizierung von Objekten mit einer relativ langen Lebensdauer verwendet, die nicht erfasst werden können. Wenn sich die GC nur auf Objekte konzentriert, die höchstwahrscheinlich wiederverwendbar sind, können Sie die Pausezeit für einige Anwendungen weiter verringern. Bei der GC nach Objektalter wird dies erreicht, indem der Freispeicher in zwei "Generationen" aufgeteilt wird, nämlich in die Bereiche "Junge Objekte" und "Alte Objekte". Die Objekte werden abhängig von ihrem Alter in einen dieser Bereiche gestellt. Der Bereich "Junge Objekte" ist der kleinere der beiden Bereiche und enthält jüngere Objekte. Der Bereich "Alte Objekte" ist größer und enthält ältere Objekte. Objekte werden zuerst dem Bereich "Junge Objekte" zugeordnet. Wenn sie lang genug überleben, werden Sie schließlich in den Bereich "Alte Objekte" umgestuft.
Die GC nach Objektalter basiert darauf, dass die meisten Objekte nur eine kurze Lebensdauer haben. Die GC nach Objektalter verringert Pausezeiten, indem sie sich auf das Zurückgewinnen von Speicher im Bereich "Junge Objekte" konzentriert, da dieser Bereich über den meisten wiederverwendbaren Speicherplatz verfügt. Im Gegensatz zu gelegentlichen aber übermäßig langen Pausezeiten beim Erfassen des gesamten Freispeichers wird der Bereich "Junge Objekte" regelmäßiger erfasst. Außerdem sind Pausezeiten verhältnismäßig kurz, wenn der Bereich klein genug ist. Die GC nach Objektalter hat jedoch den Nachteil, dass der Bereich "Alte Objekte" mit der Zeit voll wird, wenn zu viele Objekte eine zu lange Lebensdauer haben. Verwenden Sie eine Kombination aus der gleichzeitig ablaufenden GC und der GC nach Objektalter, um in dieser Situation die Pausezeit zu minimieren. Die Option -Xgcpolicy:gencon fordert die kombinierte Verwendung der gleichzeitig ablaufenden GC und der GC nach Objektalter an, um die GC-Pausezeit zu verringern.
Wenn der Java-Freispeicher nahezu voll ist und sehr wenig zurückzufordernder Garbagespeicher vorhanden ist, werden Anforderungen für neue Objekte möglicherweise nicht schnell beantwortet, da kein Speicherbereich sofort verfügbar ist. Bei der Ausführung mit nahezu vollem Freispeicher kann die Anwendungsleistung geringer werden, unabhängig davon, welche der oben genannten Optionen Sie verwenden. Wenn weiterhin Freispeicher angefordert wird, empfängt die Anwendung eine Ausnahmebedingung wegen ungenügender Speicherkapazität und JVM wird beendet, es sei denn, die Ausnahmebedingung wird abgefangen und bearbeitet. Zu diesem Zeitpunkt erstellt JVM eine Diagnosedatei mit dem Namen "javadump". In diesen Situationen sollten Sie entweder die Freispeichergröße mit der Option -Xmx erhöhen oder die Anzahl der verwendeten Anwendungsobjekte verringern. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
Wenn ein für Java Virtual Machine (JVM) wichtiges Signal gesendet wird, wird eine Signalroutine aufgerufen. Diese Signalroutine legt fest, ob das Signal für einen Java- oder Nicht-Java-Thread aufgerufen wurde.
Wurde das Signal für einen Java-Thread aufgerufen, steuert JVM die Signalverarbeitung. Wenn eine Anwendungsroutine für dieses Signal installiert ist, und Sie die Befehlszeilenoption -Xnosigchain nicht angegeben haben, wird die Anwendungsroutine für dieses Signal aufgerufen, nachdem JVM die Verarbeitung abgeschlossen hat.
Wurde das Signal für einen Nicht-Java-Thread aufgerufen und wurde zuvor mit der Anwendung, mit der JVM installiert wurde, eine eigene Routine für das Signal installiert, übernimmt diese Signalroutine die Steuerung. Wenn das Signal jedoch von JVM oder der Java-Anwendung angefordert wird, wird es ignoriert, oder die Standardaktion wird ausgeführt.
Unter Windows gibt es eine Ausnahme für diese Regel: Für ein extern generiertes Signal (z. B. durch Drücken der Taste Strg-Untbr) wird zum Ausführen der Signalroutine ein neuer Thread erstellt. In diesem Fall führt die JVM-Signalroutine die Verarbeitung aus, und die Anwendungsroutine für dieses Signal wird installiert, wenn für dieses Signal eine Anwendungsroutine installiert ist und Sie die Befehlszeilenoption -Xnosigchain nicht angegeben haben.
JVM führt für Signale bei Ausnahmebedingungen und für Fehlersignale eine der folgenden Aktionen aus:
Bei Interruptsignalen beginnt JVM ebenfalls eine Sequenz für einen kontrollierten Systemabschluss, der jedoch in diesem Fall wie eine normale Beendigung behandelt wird. Hierbei führt JVM die folgenden Aktionen aus:
Der Systemabschluss entspricht dem Systemabschluss, der über einen Aufruf der Java-Methode System.exit() eingeleitet wurde.
Weitere von JVM verwendete Signale werden für die interne Steuerung verwendet und führen nicht zur Beendigung von JVM. Das einzige wichtige Steuerungssignal ist SIGBREAK, durch das ein Java-Speicherauszug generiert wird.
In Tabelle 1 sind die von JVM verwendeten Signale aufgeführt. Die Signale werden in der Tabelle nach Typ oder Verwendung wie folgt zusammengefasst:
| Signalname | Signaltyp | Beschreibung | Inaktiviert durch -Xrs |
|---|---|---|---|
| SIGINT | Interrupt | Interaktiver Abruf (Strg-C). JVM wird normal beendet. | Ja |
| SIGTERM | Interrupt | Beendigungsanforderung. JVM wird normal beendet. | Ja |
| SIGBREAK | Steuerzeichen | Ein Unterbrechungssignal von einem Terminal. JVM verwendet dieses Signal zum Ausführen von Java-Speicherauszügen. | Ja |
Mit Hilfe der Option -Xrs (Reduzierung der Verwendung von Signalen) können Sie verhindern, dass JVM die meisten Signale verarbeitet. Weitere Informationen hierzu finden Sie auf der Sun-Website zum Startprogramm für Java-Anwendungen unter http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.
Die Signale 2 (SIGINT) und 15 (SIGTERM) für JVM-Threads führen zur Beendigung von JVM. Daher sollte eine Anwendungssignalroutine bei diesen Signalen keine Wiederherstellung versuchen, es sei denn, JVM wird nicht mehr benötigt.
Runtime Environment enthält eine Signalverkettungsfunktion. Die Signalverkettung ermöglicht eine effizientere Interaktion von JVM mit nativem Code, der eigene Signalroutinen installiert.
Mit der Signalverkettungsfunktion kann eine Anwendung mit der gemeinsam benutzten Bibliothek jsig.dll verbunden werden und diese vor msvcrt.dll laden. Mit Hilfe der Bibliothek jsig.dll wird sichergestellt, dass signal()-Aufrufe abgefangen werden, so dass die JVM-Signalroutinen nicht durch die zugehörigen Routinen ersetzt werden. Stattdessen werden die neuen Signalroutinen durch diese Aufrufe gesichert oder nach den durch JVM installierten Signalroutinen hinzugefügt. Wenn diese Signale zu einem späteren Zeit gesendet werden und nicht an JVM gerichtet sind, werden die vorinstallierten Signalroutinen aufgerufen.
Wenn Sie jsig.dll verwenden möchten, stellen Sie eine Verbindung von jsig.dll zu der Anwendung her, die JVM erstellt oder integriert.
In IBM SDK sind der XSLT4J-Prozessor und der XML4J-Parser enthalten, die der Spezifikation JAXP 1.3 entsprechen. Mit Hilfe dieser Tools können Sie XML-Dokumente unabhängig von einer bestimmten Implementierung zur XML-Verarbeitung syntaktisch analysieren und umwandeln. Mit der Funktion "Factory Finders" zum Suchen nach den Implementierungen SAXParserFactory, DocumentBuilderFactory und TransformerFactory kann Ihre Anwendung zwischen unterschiedlichen Implementierungen umschalten, ohne dass hierfür Code geändert werden muss.
|Die in IBM SDK enthaltene XML-Technologie ähnelt Apache Xerces Java und Apache Xalan Java. Weitere Informationen finden Sie unter http://xml.apache.org/xerces2-j/ und http://xml.apache.org/xalan-j/.
Der XSLT4J-Prozessor bietet Ihnen die Möglichkeit, zwischen dem ursprünglichen XSLT Interpretive-Prozessor und dem neuen XSLT Compiling-Prozessor zu wählen. Der Interpretive-Prozessor wurde speziell für Tools- und Debuggingumgebungen entwickelt. Er unterstützt die XSLT-Erweiterungsfunktionen, die vom XSLT Compiling-Prozessor nicht unterstützt werden. Der XSLT Compiling-Prozessor wurde dagegen für hochleistungsfähige Laufzeitumgebungen entwickelt. Er generiert aus einem XSL-Style-Sheet eine Umwandlungsroutine (oder Translet). Dadurch wird die Interpretation von Style-Sheet-Anweisungen von der zugehörigen ausführbaren Anwendung für XML-Daten getrennt.
Der XSLT Interpretive-Prozessor ist der Standardprozessor. Zur Auswahl des XSLT Compiling-Prozessors stehen folgende Möglichkeiten zur Verfügung:
Zur Implementierung von Merkmalen in der Datei jaxp.properties müssen Sie die Datei jaxp.properties.sample in die Datei jaxp.properties unter C:\Programme\IBM\Java50\ kopieren. Diese Datei enthält außerdem ausführliche Informationen zur Vorgehensweise bei der Ermittlung der Implementierungen, die für TransformerFactory, SAXParserFactory und DocumentBuilderFactory verwendet werden sollen.
Zur Verbesserung der Leistung bei der Umwandlung von StreamSource-Objekten mit dem XSLT Compiling-Prozessor müssen Sie die Klasse com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager als Provider des Services org.apache.xalan.xsltc.dom.XSLTCDTMManager angeben. Führen Sie zur Ermittlung des Service-Providers jeden der nachfolgend aufgeführten Schritte durch, bis org.apache.xalan.xsltc.dom.XSLTCDTMManager gefunden wird:
Der XSLT Compiling-Prozessor erkennt den Service-Provider für den Service org.apache.xalan.xsltc.dom.XSLTCDTMManager beim Erstellen eines Objekts mit dem Namen javax.xml.transform.TransformerFactory. Alle Objekte mit dem Namen javax.xml.transform.Transformer oder javax.xml.transform.sax.TransformerHandler, die mit Hilfe dieses TransformerFactory-Objekts erstellt werden, verwenden denselben Service-Provider. Sie können Service-Provider nur ändern, indem Sie eine der oben aufgeführten Einstellungen ändern und anschließend ein neues TransformerFactory-Objekt erstellen.
Wenn Sie mit einer älteren Version von Tomcat arbeiten, gilt möglicherweise die folgende Einschränkung.
Wenn Sie im Überschreibungsverzeichnis eine älteren Version von Xerces (vor Version 2.0) oder Xalan (vor Version 2.3) verwenden, wird beim Aufrufen der Anwendung möglicherweise eine Ausnahmebedingung für Nullzeiger angezeigt. Diese Ausnahmebedingung tritt auf, da bei älteren Versionen die Datei jaxp.properties nicht ordnungsgemäß verarbeitet werden kann.
Gehen Sie wie folgt vor, um diesen Fehler zu umgehen:
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory= org.apache.xerces.jaxp.SAXParserFactoryImploder
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory= org.apache.xerces.jaxp.DocumentBuilderFactoryImploder
set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory= org.apache.xalan.processor.TransformerFactoryImpl
In den folgenden Abschnitten erhalten Sie Informationen zur Verwendung von SDK for Windows zur Entwicklung von Java-Anwendungen. Einzelheiten zu den verfügbaren Tools finden Sie im Abschnitt SDK-Tools.
Zur Fehlerbehebung in Java-Programmen können Sie den Java-Debugger (JDB) oder andere Debugger verwenden, die über die JPDA (Java Platform Debugger Architecture) kommunizieren, die in SDK for Windows enthalten ist.
Der Java-Debugger (JDB) ist in SDK for Windows enthalten. Dieser Debugger wird über den Befehl jdb aufgerufen. Er wird JVM über die JPDA zugeordnet. Gehen Sie zur Fehlerbehebung in Java-Anwendungen wie folgt vor:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<Port>
MeineAnwendung <Argumente zu MeineAnwendung>jdb -attach <Portnummer>Der Debugger wird daraufhin JVM zugeordnet, und Sie können eine Reihe von Befehlen zur Überprüfung und Steuerung der Java-Anwendung ausführen. Mit dem Befehl run können Sie die Java-Anwendung beispielsweise ausführen.
Wenn Sie weitere Informationen zu JDB-Optionen aufrufen möchten, geben Sie Folgendes ein:
jdb -help
Gehen Sie wie folgt vor, um weitere Informationen zu JDB-Befehlen anzuzeigen:
Sie können JDB außerdem für die Fehlerbehebung in Java-Anwendungen auf fernen Maschinen verwenden. JPDA verwendet ein TCP/IP-Socket für die Verbindung mit der fernen JVM.
jdb -attach <Systemname oder IP-Adresse>:<Portnummer>
Wenn Sie eine Debugsitzung über das Transportprotokoll dt_socket aufrufen, müssen Sie sicherstellen, dass die angegebenen Ports verfügbar sind.
|Die JVMDI (Java Virtual Machine Debugging Interface) wird in diesem Release nicht unterstützt. Sie wurde durch die JVMTI (Java Virtual Machine Tool Interface) ersetzt.
Weitere Informationen zu JDB und JPDA sowie deren Verwendung finden Sie auf den folgenden Websites:
Einige Java-Anwendungen müssen in der Lage sein zu ermitteln, ob sie auf JVM im 32-Bit- oder 64-Bit-Modus ausgeführt werden. Falls Ihre Anwendung beispielsweise über eine Bibliothek mit nativem Code verfügt, muss die Bibliothek für Plattformen, die sowohl den 32-Bit- als auch den 64-Bit-Betriebsmodus unterstützen, separat im 32-Bit- und im 64-Bit-Format kompiliert werden. In diesem Fall muss die Anwendung während der Laufzeit die richtige Bibliothek laden, da der 32-Bit- und der 64-Bit-Code nicht miteinander kombiniert werden können.
Mit Hilfe des Systemmerkmals com.ibm.vm.bitmode können Anwendungen den Modus ermitteln, in dem JVM ausgeführt wird. Es werden folgende Werte zurückgegeben:
Mit dem folgenden Aufruf können Sie das Systemmerkmal com.ibm.vm.bitmode innerhalb des Anwendungscodes überprüfen:
System.getProperty("com.ibm.vm.bitmode");
Gültige JNI-Versionsnummmern, die über native Programme im API-Aufruf JNI_CreateJavaVM() angegeben werden können, lauten wie folgt:
Über diese Versionsnummer wird lediglich die Version der zu verwendenden nativen JNI-Schnittstelle festgelegt. Die tatsächliche JVM-Version, die erstellt wird, wird über die J2SE-Bibliotheken angegeben (Version 5.0). Die JNI-Schnittstellen-API hat keine Auswirkungen auf die Sprachenspezifikation, die über JVM, die APIs der Klassenbibliothek oder einen anderen Bereich mit JVM-Funktionen implementiert wird. Weitere Informationen hierzu finden Sie unter http://java.sun.com/j2se/1.5.0/docs/guide/jni.
Falls für Ihre Anwendung zwei JNI-Bibliotheken erforderlich sind (für 32 und 64 Bit), verwenden Sie das Systemmerkmal com.ibm.vm.bitmode, um festzustellen, ob derzeit eine 32-Bit- oder 64-Bit-JVM ausgeführt wird, und wählen Sie dann die geeignete Bibliothek aus.
Mit Applet Viewer können Sie mit Hilfe des Applet-Tags mindestens ein Applet ausführen, das durch Verweise auf einer Webseite (HTML-Datei) aufgerufen wird. Applet Viewer findet die APPLET-Tags in der HTML-Datei und führt die Applets, wie durch die Tags angegeben, in separaten Fenstern aus.
Da Applet Viewer für das Anzeigen von Applets konzipiert wurde, kann eine Webseite, die viele HTML-Tags enthält, mit Applet Viewer nicht vollständig angezeigt werden. Mit Applet Viewer kann lediglich eine syntaktische Analyse der APPLET-Tags und nicht der anderen auf der Webseite enthaltenen HTML-Tags durchgeführt werden.
Geben Sie zum Ausführen eines Applets mit Applet Viewer Folgendes an einer Eingabeaufforderung ein:
appletviewer Name
Name steht für Folgendes:
Geben Sie z. B. zum Aufrufen von Applet Viewer über eine HTML-Datei, die ein Applet aufruft, an einer Eingabeaufforderung Folgendes ein:
appletviewer <Demo>\GraphLayout\Beispiel1.html
<Demo> wird dabei durch den vollständigen Pfad des dekomprimierten Demopakets ersetzt.
Beispielsweise ist http://java.sun.com/applets/NervousText/Beispiel1.html die URL einer Webseite, die ein Applet aufruft. Geben Sie zum Aufrufen von Applet Viewer auf dieser Webseite an einer Shelleingabeaufforderung Folgendes ein:
appletviewer http://java.sun.com/applets/NervousText/Beispiel1.html
Applet Viewer erkennt die Option charset des Tags <META> nicht. Wenn die Datei, die Applet Viewer lädt, nicht als Systemstandard codiert ist, wird möglicherweise eine E/A-Ausnahmebedingung angezeigt. Verwenden Sie beim Ausführen des Befehls appletviewer die Option -encoding, um die Ausnahmebedingung zu vermeiden. Beispiel:
appletviewer -encoding JISAutoDetect Beispiel.html
Mit Hilfe der Option -debug von Applet Viewer können Sie Fehler in Applets beheben. Beim Debugging von Applets wird empfohlen, Applet Viewer über das Verzeichnis aufzurufen, in dem die HTML-Datei enthalten ist, die das Applet aufruft. Beispiel:
cd <Demo>\TicTacToe appletviewer -debug Beispiel1.html
<Demo> wird dabei durch den vollständigen Pfad des dekomprimierten Demopakets ersetzt.
Dokumentation zum Debugging von Applets finden Sie mit Hilfe des Applet Viewer auf der Website von Sun: http://java.sun.com.
| | |Sie können die Unterstützung für große Seiten auf Systemen aktivieren, die dies unterstützen. |Starten Sie dazu Java unter Angabe der Option -Xlp.
|Große Seiten werden in erster Linie verwendet, um |Leistungssteigerungen in Anwendungen zu erzielen, die große |Speichermengen zuordnen und häufig auf diesen Speicher zugreifen. |Die Leistungssteigerungen durch die Verwendung großer Seiten werden |hauptsächlich durch die geringe Anzahl Fehlschläge im Translation |Lookaside Buffer (TLB) erzielt. Der TLB ordnet einen größeren Bereich an virtuellem Speicher zu, |und daraus ergeben sich die Leistungssteigerungen.
|Damit JVM große Seiten verwendet, muss auf Ihrem System eine ausreichende Anzahl zusammenhängender großer Seiten verfügbar sein. Sollte es nicht möglich sein, große Seiten zuzuordnen, selbst wenn genügend Seiten |verfügbar sind, hängen die großen Seiten möglicherweise nicht zusammen.
|Die Zuordnung großer Seiten ist nur möglich, wenn die lokale Administrationsrichtlinie für den JVM-Benutzer so konfiguriert ist, dass "Lock pages in memory" (Seiten im Speicher sperren) zulässig ist.
Java 2 Platform, Standard Edition (J2SE) unterstützt mindestens die Spezifikationen, die in den offiziellen Spezifikationen für die CORBA-Unterstützung in J2SE (V1.5) enthalten sind. In einigen Fällen unterstützt IBM J2SE ORB neuere Versionen der Spezifikationen.
Wie in Kapitel 13 und 15 der Spezifikation CORBA 2.3.1 (OMG-Dokument formal/99-10-07) beschrieben, unterstützt SDK alle GIOP-Versionen. Sie können dieses Dokument unter der folgenden Adresse abrufen:
http://www.omg.org/cgi-bin/doc?formal/99-10-07
Bidirektionales GIOP wird nicht unterstützt.
Wie von der OMG (Object Management Group) im Dokument ptc/01-03-04 beschrieben, unterstützt SDK portierbare Abfangprozesse. Sie können dieses Dokument unter der folgenden Adresse abrufen:
http://www.omg.org/cgi-bin/doc?ptc/01-03-04
Portierbare Abfangprozesse sind Hooks in den ORB (Object Request Broker), über die ORB-Services den normalen Ausführungsablauf des ORBs unterbrechen können.
Wie von der OMG im Dokument ptc/00-08-07 beschrieben, unterstützt SDK den Interoperable Naming Service. Sie können dieses Dokument unter der folgenden Adresse abrufen:
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
Der Standardport, der vom Transient Name Server (Befehl tnameserv) verwendet wird, wenn der Parameter ORBInitialPort nicht angegeben ist, wurde von 900 in 2809 geändert. Dies ist die Portnummer, die zusammen mit der IANA (Internet Assigned Number Authority) für einen CORBA Naming Service registriert wird. Programme, die von dieser Standardeinstellung abhängig sind, müssen möglicherweise aktualisiert werden, um mit dieser Version arbeiten zu können.
Der Ausgangskontext, der vom Transient Name Server zurückgegeben wird, lautet jetzt org.omg.CosNaming.NamingContextExt. Bereits vorhandene Programme, die den Verweis auf den Kontext org.omg.CosNaming.NamingContext eingrenzen, funktionieren weiterhin und müssen nicht erneut kompiliert werden.
Der ORB unterstützt die über die Interoperable Naming Service-Spezifikation definierten Parameter -ORBInitRef und -ORBDefaultInitRef, und die Operation ORB::string_to_object unterstützt jetzt die über die Interoperable Naming Service-Spezifikation definierten Formate für ObjectURL-Zeichenfolgen (corbaloc: und corbaname:).
Die OMG gibt die Methode ORB::register_initial_reference an, um einen Service mit dem Interoperable Naming Service zu registrieren. Diese Methode ist jedoch in der Sun Java Core-API der Version 5.0 nicht verfügbar. Programme, die in der aktuellen Version einen Service registrieren müssen, müssen diese Methode in der internen IBM ORB-Implementierungsklasse aufrufen. Dies gilt beispielsweise beim Registrieren des Services "MeinService":
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MeinService",
serviceRef);
Dabei ist orb eine Instanz von org.omg.CORBA.ORB, die von ORB.init() zurückgegeben wird, und serviceRef ein CORBA-Objekt, das mit dem ORB verbunden ist. Dies ist ein vorläufiger Mechanismus, der mit zukünftigen Versionen nicht kompatibel ist und nicht auf ORBs anderer Hersteller portiert werden kann.
Durch eine Laufzeitfunktion zur Fehlerbehebung wird die Servicefreundlichkeit verbessert. Diese Funktion kann für die Problemdiagnose verwendet werden, oder sie wird vom IBM Kundendienst benötigt. Die Tracefunktion wird von drei Systemmerkmalen gesteuert.
Geben Sie z. B. Folgendes ein, um ein Trace für Ereignisse und formatierte GIOP-Nachrichten durchzuführen:
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true MeineAnwendung
Aktivieren Sie die Tracefunktion nicht für normale Operationen, da dies zu Leistungseinbußen führen kann. Obwohl Sie die Tracefunktion inaktiviert haben, funktioniert FFDC (First Failure Data Capture) weiterhin, so dass nur schwer wiegende Fehler dokumentiert werden. Wenn eine Debugausgabedatei generiert wird, prüfen Sie sie in Bezug auf dieses Problem. Z. B. hat der Server möglicherweise seinen Betrieb eingestellt, ohne dass ORB.shutdown() ausgeführt wurde.
Der Inhalt und das Format der Traceausgabe können von Version zu Version variieren.
Mit den folgenden Merkmalen können Sie den ORB optimieren:
Geben Sie Folgendes ein, um für die Fragmentgröße 4096 Byte festzulegen:
java -Dcom.ibm.CORBA.FragmentSize=4096 MeineAnwendung
Die Standardeinstellung lautet 1024 Byte. Sie können die Fragmentierung inaktivieren, wenn Sie die Fragmentgröße auf 0 setzen.
java -Dcom.ibm.CORBA.RequestTimeout=30
-Dcom.ibm.CORBA.LocateRequestTimeout=30 MeineAnwendung
Standardmäßig wartet der ORB uneingeschränkt lange auf eine Antwort. Legen Sie für das Zeitlimit keinen zu niedrigen Wert fest, um zu vermeiden, dass Verbindungen unnötigerweise beendet werden.
Geben Sie z. B. Folgendes ein, damit der ORB Port 1050 verwendet:
java -Dcom.ibm.CORBA.ListenerPort=1050 MeineAnwendung
Wenn für dieses Merkmal ein Wert festgelegt wurde, ist der ORB empfangsbereit, sobald er initialisiert wurde. Andernfalls ist er nur empfangsbereit, wenn es erforderlich ist.
Bei der Ausführung eines Java 2-Sicherheitsmanagers kann das Aufrufen einiger Methoden in den CORBA-API-Klassen Berechtigungsprüfungen verursachen, die wiederum zu einer Ausnahmebedingung SecurityException führen. Zu den hiervon betroffenen Methoden gehören:
| Klasse/Schnittstelle | Methode | Erforderliche Berechtigung |
|---|---|---|
|
org.omg.CORBA.ORB |
init |
java.net.SocketPermission resolve |
|
org.omg.CORBA.ORB |
connect |
java.net.SocketPermission listen |
|
org.omg.CORBA.ORB |
resolve_initial_references |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_is_a |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_non_existent |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
OutputStream _request (String, boolean) |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_get_interface_def |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
invoke |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
send_deferred |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
send_oneway |
java.net.SocketPermission connect |
|
javax.rmi. PortableRemoteObject |
narrow |
java.net.SocketPermission connect |
Falls Ihr Programm eine der aufgeführten Methoden verwendet, müssen Sie sicherstellen, dass die erforderlichen Berechtigungen vorliegen.
Die ORB-Implementierungsklassen in diesem Release lauten:
Hierbei handelt es sich um die Standardwerte. Es wird jedoch empfohlen, diese Merkmale nicht direkt festzulegen bzw. nicht direkt auf die Implementierungsklassen zu verweisen. Aus Gründen der Portierbarkeit sollte ausschließlich auf die CORBA-API-Klassen und nicht auf die Implementierungsklassen verwiesen werden. Diese Werte werden in zukünftigen Releases möglicherweise geändert.
Java Remote Method Invocation (RMI) bietet ein einfaches Verfahren für die verteilte Java-Programmierung. RMI-IIOP (RMI over IIOP) arbeitet auf der Grundlage des Standard-IIOP-Protokolls (IIOP - Internet Inter-ORB Protocol) der CORBA (Common Object Request Broker Architecture) und ermöglicht so Erweiterungen der Java-RMI bei Datenübertragungen. Dadurch sind direkte Interaktionen mit beliebigen anderen CORBA-Object-Request-Brokern (ORBs) möglich, unabhängig davon, ob diese in Java oder einer anderen Programmiersprache implementiert wurden.
Folgende Dokumentation steht zur Verfügung:
Thread-Pooling für Steuerroutinen von RMI-Verbindungen wird nicht standardmäßig aktiviert.
Wenn Sie das Verbindungspooling aktivieren wollen, das in der RMI-TCPTransport-Ebene implementiert ist, legen Sie die folgende Option fest:
-Dsun.rmi.transport.tcp.connectionPool=true (oder einen Wert ungleich null)
Diese Runtime Environment-Version verfügt über keine Einstellungen, die Sie verwenden können, um die Anzahl Threads im Verbindungspool zu begrenzen.
Weitere Informationen finden Sie auf der Java-Website von Sun: http://java.sun.com.
IBM SDK umfasst erweiterte BiDirectional-Unterstützung. Weitere Informationen erhalten Sie unter http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html. Die Javadoc-Komponente für das BiDirectional-Paket wird mit SDK in der Datei docs/apidoc.zip mitgeliefert.
Über Java 5.0 wurde die IBM BigDecimal-Klasse von Sun als java.math.BigDecimal übernommen. com.ibm.math.BigDecimal wird von IBM nicht mehr gepflegt und ist daher veraltet. Es wird empfohlen, für die Verwendung von java.math.BigDecimal bereits vorhandenen Java-Code zu migrieren.
|Die neue Klasse java.math.BigDecimal verwendet dieselben Methoden wie die Vorversion |und wie com.ibm.math.BigDecimal. Der bereits vorhandene Code, der java.math.BigDecimal verwendet, funktioniert weiterhin ordnungsgemäß.
|Wenn Sie bereits vorhandenen Java-Code migrieren wollen, um die Klasse java.math.BigDecimal zu verwenden, ändern Sie die Importanweisung am Anfang Ihrer Java-Datei von import com.ibm.math.*; in import java.math,*;.
Für IBM SDK und Runtime Environment gilt ab dem 1. Januar 2002 für die Länder der Europäischen Währungsunion der Euro als Standardwährung.
Wenn Sie die frühere nationale Währung verwenden möchten, geben Sie in der Java-Befehlszeile -Duser.variant=PREEURO an.
Wenn Sie mit der britischen, dänischen oder schwedischen Ländereinstellung arbeiten und den Euro als Währung verwenden möchten, geben Sie in der Java-Befehlszeile -Duser.variant=EURO an.
Das Paket mit der Java Communications API (JavaComm) ist ein optional erhältliches Paket, das zusammen mit Runtime Environment for Windows eingesetzt werden kann. JavaComm kann unabhängig von SDK oder Runtime Environment installiert werden.
Mit Hilfe der JavaComm API sind Java-Anwendungen in der Lage, Übertragungen über den seriellen Anschluss und den Parallelanschluss für Technologien, wie z. B. Voicemail, Fax und Smartcards, unabhängig von der jeweiligen Plattform durchzuführen. Nach dem Schreiben von Übertragungen über den seriellen Anschluss oder den Parallelanschluss für Ihre Anwendung können Sie die entsprechenden Dateien in Ihre Anwendung aufnehmen.
Die Java Communications API unterstützt serielle EIA-232-Anschlüsse (EIA - Electronic Industries Association) bzw. RS232-Anschlüsse sowie IEEE 1284-Parallelanschlüsse (IEEE - Institute of Electrical and Electronics Engineers). Sie wird auf Systemen mit IBM Runtime Environment Version 5.0 unterstützt.
Bei Verwendung der Java Communications API haben Sie folgende Möglichkeiten:
Sie sollten vor der Installation der Java Communications API sicherstellen, dass eine Kopie von SDK oder Runtime Environment installiert ist.
Gehen Sie zur Installation der Java Communications API über eine Datei mit der Erweiterung zip folgendermaßen vor:
Falls Sie bei der Installation von Runtime Environment das Standardverzeichnis übernommen haben, befindet sich die Datei comm.jar im Verzeichnis C:\Programme\IBM\Java50\jre\lib\ext.
Wenn Sie die Datei in einem anderen Verzeichnis dekomprimieren, werden die Dateien in dieselbe Verzeichnisstruktur gestellt, an Stelle von C:\Programme\IBM\Java50\ wird jedoch das Verzeichnis verwendet, in dem Sie die Datei dekomprimiert haben.
Nach der Installation der Java Communications API müssen Sie folgende Schritte durchführen:
Bei Druckvorgängen über die Java Communications API müssen Sie auf dem Drucker möglicherweise die Tasten für Seitenvorschub oder Weiter oder eine ähnliche Funktion drücken.
Löschen Sie zum Deinstallieren der Java Communications API die folgenden Dateien aus dem Verzeichnis, in dem Sie Runtime Environment installiert haben:
Runtime Environment ist standardmäßig im Verzeichnis C:\Programme\IBM\Java50\ installiert.
Dokumentation zu APIs und Beispiele zur Java Communications API finden Sie auf der Sun-Website unter folgender Adresse: http://java.sun.com
Bei dem Java-Plug-in handelt es sich um ein Web-Browser-Plug-in. Durch Verwendung des Java-Plug-ins können Sie die Standard-JVM Ihres Web-Browsers umgehen und zum Ausführen von Applets oder Beans im Browser die gewünschte Laufzeitumgebung verwenden.
Sie müssen warten, bis die Applets vollständig geladen wurden, um zu vermeiden, dass sich der Browser "aufhängt". Wenn Sie beispielsweise die Knöpfe Zurück und Weiter verwenden, während ein Applet geladen wird, können die HTML-Seiten unter Umständen nicht geladen werden.
Das Java-Plug-in ist auf der Website von Sun unter http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/ dokumentiert.
|
| |Betriebssystem | |Internet Explorer | |Netscape | |Mozilla |
|---|---|---|---|
| |Windows 2000 | |5.5 SP2, 6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows XP | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows Server 2003 | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
Internet Explorer 5.01, der Standardbrowser unter Windows |2000, wird nicht unterstützt.
Auf Grund von Einschränkungen bei bestimmten Browsern können Sie möglicherweise nicht alle Funktionen des Pakets org.w3c.dom.html implementieren.
Das Java-Plug-in unterstützt Doppelbytezeichen (z. B. Traditionelles Chinesisch BIG-5, Koreanisch, Japanisch) als Parameter für die Tags <APPLET>,<OBJECT> und <EMBED>. Sie müssen die richtige Zeichencodierung für das HTML-Dokument auswählen, damit das Java-Plug-in den Parameter syntaktisch analysieren kann. Geben Sie die Zeichencodierung für das HTML-Dokument mit Hilfe des Tags <META> im Abschnitt <HEAD> wie folgt an:
<meta http-equiv="Content-Type" content="text/html; charset=big5">
In diesem Beispiel wird dem Browser mitgeteilt, dass er die HTML-Datei mit Hilfe der Zeichencodierung für Chinesisch BIG-5 syntaktisch analysieren soll. Alle Parameter werden ordnungsgemäß an das Java-Plug-in weitergeleitet. Einige der älteren Browserversionen erkennen diesen Tag möglicherweise nicht richtig. In diesem Fall können Sie erzwingen, dass der Browser diesen Tag ignoriert. Sie müssen die Codierung jedoch möglicherweise manuell ändern.
Sie können angeben, welche Codierung Sie verwenden möchten, um die HTML-Datei syntaktisch zu analysieren:
Mit Hilfe von Java Web Start können Sie Java-Anwendungen implementieren. Web Start bietet dem Benutzer die Möglichkeit, Anwendungen direkt über das Internet aufzurufen und zu verwalten. Über Java Web Start können Sie Anwendungen auf einfache Weise über das Internet starten. Dabei haben Sie die Gewissheit, dass Sie mit der neuesten Version arbeiten. Installations- oder Upgradeprozeduren sind daher nicht mehr erforderlich. Bei der Arbeit mit Java Web Start muss keine Software heruntergeladen und installiert werden, so dass komplexe Installationsoptionen umgangen werden.
|Neben den unter http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources dokumentierten Argumenten des Attributs java-vm-args unterstützt Web Start -Xgcpolicy zum Festlegen der Garbage-Collection-Richtlinie.
Weitere Informationen zu Browsern, die Web Start unterstützen, finden Sie im Abschnitt Unterstützte Browser.
Weitere Informationen zu Web Start finden Sie unter http://java.sun.com/products/javawebstart und http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Weitere Informationen zur Implementierung von Anwendungen finden Sie unter http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.
Sie können Web Start auf drei Arten aufrufen:
Sobald eine Anwendung heruntergeladen wurde, wird sie im Cache der Java-Anwendung zwischengespeichert. Wenn erneut auf die Anwendung zugegriffen wird, lädt Java Web Start eine neuere Version der Anwendung herunter, sofern diese verfügbar ist. Andernfalls wird die im Cache vorhandene Version verwendet.
Beim Auftreten eines Fehlers in einer JNLP-Datei (z. B. ein ungültiger Befehlsname) schlägt Web Start fehl, ohne dass eine Fehlernachricht angezeigt wird.
Bei einer Java-Anwendung kann im Gegensatz zu einem Java-Applet kein Web-Browser für Installations- und Laufzeitservices verwendet werden. Bei der Auslieferung einer Java-Anwendung kann im Softwarepaket beispielsweise Folgendes enthalten sein:
Zum Ausführen der Anwendung benötigt der Benutzer Runtime Environment for Windows. In SDK for Windows ist Runtime Environment enthalten. Sie können jedoch nicht davon ausgehen, dass SDK for Windows auf den Systemen aller Benutzer installiert ist.
Die Lizenz für SDK for Windows berechtigt nicht dazu, Dateien aus SDK zusammen mit der Anwendung weiter zu verteilen. Sie müssen sicherstellen, dass auf dem Zielsystem eine lizenzierte Version von SDK for Windows installiert ist.
| | |IBM Virtual Machine (VM) ermöglicht die gemeinsame Nutzung von Boot- und Anwendungsklassen auf verschiedenen VMs, indem diese als gemeinsam genutzter Speicher in einen Cache gestellt werden. Durch die gemeinsame Nutzung von Klassen verringert sich die gesamte virtuelle Speicherbelegung, wenn mehrere VMs einen Cache gemeinsam nutzen. Außerdem verkürzt sich hierdurch der Systemstart von VM, nachdem der Cache erstellt wurde. Der Cache für gemeinsam genutzte Klassen ist unabhängig von den aktiven VMs und besteht über die Laufzeit der VM hinaus, über die der Cache gestartet wurde.
| |Mit IBM SDK können Sie so viele Klassen wie möglich gemeinsam nutzen. Dieser Vorgang läuft für den Benutzer transparent ab.
| |Der Cache für gemeinsam genutzte Klassen enthält |schreibgeschützte statische Klassendaten und Metadaten, die die |Klassen beschreiben. Alle VMs können die Daten im Cache lesen oder |aktualisieren. VMs, die den Cache gemeinsam nutzen, müssen |dieselbe Version aufweisen. Bei der Bearbeitung von Laufzeitbytecodes müssen Sie sorgfältig vorgehen. (Siehe |hierzu die Informationen im Abschnitt Änderungen bei Laufzeitbytecodes.)
| |Da der Cache für gemeinsam genutzte Klassen über die |Laufzeit von VMs hinaus besteht, wird er dynamisch |aktualisiert, um alle Änderungen wiederzugeben, die |möglicherweise an JARs oder Klassen auf dem Dateisystem |vorgenommen wurden. Durch die dynamische Aktualisierung |erscheint der Cache für die Anwendung transparent, die den Cache |nutzt.
| |Sie können die gemeinsame Nutzung von Klassen mit Hilfe der |Option -Xshareclasses beim Starten von VM |aktivieren. VM stellt dadurch eine Verbindung zu einem |vorhandenen Cache her oder erstellt einen neuen Cache, falls noch |keiner vorhanden ist. Alle über VM geladenen Boot- und Anwendungsklassen werden standardmäßig gemeinsam genutzt. Benutzerdefinierte Klassenladeprogramme nutzen den Cache automatisch gemeinsam, wenn sie das Klassenladeprogramm der Anwendung erweitern. Sie müssen die zusammen mit VM verfügbare Java Helper API verwenden, um auf den Cache zugreifen zu können. (Siehe hierzu die Informationen im Abschnitt Anpassen benutzerdefinierter Klassenladeprogramme an gemeinsam genutzte Klassen.)
| |Der Zugriff auf den Cache für gemeinsam genutzte Klassen wird durch Berechtigungen des Betriebssystems und Java-Sicherheitsberechtigungen begrenzt. Nur ein Klassenladeprogramm, in dem die gemeinsame Nutzung von Klassen registriert ist, kann Klassen zum Cache für gemeinsam genutzte Klassen hinzufügen. Wenn ein Java-Sicherheitsmanager installiert ist, muss Klassenladeprogrammen, mit Ausnahme von Klassenladeprogrammen des Standardbootprogramms, von Anwendungen und Erweiterungen, die Berechtigung zur gemeinsamen Nutzung von Klassen erteilt werden, indem der Datei java.policy die Klasse SharedClassPermission hinzugefügt wird. (Siehe |hierzu die Informationen im Abschnitt Verwenden von SharedClassPermission.) |Die Laufzeitberechtigung "createClassLoader" beschränkt die Erstellung neuer Klassenladeprogramme und daher auch den Zugriff auf den Cache.
| |Auf einem System können mehrere Caches vorhanden sein. Sie |werden nach Namen als Unteroption des Befehls |-Xshareclasses angegeben. VM kann nur mit jeweils einem Cache verbunden werden. Die Cachegröße wird beim |Systemstart über den Befehl -Xscmx<n>[k|m|g] |angegeben, und die Größe ist dann für die gesamte Lebensdauer des |Caches festgelegt. Caches bestehen solange, bis sie |explizit über eine Unteroption des Befehls |-Xshareclasses gelöscht werden oder das System erneut gestartet wird.
| |Alle Cache-Dienstprogramme sind Unteroptionen des |Befehls -Xshareclasses. Mit |-Xshareclasses:help können Sie eine Liste der |verfügbaren Unteroptionen anzeigen.
| |Die gemeinsame Nutzung von Klassen wird mit Hilfe der Befehlszeilenoptionen -Xshareclasses und -Xscmx aktiviert und konfiguriert.
|Zum Aktivieren der gemeinsamen Nutzung von Klassen müssen Sie |die Angabe -Xshareclasses[:name=<Name>] in |der Befehlszeile Ihrer Anwendung hinzufügen. VM stellt |dann entweder eine Verbindung zu einem vorhandenen Cache mit dem |angegebenen Namen her oder erstellt einen neuen Cache mit diesem |Namen. Wenn ein neuer Cache erstellt wurde, wird dieser mit allen |Boot- und Anwendungsklassen gefüllt, die geladen wurden, bis der Cache voll wird. Sollten |zwei oder mehr VMs gleichzeitig gestartet werden, schreiben diese |gleichzeitig Daten in den Cache.
|Wenn Sie überprüfen möchten, ob der Cache erstellt wurde, führen |Sie den Befehl java -Xshareclasses:listAllCaches aus. Sie müssen den Befehl java -Xshareclasses:[name=<Name>],printStats ausführen, um anzuzeigen, wie viele Klassen und Klassendaten gemeinsam genutzt werden. (Diese Dienstprogramme können entweder nach der Beendigung der |Anwendungs-VM oder in einem anderen Befehlsfenster ausgeführt werden.)
|Wenn Sie Klassen anzeigen möchten, die in den Cache |geladen oder im Cache gespeichert wurden, fügen Sie in der |Befehlszeile Ihrer Anwendung -Xshareclasses:[name=<Name>],verbose |hinzu.
|Zum Löschen des zuvor erstellten Caches führen Sie den Befehl |java -Xshareclasses:[name=<Name>],delete aus. Caches müssen normalerweise nur dann gelöscht werden, wenn sie |zahlreiche veraltete Klassen enthalten bzw. wenn der Cache voll |ist und Sie einen größeren Cache erstellen möchten.
|Es wird empfohlen, die Cachegröße für Ihre spezielle Anwendung zu optimieren, da die Standardeinstellung sehr wahrscheinlich nicht die optimale Größe angibt. Am besten ermitteln Sie die optimale Cachegröße, indem Sie einen großen Cache (mit -Xscmx) angeben, die Anwendung ausführen und dann mit printStats ermitteln, wie viele Klassendaten gespeichert wurden. Addieren Sie für alle Fälle einen kleinen Betrag zu dem in printStats angezeigten Wert hinzu. Da Klassen jederzeit während der Lebensdauer von VM geladen werden können, empfiehlt es sich, diese Analyse nach Beendigung der Anwendung durchzuführen. Da jedoch ein voller Cache keine negativen Auswirkungen auf die Leistung oder Funktionalität von VMs hat, die mit diesem Cache verbunden sind, können Sie auch eine kleinere als die erforderliche Cachegröße auswählen.
|Wenn ein Cache voll wird, wird eine entsprechende Nachricht in der Befehlszeile aller VMs angezeigt, die diesen Cache verwenden. Diese VMs laden dann weitere Klassen in ihren eigenen Prozessspeicher. Die in einem vollen Cache enthaltenen |Klassen können weiterhin gemeinsam genutzt werden, der volle |Cache ist jedoch schreibgeschützt und kann nicht mit neuen |Klassen aktualisiert werden.
| |Die gemeinsame Nutzung von Klassen empfiehlt sich |insbesondere auf Systemen, auf denen mit mehreren VMs |gearbeitet wird, die ähnlichen Code ausführen. Diese Systeme profitieren von der |geringeren virtuellen Speicherbelegung. Außerdem ist die gemeinsame Nutzung von Klassen auf Systemen sinnvoll, auf denen VMs häufig |gestartet und heruntergefahren werden. Auf diesen Systemen |verkürzt sich dadurch der Zeitraum für den Systemstart.
|Der Aufwand für das Erstellen und Belegen eines neuen Caches |ist minimal. Wenn Sie die gemeinsame Nutzung von Klassen verwenden, aber nur eine einzige VM starten, dauert der Startvorgang 0 bis 5 % länger als der Startvorgang einer VM, die die gemeinsame Nutzung von Klassen nicht verwendet. Wenn Sie die gemeinsame Nutzung von Klassen verwenden und zwei VMs starten, lädt die zweite VM 10 bis 40 % schneller als eine VM, die die gemeinsame Nutzung von Klassen nicht verwendet. Dies hängt vom Betriebssystem |und der Anzahl geladener Klassen ab. Bei mehreren gleichzeitig ablaufenden VMs ergeben sich größere Verkürzungen bei der Startzeit.
|Wenn bei der Ausführung Ihrer Anwendung die gemeinsame |Nutzung von Klassen aktiviert ist, können Sie mit Hilfe von |Betriebssystemtools die Verringerung der virtuellen Speicherbelegung anzeigen.
| |Die maximale theoretische Cachegröße beträgt 2 GB. Der Cache wird durch die folgenden Faktoren begrenzt:
| |Damit VMs, die einen JVMTI-Agenten verwenden, mit dem Bytecode |geändert werden kann, die gemeinsame Nutzung von Klassen |ermöglicht wird, muss in der Befehlszeile die Unteroption |modified=<Geänderter Kontext> verwendet werden (siehe oben). Bei dem geänderten Kontext handelt es sich um einen benutzerdefinierten Deskriptor, der die Art der durchgeführten Änderung beschreibt. Alle VMs, die einen bestimmten geänderten Kontext |verwenden, müssen den Bytecode für jede Klasse in einer berechenbaren, |wiederholt anwendbaren Weise ändern, so dass die im Cache gespeicherten, |geänderten Klassen die erwarteten Änderungen aufweisen, |wenn sie von einer anderen VM geladen werden. Der Grund dafür, |dass alle Änderungen berechenbar sein müssen, besteht darin, dass |Klassen, die aus dem Cache für gemeinsam genutzte Klassen geladen |wurden, nicht über den Agenten erneut geändert werden können. Geänderter |und nicht geänderter Bytecode kann im selben Cache gespeichert |werden. Weitere Informationen hierzu finden Sie im Handbuch |Diagnostics Guide.
| |Bei Betriebssystemen, die sowohl |32-Bit-Anwendungen als auch 64-Bit-Anwendungen ausführen können, ist |die gemeinsame Nutzung von Klassen zwischen VMs mit 32 Bit und 64 Bit |nicht zulässig. |Mit der Unteroption listAllCaches werden je |nach Adressmodus der verwendeten VM 32-Bit- oder 64-Bit-Caches |aufgelistet.
|Der Cache für gemeinsam genutzte Klassen benötigt |Plattenspeicherplatz zum Speichern von ID-Informationen zu den Caches auf dem System. Diese |Informationen sind im Verzeichnis mit dem Benutzerprofil enthalten. Wenn das Verzeichnis mit |den ID-Informationen gelöscht wird, kann VM die gemeinsam |genutzten Klassen auf dem System nicht identifizieren und muss den Cache erneut |erstellen.
|Die Berechtigungen für den Zugriff auf einen Cache für gemeinsam genutzte Klassen werden vom Betriebssystem umgesetzt. Falls kein Cachename angegeben wird, wird der |Benutzername an den Standardnamen angehängt, damit mehrere Benutzer |auf demselben System standardmäßig eigene Caches erstellen.
| |Wenn ein Sicherheitsmanager zusammen mit der gemeinsamen Nutzung von Klassen verwendet wird und die ausgeführte Anwendung ihre eigenen Klassenladeprogramme verwendet, müssen diesen Klassenladeprogrammen Berechtigungen zur gemeinsamen Nutzung von Klassen erteilt werden, bevor sie Klassen gemeinsam nutzen können. Fügen Sie der Datei java.policy Berechtigungen zur gemeinsamen Nutzung von Klassen unter Verwendung des Klassennamens des Klassenladeprogramms (Platzhalterzeichen sind zulässig) und "read", "write" oder "read,write" zur Angabe der erteilten Zugriffsberechtigung hinzu. |Beispiel:
|permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";
Wenn ein Klassenladeprogramm nicht die korrekten Berechtigungen hat und versucht, Klassen gemeinsam zu nutzen, wird die Ausnahmebedingung AccessControlException ausgelöst. Sie können die Berechtigungen der Klassenladeprogramme für das Standardbootprogramm, für Anwendungen oder Erweiterungen nicht ändern oder verringern.
| |Die meisten Java-Anwendungen verwenden die Klassenladeprogramme |von VM oder verfügen über benutzerdefinierte Klassenladeprogramme, |die eine Erweiterung zu java/net/URLClassLoader darstellen. Anwendungen, |die diese Klassenladeprogramme verwenden, können automatisch Boot- und Anwendungsklassen gemeinsam nutzen. |Benutzerdefinierte Klassenladeprogramme, die keine Erweiterung |zu java/net/URLClassLoader darstellen, müssen bearbeitet werden, um |mit der gemeinsamen Nutzung von Klassen arbeiten zu können. Allen benutzerdefinierten Klassenladeprogrammen müssen Berechtigungen zur gemeinsamen Nutzung von Klassen erteilt werden, wenn ein Sicherheitsmanager verwendet wird. Weitere Informationen hierzu finden Sie im Abschnitt Verwenden von SharedClassPermission. IBM |bietet mehrere Java-Schnittstellen für verschiedene Typen von |benutzerdefinierten Klassenladeprogrammen, mit denen die |Programme im Cache für gemeinsam genutzte Klassen nach Klassen suchen |und diese speichern können. Diese Klassen befinden sich im Paket "com.ibm.oti.shared". Die Javadoc-Komponente für dieses Paket wird mit SDK in der Datei docs/apidoc.zip mitgeliefert. Weitere Informationen zur Verwendung |dieser Schnittstellen finden Sie im Handbuch Diagnostics |Guide.
Falls Sie berechtigt sind, Serviceleistungen für den Programmcode des Programms 'IBM Solutions Developer Program' in Anspruch zu nehmen, gehen Sie hierbei wie gewohnt vor, oder rufen Sie das Programm im Internet unter folgender Adresse auf: http://www-1.ibm.com/partnerworld/.
Wenn Sie einen Servicevertrag (z. B. für IBM Personal Systems Support Line oder für einen vergleichbaren, in Ihrem Land verfügbaren Service) unterzeichnet haben, ist in den Vertragsbedingungen dieses Servicevertrags festgelegt, welche Services Sie - falls verfügbar - gemäß dem o g. Programm in Anspruch nehmen dürfen.
Die Benutzerhandbücher, die zusammen mit SDK und Runtime Environment geliefert werden, wurden mit Hilfe von Sprachausgabeprogrammen getestet. Sie können ein Sprachausgabeprogramm, wie z. B. Home Page Reader oder das JAWS-Sprachausgabeprogramm, zusammen mit diesen Benutzerhandbüchern verwenden.
Verwenden Sie zum Ändern der Schriftgrößen in den Benutzerhandbüchern die Funktion, die in Ihrem Browser enthalten ist. Sie finden diese Funktion normalerweise im Menü Ansicht.
Benutzer, die über die Tastatur navigieren müssen, finden unter "Swing Key Bindings" (http://www-128.ibm.com/developerworks/java/jdk/additional/) eine Beschreibung von nützlichen Tastatureingaben für Swing-Anwendungen.
|Zusätzlich zur GUI verfügt das iKeyman-Tool über das Befehlszeilentool IKEYCMD, das dieselben Funktionen wie die iKeyman-GUI aufweist. Mit IKEYCMD können Sie Schlüssel, Zertifikate und Zertifikatsanforderungen verwalten. Sie können IKEYCMD über native Shell-Scripts und Programme aufrufen, die verwendet werden sollen, wenn Anwendungen benutzerdefinierte Schnittstellen zu Zertifikaten und wichtigen Verwaltungstasks hinzufügen müssen. IKEYCMD kann für alle Typen, die zurzeit von iKeyman unterstützt werden, Schlüsseldateien erstellen. IKEYCMD kann auch Zertifikatsanforderungen erstellen, CA-signierte Zertifikate importieren und selbstsignierende Zertifikate verwalten.
Geben Sie zum Ausführen eines IKEYCMD-Befehls Folgendes ein:
java [-Dikeycmd.properties=<Merkmaldatei>]com.ibm.gsk.ikeyman.ikeycmd <Objekt> <Aktion> [Optionen]
Dabei gilt Folgendes:
Weitere Informationen finden Sie im Handbuch "iKeyman User Guide" unter http://www.ibm.com/developerworks/java/jdk/security/index.html.
Beim Blättern in der Dropdown-Liste einer JComboBox-Komponente mit den Cursortasten kann der Wert mit Hilfe des Knopfs oder des editierbaren Felds des Kombinationsfelds nicht geändert werden, solange ein Element ausgewählt ist. Mit diesem für dieses Release gewünschten Verhalten verbessern sich Eingabehilfen und Benutzerfreundlichkeit, da sichergestellt wird, dass das Verschieben des Eingabefokus per Tastatur dem Verschieben des Eingabefokus per Maus entspricht.
In IBM Java Web Start V5.0 wurden im Vergleich zum vorherigen Release Eingabehilfen und Benutzerfreundlichkeit verbessert. Dazu gehören z. B. eine bessere Unterstützung für Sprachausgabeprogramme und eine bessere Navigation über die Tastatur.
Sie können die Befehlszeile nur zum Starten einer Java-Anwendung verwenden, die für Web Start aktiviert ist. Zum Ändern von Einstellungsoptionen müssen Sie die Konfigurationsdatei Application Data\IBM\Java\Deployment\deployment.properties im Ausgangsverzeichnis des Benutzers editieren. Sichern Sie die Datei, bevor Sie sie editieren. Nicht alle Einstellungen, die in Java Application Cache Viewer festgelegt werden können, sind in der Konfigurationsdatei verfügbar.
Uneingeschränkte JCE-Richtliniendateien finden Sie unter http://www.ibm.com/developerworks/java/jdk/security/index.html. Auf dieser Website finden Sie auch die Dokumentation zu den IBM Sicherheitspaketen JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS und JAAS sowie zur Hardwareverschlüsselung.
In IBM 32-bit SDK for Windows, v5.0 sind folgende Einschränkungen zu beachten:
Wenn diese Ausnahmebedingung angezeigt wird, können Sie durch Festlegen des Systemmerkmals java.nio.debug=pipe anzeigen, welche Portnummern blockiert werden.
Wenn Sie Ihren Kommentar zur Zweckmäßigkeit oder zu anderen Eigenschaften dieses Benutzerhandbuchs mitteilen möchten, können Sie sich über eine der im Folgenden aufgeführten Möglichkeiten an uns wenden. Beachten Sie, dass diese Mitteilungswege nicht eingerichtet wurden, um technische Fragen zu beantworten. Sie sind nur für Kommentare zur Dokumentation bestimmt. Senden Sie Ihre Kommentare an folgende Adresse:
Das Kleingedruckte. Wenn Sie eine Nachricht an IBM senden, erklären Sie sich einverstanden, dass alle in Ihrer Nachricht enthaltenen Informationen, einschließlich der Rückmeldedaten, wie beispielsweise Fragen, Kommentare, Anregungen o. Ä., nicht vertraulich behandelt werden und dass IBM keinerlei Verpflichtungen in Bezug auf diese Informationen hat und diese uneingeschränkt abdrucken, verwenden, veröffentlichen und an andere weitergeben kann. Des Weiteren kann IBM in diesen Informationen enthaltene Ideen, Konzepte oder Angaben zu Know-how oder technischen Verfahren uneingeschränkt und für beliebige Zwecke verwenden, u. a. für die Entwicklung, die Produktion und das Marketing von Produkten, die diese Informationen enthalten.
Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden. Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Komponenten in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim IBM Ansprechpartner erhältlich. Hinweise auf IBM Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Services von IBM verwendet werden können. An Stelle der IBM Produkte, Programme oder Services können auch andere ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerblichen oder anderen Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Fremdprodukten, Fremdprogrammen und Fremdservices liegt beim Kunden.
Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Handbuchs ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf Englisch formuliert werden):
Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen oder in Technical News Letters (TNLs) bekannt gegeben. IBM kann jederzeit ohne Vorankündigung Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.
Verweise in diesen Informationen auf Websites anderer Anbieter dienen lediglich als Benutzerinformationen und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.
Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.
Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:
Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.
Die Lieferung des in der Informationsdatei aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt im Rahmen der Allgemeinen Geschäftsbedingungen der IBM oder einer äquivalenten Vereinbarung.
Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer gesteuerten Umgebung. Die Ergebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier erzielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklung noch nicht abgeschlossen ist. Eine Gewährleistung, dass diese Daten auch in allgemein verfügbaren Systemen erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständen durch Extrapolation berechnet. Die tatsächlichen Ergebnisse können abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
IBM ist in gewissen Ländern eine Marke der International Business Machines Corporation.
Java und alle Java-basierten Marken und Logos sind in gewissen Ländern Marken oder eingetragene Marken von Sun Microsystems, Inc.
Microsoft, Windows und das Windows-Logo sind in gewissen Ländern Marken der Microsoft Corporation.
Andere Namen von Unternehmen, Produkten oder Dienstleistungen können Marken oder Dienstleistungsmarken anderer Unternehmen sein.
Dieses Produkt basiert auch teilweise auf der Arbeit zum Projekt FreeType. Weitere Informationen zu Freetype finden Sie unter http://www.freetype.org.
Dieses Produkt enthält Software, die von der Apache Software Foundation (http://www.apache.org/) entwickelt wurde.