Date: 2005-10-18

# IBM SDK and Runtime Environment for Linux platforms, Java 2 Technology Edition, Version 5.0

# Benutzerhandbuch

# Copyrightvermerk

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 Linux on Intel architecture, Java 2 Technology Edition, Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux on AMD64/EM64T architecture, Java 2 Technology Edition, Version 5.0
- IBM 32-bit SDK and Runtime Environment for Linux on iSeries and pSeries, Java 2 Technology Edition, Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux on iSeries and pSeries, Java 2 Technology Edition, Version 5.0
- IBM 31-bit SDK and Runtime Environment for Linux on zSeries, Java 2 Technology Edition, Version 5.0
- IBM 64-bit SDK and Runtime Environment for Linux on zSeries, Java 2 Technology Edition, Version 5.0

Weiterhin bezieht sich diese Ausgabe des Benutzerhandbuchs auf alle nachfolgenden Releases und Änderungen 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.

# Vorwort

In diesem Benutzerhandbuch erhalten Sie allgemeine Informationen zu IBM(R) SDK and Runtime Environment for Linux(TM) platforms, 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.

Unter der folgenden Adresse finden Sie eine Liste der Distributionen, unter denen SDK und Runtime Environment for Linux getestet wurden: http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html

Das Handbuch Diagnostics Guide enthält weitere Informationen zu IBM Virtual Machine für Java.

Die Begriffe "Runtime Environment" und "Java Virtual Machine" sind in diesem Handbuch gleichbedeutend.

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.

# Inhaltsverzeichnis

Copyrightvermerk
Vorwort
Übersicht
Konventionen
Versionskompatibilität
Ausführen eines Upgrades für SDK
Migrieren von weiteren IBM JVMs
| |
Unterstützte Hardware für zSeries
Inhalt von SDK und Runtime Environment
Runtime Environment-Tools
SDK-Tools
Installieren und Konfigurieren von SDK und Runtime Environment
Installieren unter Red Hat Enterprise Linux (RHEL) 4
| |
Installieren von 32-Bit-SDK auf 64-Bit-Architektur
Installieren über eine RPM-Datei
Installieren über eine TGZ-Datei
Konfigurieren von SDK und Runtime Environment for Linux
Festlegen der Umgebungsvariablen PATH
Festlegen der Umgebungsvariablen CLASSPATH
Deinstallieren von SDK und Runtime Environment for Linux
Deinstallieren des RPM-Pakets (Red Hat Package Manager)
Deinstallieren des komprimierten TAR-Pakets (Tape Archive)
Verwenden von Runtime Environment
Optionen
Angeben von Java-Optionen und Systemmerkmalen
Standardoptionen
Vom Standard abweichende Optionen
Abrufen der IBM Build- und Versionsnummer
Globalisierung des Befehls 'java'
JIT-Compiler (Just-In-Time)
Inaktivieren des JIT-Compilers
Aktivieren des JIT-Compilers
Prüfen, ob der JIT-Compiler aktiviert ist
Angeben der Garbage-Collection-Richtlinie
Optionen der Garbage-Collection
Pausezeit
Verringerung der Pausezeit
Umgebungen mit sehr vollen Freispeichern
Signalverarbeitung durch JVM
Von JVM verwendete Signale
Verbinden eines nativen Codetreibers mit der Signalverkettungsbibliothek
Verwenden der Funktion 'floating stacks'
Umwandeln von XML-Dokumenten
Verwenden einer älteren Version von Xerces oder Xalan
Verwenden von SDK zur Entwicklung von Java-Anwendungen
Debugging in Java-Anwendungen
Java-Debugger (JDB)
Ermitteln, ob eine Anwendung auf JVM im 32-Bit- oder 64-Bit-Modus ausgeführt wird
Schreiben von JNI-Anwendungen
| |
Unterstützung für die Wiederherstellung von blockierten Verbindungen auf Threadebene
Arbeiten mit Applets
Ausführen von Applets mit Applet Viewer
Debugging von Applets mit Applet Viewer
| |
Konfigurieren einer Speicherzuordnung von großen Seiten
CORBA-Unterstützung
Unterstützung für GIOP 1.2
Unterstützung für portierbare Abfangprozesse
Unterstützung für den Interoperable Naming Service
Systemmerkmale für die ORB-Tracefunktion
Systemmerkmale zur Optimierung des ORB
Java 2-Sicherheitsberechtigungen für den ORB
ORB-Implementierungsklassen
RMI-IIOP
Implementieren des Steuerroutinenpools für RMI-Verbindungen
Erweiterte BiDirectional-Unterstützung
Funktionale Erweiterungen für BigDecimal
Unterstützung des Euro-Symbols
Verwenden der Java Communications API (JavaComm)
Installieren der Java Communications API
Speicherposition der Java Communications API-Dateien
Konfigurieren der Java Communications API
Ändern des Zugriffsmodus für den seriellen Anschluss und den Parallelanschluss
Aktivieren von seriellen Anschlüssen auf IBM ThinkPads
Einschränkung beim Drucken mit der Java Communications API
Deinstallieren der Java Communications API
Deinstallieren des RPM-Pakets (Red Hat Package Manager)
Deinstallieren des komprimierten TAR-Pakets (Tape Archive)
Dokumentation zur Java Communications API
Implementieren von Java-Anwendungen
(Nur Linux IA (32 Bit) und PPC32) Verwenden des Java-Plug-ins
Unterstützte Browser
Installieren und Konfigurieren des Java-Plug-ins
Allgemeine Dokumentobjektmodellunterstützung (Document Object Model, DOM)
Verwenden von DBCS-Parametern
(nur Linux IA (32 Bit), PPC32 und PPC64) Verwenden von Java Web Start
Ausführen von Java Web Start
Ausliefern von Java-Anwendungen
| |
Gemeinsame Nutzung von Klassendaten auf verschiedenen JVMs
| |
Übersicht über die gemeinsame Nutzung von Klassen
| |
Cache-Inhalte
| |
Dynamisches Aktualisieren des Caches
| |
Aktivieren der gemeinsamen Nutzung von Klassen
| |
Cache-Sicherheit
| |
Lebensdauer des Caches
| |
Cache-Dienstprogramme
| |
Verwenden von Befehlszeilenoptionen für die gemeinsame Nutzung von Klassen
| |
Erstellen, Belegen, Überwachen und Löschen eines Caches
| |
Leistung und Speicherbelegung
| |
Einschränkungen und besondere Aspekte bei der gemeinsamen Nutzung von Klassen
| |
Grenzwerte für die Cachegröße
| |
Änderungen bei Laufzeitbytecodes
| |
Betriebssystemeinschränkungen
| |
Verwenden von SharedClassPermission
| |
Anpassen benutzerdefinierter Klassenladeprogramme an gemeinsam genutzte Klassen
Service und Unterstützung für unabhängige Softwareanbieter
Eingabehilfen
iKeyman-Eingabehilfen
Verschieben des Eingabefokus von JComboBox-Komponenten in Swing per Tastatur
(nur Linux IA (32 Bit), PPC32 und PPC64) Web Start-Eingabehilfen
Bekannte Einschränkungen
Einschränkungen, die für alle Linux-Plattformen gelten (wenn nicht anders angegeben)
Einschränkungen für Linux IA (32 Bit)
Einschränkungen für Linux AMD64
Einschränkungen für Linux PPC (32 Bit) und (64 Bit)
Einschränkungen für Linux PPC (64 Bit)
Einschränkungen für Linux zSeries (64 Bit)
Einschränkungen für Linux zSeries (31 und 64 Bit)
Kommentare zu diesem Handbuch
Bemerkungen
Marken

# Übersicht

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 Linux. 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. Dateien mit der Erweiterung .so, bei denen kein Debugging möglich ist, und 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 Linux enthält kein Entwicklungstool, wie z. B. appletviewer oder den Java-Compiler (javac), bzw. keine Klassen, die nur für Entwicklungssysteme konzipiert sind.

Außerdem wird das Paket mit der Java Communications API für IA32-, PPC32- und AMD64/EM64T-Plattformen zur Verwendung mit Runtime Environment for Linux bereitgestellt. Informationen hierzu finden Sie unter Verwenden der Java Communications API (JavaComm).

Die Datei license_xx.html enthält die Lizenzvereinbarung für Runtime Environment for Linux-Software. (xx ist eine Abkürzung für die jeweilige Sprache.) Öffnen Sie diese Datei in einem Web-Browser, um die Lizenzvereinbarung anzuzeigen oder zu drucken.

## Konventionen

In diesem Benutzerhandbuch lautet das Standardinstallationsverzeichnis von SDK: /opt/ibm/java2-i386-50/. Die unten aufgeführten Plattformen haben verschiedene Standardinstallationsverzeichnisse. Verwenden Sie das für Ihre Plattform entsprechende Verzeichnis, wenn /opt/ibm/java2-i386-50/ angezeigt wird:

- Linux IA (32 Bit): /opt/ibm/java2-i386-50/
- Linux AMD (64 Bit): /opt/ibm/java2-x86_64-50/
- Linux PPC (32 Bit): /opt/ibm/java2-ppc-50/
- Linux PPC (64 Bit): /opt/ibm/java2-ppc64-50/
- Linux zSeries (31 Bit): /opt/ibm/java2-s390-50/
- Linux zSeries (64 Bit): /opt/ibm/java2-s390x-50/

## Versionskompatibilität

Normalerweise müssten alle Applets oder Anwendungen, die mit einer Vorversion von SDK ausgeführt wurden, zusammen mit IBM SDK for Linux, 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.

Die Sun-Dokumentation zur Kompatibilität finden Sie auf der Sun-Website unter http://java.sun.com.

## Ausführen eines Upgrades für SDK

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.

## Migrieren von weiteren IBM JVMs

In Version 1.4.2 für AMD64/EM64T und Version 5 für die anderen Linux-Plattformen enthält IBM Runtime Environment for Linux 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:

- Die gemeinsam genutzte JVM-Bibliothek libjvm.so befindet sich im Verzeichnis jre/bin/j9vm. Dies ist nicht der Fall, wenn die Migration z. B. über Runtime Environment for Linux für Version 1.4.2 (für alle Plattformen außer AMD64/EM64T) ausgeführt wird. In diesem Fall lautet das Verzeichnis jre/bin/classic. Für native Anwendungen, die die JNI-Aufrufschnittstelle verwenden, muss der bzw. den zugehörigen Umgebungsvariablen möglicherweise der neue Verzeichnispfad hinzugefügt werden, damit die JVM-DLL-Datei gefunden wird.
- |Die JVMMI (JVM Monitoring Interface) ist nicht mehr verfügbar. |Sie müssen Anwendungen, die diese API verwenden, neu schreiben. Es wird empfohlen, stattdessen die JVMTI (JVM Tool Interface) zu verwenden. Die JVMTI entspricht funktional nicht der JVMMI. Weitere Informationen zur JVMTI finden Sie unter http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ und im Handbuch Diagnostics Guide.
- |Die neue Implementierung von JNI entspricht der JNI-Spezifikation, unterscheidet sich jedoch von der alten Implementierung. Sie gibt Kopien der Objekte zurück, anstatt die ursprünglichen Objekte im Speicher zu belassen. Dieser Unterschied kann zu Fehlern im JNI-Anwendungscode führen. Informationen zum Debugging von JNI-Code finden Sie unter -Xcheck:jni im Abschnitt Vom Standard abweichende Optionen.
- |Format und Inhalt von ausführlichen Garbage-Collector-Protokollen, die mit Hilfe von -verbose:gc empfangen wurden, wurden geändert. Die Daten weisen jetzt das XML-Format auf. Der Dateninhalt zeigt die Änderungen der Implementierung der Garbage-Collection in JVM an. Die meisten statistischen Ausgabedaten wurden geändert. |Sie müssen alle Programme ändern, die die ausführliche GC-Ausgabe verarbeiten, damit diese Programme mit dem neuen Format und den neuen Daten funktionieren. Im Handbuch Diagnostics Guide finden Sie ein Beispiel der neuen ausführlichen GC-Daten.
- Frühere IBM JRE-Versionen wurden zusammen mit der Datei rt.jar geliefert, die sich im Verzeichnis jre/lib befindet. Ab Java Version 1.4 wurde diese Datei durch mehrere JAR-Dateien ersetzt, die sich im Verzeichnis jre/lib befinden.
- |Weitere Informationen zur Kompatibilität und zu veralteten APIs in Bezug auf Sun-Java-Releases finden Sie in den Dokumenten Sun's Java 5 Compatibility Documentation und Sun's Java 5 Depreciated API List.

| | |

## Unterstützte Hardware für zSeries

|

Die 31-Bit- und 64-Bit-SDKs und Runtime Environments von zSeries werden auf den folgenden System z9- und zSeries-Servern oder funktional entsprechenden Servern ausgeführt:

|

|
- z9-109
|
- z990
|
- z900
|
- z890
|
- z800

# Inhalt von SDK und Runtime Environment

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.

## Runtime Environment-Tools

- Wichtige Klassen -- Dies sind die kompilierten Klassendateien für die Plattform. Sie müssen komprimiert bleiben, damit der Compiler und der Interpreter auf sie zugreifen können. Ändern Sie diese Klassen nicht, sondern erstellen Sie stattdessen Unterklassen, und überschreiben Sie diese, falls erforderlich.
- JRE-Tools -- Die folgenden Tools sind Teil von Runtime Environment. Sofern nichts anderes angegeben ist, befinden sie sich im Verzeichnis jre/bin.
  - java (Java-Interpreter)
    - Führt Java-Klassen aus. Der Java-Interpreter führt Programme aus, die in der Programmiersprache Java geschrieben sind.
  - javaw (Java-Interpreter)
    - Führt Java-Klassen genauso aus wie der Befehl java, verwendet jedoch kein Konsolfenster.
  - keytool (Tool für das Schlüssel- und Zertifikatmanagement)
    - Verwaltet einen Schlüsselspeicher (Datenbank) mit privaten Schlüsseln und den ihnen zugeordneten X.509-Zertifikatketten, die die entsprechenden öffentlichen Schlüssel authentifizieren.
  - policytool (Tool für die Erstellung und das Management von Richtliniendateien)
    - Erstellt und ändert die externen Richtlinienkonfigurationsdateien, die die Java-Sicherheitsrichtlinie Ihrer Installation definieren.
  - rmid (Systemdämon für die RMI-Aktivierung)
    - Startet den Aktivierungssystemdämon, so dass Objekte in JVM (Java Virtual Machine) registriert und aktiviert werden können.
  - tnameserv (CORBA Naming Service (CORBA - Common Object Request Broker Architecture))
    - Startet den CORBA Transient Naming Service.
  - rmiregistry (Java-Registrierungsdatenbank für ferne Objekte)
    - Erstellt und startet eine Registrierungsdatenbank für ferne Objekte an dem angegebenen Port des aktuellen Hosts.
  - ikeyman (iKeyman-GUI-Dienstprogramm)
    - Ermöglicht das Verwalten von Schlüsseln, Zertifikaten und Zertifikatsanforderungen. Weitere Informationen finden Sie im zugehörigen Handbuch Security Guide und unter http://www.ibm.com/developerworks/java/jdk/security. SDK enthält auch eine Befehlszeilenversion dieses Dienstprogramms. Weitere Informationen hierzu finden Sie im Abschnitt iKeyman-Eingabehilfen.
  - jextract (Extrahierungsprogramm für Speicherauszüge)
    - Konvertiert einen vom System erstellten Speicherauszug in ein einheitliches Format, das von jdmpview verwendet werden kann. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
  - (nur Linux IA (32 Bit), PPC32 und PPC64) javaws (Java Web Start)
    - Ermöglicht die Implementierung und automatische Verwaltung von Java-Anwendungen.
  - (nur Linux IA (32 Bit), PPC32 und PPC64) |updateSettings.sh (Einstellungen von Java Web Start)
    - Konfiguriert Ihr System so, dass Web Start mit Ihrem Browser verwendet werden kann. Weitere Informationen finden Sie im Abschnitt Ausführen von Java Web Start. Diese Datei ist im Verzeichnis jre/lib/javaws installiert.

## SDK-Tools

- Die folgenden Tools sind Teil von SDK und befinden sich im Verzeichnis /opt/ibm/java2-i386-50/bin :
  - javac (Java-Compiler)
    - Kompiliert Programme, die in der Programmiersprache Java in Bytecodes (kompilierter Java-Code) geschrieben werden.
  - appletviewer (Java Applet Viewer)
    - Testet und führt Applets außerhalb eines Web-Browsers aus.
  - jdb (Java-Debugger)
    - Hilft beim Debugging Ihres Java-Programms.
  - javap (Disassembler für Klassendateien)
    - Zerlegt kompilierte Dateien und kann eine Darstellung der Bytecodes drucken.
  - javadoc (Java-Dokumentationsgenerator)
    - Generiert HTML-Seiten der API-Dokumentation über Java-Quellendateien.
  - javah (C-Header- und Stubdateigenerator)
    - Ermöglicht die Zuordnung nativer Methoden zu Code, der in der Programmiersprache Java geschrieben wurde.
  - jar (Java-Archivierungstool)
    - Kombiniert mehrere Dateien in einer einzelnen JAR-Datei (Java Archive).
  - jarsigner (Tool zur JAR-Signierung und -Prüfung)
    - Generiert Signaturen für JAR-Dateien und prüft die Signaturen der signierten JAR-Dateien.
  - jconsole (JConsole - experimentelles Überwachungs- und Verwaltungstool)
    - Experimentelles (nicht unterstütztes) JMX-kompatibles grafisches Tool zur Überwachung von lokalen und fernen JVMs.
  - native2ascii (Native-zu-ASCII-Converter)
    - Konvertiert eine native Codierungsdatei in eine ASCII-Datei, die Zeichen enthält, die in Latin-1 und/oder Unicode codiert sind.
  - rmic (Java-RMI-Stub-Converter (RMI - Remote Method Invocation))
    - Generiert Stubs, Entwürfe und Ties für ferne Objekte. Umfasst Unterstützung für RMI-IIOP (RMI over Internet Inter-ORB Protocol).
  - java-rmi.cgi (HTTP-zu-CGI-Anforderungsweiterleitungstool)
    - Akzeptiert RMI-über-HTTP-Anforderungen und leitet diese an einen RMI-Server weiter, der an einem beliebigen Port empfangsbereit ist.
  - idlj (IDL für Java-Compiler)
    - Generiert Java-Bindungen über eine festgelegte IDL-Datei.
  - serialver (Befehl für serialisierte Version)
    - Wandelt die serialVersionUID für mindestens eine Klasse in ein Format um, das in eine Klasse kopiert werden kann, die sich in einer zukünftigen Version ändert.
  - extcheck (Extcheck-Dienstprogramm)
    - Stellt Versionskonflikte zwischen einer JAR-Zieldatei und neu installierten JAR-Erweiterungsdateien fest.
  - jdmpview (plattformunabhängiges Formatierprogramm für Speicherauszüge)
    - Ein Tool, mit dem Sie Speicherauszüge analysieren können. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
  - (nur Linux IA (32 Bit), PPC32 und PPC64) htmlconverter (Java Plug-in HTML Converter)
    - Konvertiert eine HTML-Seite, in der Applets enthalten sind, in ein Format, das das Java-Plug-in verwenden kann.
- Include-Dateien
  - C-Header für JNI-Programme.
- Demos
  - Das Verzeichnis 'demo' enthält mehrere Unterverzeichnisse, in denen Musterquellcode, Demos, Anwendungen und Applets enthalten sind, die Sie verwenden können.
- Copyright
  - Copyrightvermerk für die SDK for Linux-Software.
- Lizenz
  - Die Lizenzdatei /opt/ibm/java2-i386-50/docs/<Ländereinstellung>/license_<Ländereinstellung>.html enthält die Lizenzvereinbarung für die SDK for Linux-Software (wobei <Ländereinstellung> die Bezeichnung Ihrer Ländereinstellung ist, wie z. B. DE_DE). Öffnen Sie diese Datei in einem Web-Browser, um die Lizenzvereinbarung anzuzeigen oder zu drucken.
- fixes.lst
  - Eine Textdatei mit Erläuterungen zu allen Fehlern, die nach dem ersten Release dieser Version korrigiert wurden.

Anmerkung: SDK for Linux 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.

# Installieren und Konfigurieren von SDK und Runtime Environment

Sie können IBM Java SDK und Runtime Environment über eine RPM- oder TGZ-Datei installieren. Führen Sie die Installation über die TGZ-Datei aus, außer wenn Sie allen Benutzern auf dem System den Zugriff auf diese Java-Installation erteilen wollen. Wenn Sie nicht über Rootzugriff verfügen, verwenden Sie die TGZ-Datei.

Wenn Sie die Installation mit Hilfe einer RPM-Datei ausführen, werden die Java-Dateien im Verzeichnis /opt/ibm/java2-i386-50/ installiert. Bei den Beispielen im vorliegenden Handbuch wird davon ausgegangen, dass Sie Java in diesem Verzeichnis installiert haben.

## Installieren unter Red Hat Enterprise Linux (RHEL) 4

SDK ist von gemeinsam genutzten Bibliotheken abhängig, die nicht standardmäßig für Red Hat Enterprise Linux (RHEL) 4.0 installiert werden.

Die RPMs, die diese Bibliotheken enthalten, lauten:

- `compat-libstdc++-33-3.2.3` und `xorg-x11-deprecated-libs-6.8.1` (Intel Architecture, PPC und PPC64)
- `compat-libstdc++-295-2.95.3` und `xorg-x11-deprecated-libs-6.8.1` (zSeries)

Gehen Sie wie folgt vor, um diese Bibliotheken während der Installation von RHEL 4 aufzunehmen:

1. Wenn Sie die Anzeige Package Defaults erreichen, wählen Sie die Option Customize the set of packages to be installed aus.
2. Wählen Sie in der Anzeige Package Group Selection unter X Windows System die Option Details aus, und stellen Sie sicher, dass `xorg-x11-deprecated-libs` ausgewählt ist.
3. Wählen Sie unter den Development-Optionen Legacy Software Development aus.

| | |

## Installieren von 32-Bit-SDK auf 64-Bit-Architektur

|

Zum Ausführen von SDK müssen Sie die richtigen Versionen aller für SDK erforderlichen Bibliotheken installieren (32 oder 64 Bit).

|

In RHEL4 sind die 64-Bit-Versionen der Pakete in der Paketgruppe Compatibility Arch Support verfügbar.

|

Sie können das Tool RPM verwenden, um zu überprüfen, welche Versionen des Pakets Sie installiert haben. Fügen Sie dazu dem RPM-Befehl die Option `--queryformat "%{NAME}.%{ARCH}\n"` hinzu. Beispiel:

|

    /home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++
    |libstdc++.x86_64
    |libstdc++.i386

## Installieren über eine RPM-Datei

1. Rufen Sie eine Shelleingabeaufforderung auf, und stellen Sie sicher, dass Sie als Root angemeldet sind.

2. Geben Sie an einer Shelleingabeaufforderung `rpm -ivh <RPM-Datei>` ein. Beispiel:

       |rpm -ivh ibm-java2-<Architektur>-sdk-5.0-0.0.<Architektur>.rpm

   oder

       |rpm -ivh ibm-java2-<Architektur>-jre-5.0-0.0.<Architektur>.rpm

   |Dabei steht `<Architektur>` für Ihre Architektur: |i386, x86_64, ppc, ppc64, s390 oder s390x.

## Installieren über eine TGZ-Datei

1. Erstellen Sie ein Verzeichnis, in dem die Java-Paketdateien gespeichert werden sollen. Bei den Beispielen im vorliegenden Handbuch wird davon ausgegangen, dass Sie sie im Verzeichnis /opt/ibm/java2-i386-50/ installiert haben. Ersetzen Sie /opt/ibm/java2-i386-50/ im übrigen Handbuch durch das Verzeichnis, in dem Sie Java installiert haben.

2. Geben Sie an einer Shelleingabeaufforderung `tar -zxvf <TGZ-Datei>` ein. Beispiel:

       |tar -zxvf ibm-java2-sdk-50-linux-<Architektur>.tgz

   oder

       |tar -zxvf ibm-java2-jre-50-linux-<Architektur>.tgz

   |Dabei steht `<Architektur>` für Ihre Architektur: |i386, x86_64, ppc, ppc64, s390 oder s390x.

## Konfigurieren von SDK und Runtime Environment for Linux

### Festlegen der Umgebungsvariablen PATH

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 Linux im Verzeichnis /opt/ibm/java2-i386-50/bin installiert ist, können Sie eine Datei mit dem Namen MeineDatei.java kompilieren, indem Sie Folgendes an einer Shelleingabeaufforderung eingeben:

      /opt/ibm/java2-i386-50/bin/javac MeineDatei.java

Gehen Sie wie folgt vor, um die Umgebungsvariable PATH zu ändern:

1. Editieren Sie die Shellstartdatei im Ausgangsverzeichnis (normalerweise .bashrc, je nach der von Ihnen verwendeten Shell), und fügen Sie der Umgebungsvariablen PATH die absoluten Pfade hinzu. Beispiel:

       export PATH=/opt/ibm/java2-i386-50/bin:/opt/ibm/java2-i386-50/jre/bin:$PATH

2. Melden Sie sich erneut an, oder führen Sie das aktualisierte Shell-Script aus, um die neue Einstellung der Umgebungsvariablen PATH zu aktivieren.

### Festlegen der Umgebungsvariablen CLASSPATH

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:

- Sie benötigen eine andere Bibliothek oder Klassendatei (z. B. eine, die Sie entwickeln), und diese befindet sich nicht im aktuellen Verzeichnis.
- Sie ändern die Speicherposition der Verzeichnisse bin und lib, sodass sie sich nicht mehr im selben übergeordneten Verzeichnis befinden.
- Sie wollen Anwendungen entwickeln oder ausführen, die unterschiedliche Laufzeitumgebungen auf demselben System verwenden.

Geben Sie zum Anzeigen des aktuellen Werts der Umgebungsvariablen CLASSPATH Folgendes an einer Shelleingabeaufforderung 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 einer separaten Shell ausgeführt werden.

Wenn Sie nur jeweils eine Version von Java ausführen wollen, können Sie mit Hilfe eines Shell-Scripts zwischen den verschiedenen Laufzeitumgebungen umschalten.

Anmerkung:
(Nur für chinesische Benutzer von Linux IA, 32 Bit) Auf Grund der Inkonsistenz der Verschlüsselungen von Schriftarten auf dem Red Hat Advanced Server ist es bei der Installation für eine Umgebung, in der Chinesisch die voreingestellte Sprache sein soll, von Vorteil, bei der Installation Englisch als voreingestellte Sprache festzulegen und sie nach Abschluss der Installation in Chinesisch zu ändern. Andernfalls werden chinesische Zeichen möglicherweise nicht angezeigt.

## Deinstallieren von SDK und Runtime Environment for Linux

Der Prozess, den Sie zum Entfernen von SDK und Runtime Environment for Linux verwenden, ist vom verwendeten Installationstyp abhängig. Anweisungen hierzu finden Sie im Abschnitt Deinstallieren des RPM-Pakets (Red Hat Package Manager) oder Deinstallieren des komprimierten TAR-Pakets (Tape Archive).

### Deinstallieren des RPM-Pakets (Red Hat Package Manager)

Gehen Sie zum Deinstallieren von SDK oder Runtime Environment for Linux folgendermaßen vor, falls Sie das installierbare RPM-Paket installiert haben:

1. Geben Sie an einer Shelleingabeaufforderung Folgendes ein,
   1. wenn Sie überprüfen möchten, welche RPM-Pakete Sie installiert haben:

          rpm -qa | grep -i java

   2. Daraufhin wird eine Liste aller IBM Java-Pakete angezeigt, die Sie installiert haben. Beispiel:

          ibm-java2-<Architektur>-jre-5.0-0.0.<Architektur>
          ibm-java2-<Architektur>-sdk-5.0-0.0.<Architektur>

   3. Über diese Ausgabe erfahren Sie, welche Pakete Sie mit dem Befehl `rpm -e` deinstallieren können. Beispiel:

          rpm -e ibm-java2-<Architektur>-jre-5.0-0.0.<Architektur>
          rpm -e ibm-java2-<Architektur>-sdk-5.0-0.0.<Architektur>

   Sie können auch ein grafisches Tool verwenden, wie beispielsweise kpackage oder yast2.
2. Entfernen Sie das Verzeichnis, in dem Sie SDK und Runtime Environment installiert haben, aus der Anweisung PATH.

3. (nur Linux IA (32 Bit) und PPC32) Wenn Sie das Java-Plug-in installiert haben, entfernen Sie die Java-Plug-in-Dateien aus dem Web-Browser-Verzeichnis.

### Deinstallieren des komprimierten TAR-Pakets (Tape Archive)

Gehen Sie zum Deinstallieren von SDK oder Runtime Environment for Linux folgendermaßen vor, wenn Sie das komprimierte TAR-Paket extrahiert haben:

1. Entfernen Sie die SDK- oder Runtime Environment-Dateien aus dem Verzeichnis, in dem Sie SDK oder Runtime Environment installiert haben.

2. Entfernen Sie das Verzeichnis, in dem Sie SDK oder Runtime Environment installiert haben, aus der Anweisung PATH.

3. Melden Sie sich erneut an, oder führen Sie das aktualisierte Shell-Script aus, um die neue Einstellung der Umgebungsvariablen PATH zu aktivieren.

4. (nur Linux IA (32 Bit) und AMD64/EM64T) Wenn Sie das Java-Plug-in installiert haben, entfernen Sie die Java-Plug-in-Dateien aus dem Web-Browser-Verzeichnis.

# Verwenden von Runtime Environment

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.

Optionen
  Befehlszeilenoptionen.
Klasse
  Der Name der Klasse, die aufgerufen werden soll.
Datei.jar
  Der Name der JAR-Datei, die aufgerufen werden soll. Sie wird nur mit der Option -jar verwendet.
Argumente
  Die Argumente, die an die Funktion main weitergeleitet werden.

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.

## Optionen

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.

### Angeben von Java-Optionen und Systemmerkmalen

Sie können Java-Optionen und Systemmerkmale auf drei verschiedene Arten angeben. Diese sind im Folgenden aufgelistet (nach Priorität):

1. Durch Angeben der Option oder des Merkmals in der Befehlszeile. Beispiel:`java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MeineJavaKlasse`.

2. Durch Erstellen einer Datei, die die Optionen enthält, und Angeben der Datei in der Befehlszeile mit -Xoptionsfile=<Dateiname>.

3. Durch Erstellen einer Umgebungsvariablen namens IBM_JAVA_OPTIONS mit den Optionen, z. B. `export IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"`.

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.

### Standardoptionen

- -D<Merkmalname>=<Wert>
  - Definiert ein Systemmerkmal.
- -assert
  - Zeigt Hilfe für auf Festlegungen bezogene Optionen an.
- -cp oder -classpath <durch : getrennte Verzeichnisse und ZIP- oder JAR-Dateien>
  - Definiert den Suchpfad für Anwendungsklassen und -ressourcen. Wenn die Optionen -classpath und -cp nicht verwendet werden und wenn CLASSPATH nicht definiert wurde, ist der Benutzerklassenpfad standardmäßig das aktuelle Verzeichnis (.).
- -help oder -?
  - Zeigt einen Benutzungshinweis an.
- -showversion
  - Zeigt die Produktversion an und setzt den Vorgang fort.
- -verbose:[class,gcterse,gc,dynload,stackwalk,sizes,stack,debug,jni]
  - Aktiviert die ausführliche Ausgabe.
- -version
  - Zeigt die Produktversion an.
- -version:<Wert>
  - Setzt voraus, dass die angegebene Version ausgeführt wird.
- -jre-restrict-search
  - Nimmt private Benutzer-JREs in die Versionssuche auf.
- -no-jre-restrict-search
  - Schließt private Benutzer-JREs von der Versionssuche aus.
- -agentlib:<Bibliotheksname>[=<Optionen>]
  - Lädt die native Agentenbibliothek <Bibliotheksname>, z. B. -agentlib:hprof. Geben Sie -agentlib:jdwp=help und -agentlib:hprof=help in der Befehlszeile an, um weitere Informationen zu erhalten.
- -agentpath: Bibliotheksname[=<Optionen>]
  - Lädt die native Agentenbibliothek mit dem vollständigen Pfadnamen.
- -javaagent:<JAR-Pfad>[=<Optionen>]
  - Lädt den Java-Programmiersprachenagenten. Weitere Informationen finden Sie in der Dokumentation zur API java.lang.instrument.
- -X
  - Zeigt Hilfe für vom Standard abweichende Optionen an.

### Vom Standard abweichende Optionen

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.

- -Xargencoding
  - Mit dieser Option können Sie Unicode-Escapezeichenfolgen in die Argumentenliste aufnehmen. Sie ist standardmäßig inaktiviert.
- -Xbootclasspath:<durch ; getrennte Verzeichnisse und ZIP- oder JAR-Dateien>
  - Definiert den Suchpfad für Bootklassen und -ressourcen. Standardmäßig wird in den internen VM-Verzeichnissen und JAR-Dateien nach Bootklassen und -ressourcen gesucht.
- -Xbootclasspath/a:<durch ; getrennte Verzeichnisse und ZIP- oder JAR-Dateien>
  - Fügt die angegebenen Verzeichnisse, ZIP- oder JAR-Dateien am Ende des Bootklassenpfads hinzu. Standardmäßig wird in den internen VM-Verzeichnissen und JAR-Dateien nach Bootklassen und -ressourcen gesucht.
- -Xbootclasspath/p:<durch ; getrennte Verzeichnisse und ZIP- oder JAR-Dateien>
  - Fügt die angegebenen Verzeichnisse, ZIP- oder JAR-Dateien am Anfang des Bootklassenpfads hinzu. Implementieren Sie keine Anwendungen, bei denen mit der Option -Xbootclasspath: oder -Xbootclasspath/p: eine Klasse in der Standard-API überschrieben wird, da eine solche Implementierung gegen die Java 2 Runtime Environment-Binärcodelizenz verstößt. Standardmäßig wird in den internen VM-Verzeichnissen und JAR-Dateien nach Bootklassen und -ressourcen gesucht.
- -Xcheck:jni
  - Führt zusätzliche Prüfungen für JNI-Funktionen aus. Sie können auch die Option -Xrunjnichk verwenden. Standardmäßig wird keine Prüfung ausgeführt.
- -Xcheck:nabounds
  - Führt zusätzliche Prüfungen für JNI-Bereichsoperationen aus. Sie können auch die Option -Xrunjnichk verwenden. Standardmäßig wird keine Prüfung ausgeführt.
- |-Xclassgc |
  |
  - Erfasst Klassenobjekte bei jeder Garbage-Collection. |Diese Option ist standardmäßig aktiviert.
- -Xcompactexplicitgc
  - Komprimiert bei jedem Aufruf an `System.gc()`. Siehe auch -Xnocompactexplicitgc. Standardmäßig wird die Komprimierung nur ausgeführt, wenn sie intern ausgelöst wird.
- -Xcompactgc
  - Komprimiert alle Garbage-Collector-Zyklen. Siehe auch -Xnocompactgc. Standardmäßig wird die Komprimierung nur ausgeführt, wenn sie intern ausgelöst wird.
- |-Xconcurrentbackground <Anzahl> |
  |
  - Gibt die Anzahl der Hintergrundthreads mit niedriger Priorität an, die während der Garbage-Collection-Phase der gleichzeitigen Markierung zur Unterstützung der Mutator-Threads zugeordnet sind. Die Standardeinstellung lautet 1.
- |-Xconcurrentlevel <Zahl> |
  |
  - Gibt die Zuordnungsauslastungsrate an. Sie gibt das Verhältnis zwischen dem zugeordneten und dem markierten Freispeicher an. Die Standardeinstellung lautet 8.
- |-Xconmeter:<soa | loa | dynamic> |
  |
  - Legt fest, für welchen Speicherbereich (LOA oder SOA) die Belegung gemessen wird, und folglich, welche Zuordnungen während der gleichzeitigen Markierung belastet werden. Mit -Xconmeter:soa wird die Zuordnungsauslastung für Zuordnungen über den SOA (Small Object Area) und mit -Xconmeter:loa die Zuordnungsauslastung für Zuordnungen über den LOA (Large Object Area) verwendet. Wenn -Xconmeter:dynamic angegeben ist, legt der Collector dynamisch fest, welcher Bereich gemessen werden soll, basierend darauf, welcher Bereich (SOA oder LOA) zuerst ausgelastet ist. Standardmäßig ist die Option auf -Xconmeter:soa gesetzt.
- -Xdbg:<Optionen>
  - Lädt Debugbibliotheken, damit das ferne Debugging von Anwendungen unterstützt wird. Dies ist identisch mit -Xrunjdwp. Standardmäßig werden die Debugbibliotheken nicht geladen, und die VM-Instanz wird für das Debugging nicht aktiviert.
- -Xdbginfo:<Pfad zur Symboldatei>
  - Lädt und übergibt Optionen an den Debuginformationsserver. Der Debuginformationsserver ist standardmäßig inaktiviert.
- -Xdebug
  - Startet JVM mit aktiviertem Debugger. Der Debugger ist standardmäßig inaktiviert.
- |-Xdisableexcessivegc |
  |
  - Inaktiviert die Auslösung der Ausnahmebedingung `OutOfMemory`, wenn in der Garbage-Collection zu viel Zeit benötigt wurde. Diese Option ist standardmäßig inaktiviert.
- -Xdisableexplicitgc
  - Signalisiert VM, dass Aufrufe an `System.gc()` keine Auswirkung haben. Aufrufe an `System.gc()` lösen standardmäßig eine Garbage-Collection aus.
- |-Xdisablestringconstantgc |
  |
  - Verhindert, dass Zeichenfolgen in der zeichenfolgeninternen Tabelle erfasst werden. |Diese Option ist standardmäßig inaktiviert.
- -Xdisablejavadump
  - Inaktiviert die Generierung von Java-Speicherauszügen bei Fehlern und Signalen. Die Generierung von Java-Speicherauszügen ist standardmäßig aktiviert.
- |-Xenableexcessivegc |
  |
  - Wenn in der GC zu viel Zeit beansprucht wird, gibt diese Option für eine Zuordnungsanforderung NULL zurück, wodurch die Ausnahmebedingung `OutOfMemory` ausgelöst wird. Diese Aktion erfolgt nur, wenn der Freispeicher vollständig ausgelastet ist und die benötigte Zeit mindestens 95 % beträgt. Dies ist das Standardverhalten.
- |-Xenablestringconstantgc |
  |
  - Ermöglicht die Erfassung von Zeichenfolgen aus der internen Zeichenfolgentabelle. |Diese Option ist standardmäßig aktiviert.
- -Xfuture
  - Aktiviert genaue Formatprüfungen von Klassendateien. Verwenden Sie diese Option für die Entwicklung von neuem Code, da in den zukünftigen Releases standardmäßig genauere Prüfungen ausgeführt werden. Genaue Formatprüfungen sind standardmäßig inaktiviert.
- -Xgcpolicy:[optthruput]|[optavgpause]|[gencon]||[subpool] (Speicherteilbereich für PPC und zSeries)
  - Steuert das Verhalten des Garbage-Collectors. Die Option optthruput ist die Standardeinstellung und ermöglicht einen sehr hohen Anwendungsdurchsatz, wobei jedoch gelegentliche Pausen auftreten. Die Option optavgpause verringert die Zeit dieser Garbage-Collection-Pausen. Außerdem wird der Effekt eines höheren Freispeicherumfangs während der Garbage-Collection-Pause begrenzt. Verwenden Sie optavgpause, wenn Ihre Konfiguration über einen sehr großen Freispeicher verfügt. Die Option gencon fordert die kombinierte Verwendung von gleichzeitig ablaufendem GC und GC nach Objektalter an, um alle Garbage-Collection-Pausen zu verringern. |Die Option subpool verwendet einen verbesserten Algorithmus für die Objektzuordnung, um eine bessere Leistung beim Zuordnen von Objekten im Freispeicher zu erzielen. Diese Option kann Leistungssteigerungen auf großen SMP-Systemen ermöglichen. Weitere Informationen finden Sie im Abschnitt Angeben der Garbage-Collection-Richtlinie.
- -Xgcthreads<Anzahl Threads>
  - Definiert die Anzahl der Helper-Threads, die für Paralleloperationen während der Garbage-Collection verwendet werden. Standardmäßig entspricht die Anzahl Threads der Anzahl vorhandener physischer CPUs minus 1 (mindestens 1).
- |-Xgcworkpackets <Anzahl> |
  |
  - Gibt die Gesamtzahl der Vorgangspakete an, die im globalen Collector zur Verfügung stehen. Wenn keine Anzahl angegeben ist, ordnet der Collector auf Grundlage der maximalen Größe des Freispeichers eine Paketzahl zu.
- -Xint
  - Mit Hilfe dieser Option verwendet JVM nur den Interpreter. Der JIT-Compiler (Just-In-Time) wird inaktiviert. Der JIT-Compiler ist standardmäßig aktiviert.
- -Xiss<Größe>
  - Definiert die ursprüngliche Größe des Java-Thread-Stacks. Standardmäßig sind 2 Kilobyte angegeben.
- -Xjit[:<Unteroption>,<Unteroption>,...]
  - Aktiviert den JIT-Compiler. Weitere Informationen zu den Unteroptionen finden Sie im Handbuch Diagnostics Guide. Siehe auch -Xnojit. Der JIT-Compiler ist standardmäßig aktiviert.
- -Xlinenumbers
  - Zeigt Zeilennummern in Stack-Traces für das Debugging an. Siehe auch -Xnolinenumbers. Zeilennummern sind standardmäßig aktiviert.
- |-Xloa |
  |
  - Diese Option ordnet einen LOA (Large Object Area) zu. Objekte werden diesem LOA statt dem SOA zugeordnet. Standardmäßig ist der LOA für alle GC-Richtlinien aktiviert, mit Ausnahme des Speicherteilbereichs, in dem der LOA nicht verfügbar ist. Siehe auch -Xnoloa.
- |-Xloainitial <Zahl> |
  |
  - <Zahl> liegt zwischen 0 und 0,95 und gibt den Anfangsprozentsatz des aktuellen Bereichs für alte Objekte an, der dem LOA (Large Object Area) zugeordnet ist. Die Standardeinstellung lautet 0,05 oder 5 %.
- |-Xloamaximum <Zahl> |
  |
  - <Zahl> liegt zwischen 0 und 0,95 und gibt den maximalen Prozentsatz des aktuellen Bereichs für alte Objekte an, der dem LOA (Large Object Area) zugeordnet ist. Die Standardeinstellung lautet 0,5 oder 50 %.
- -Xlp
  - Fordert JVM auf, Java-Freispeicher mit großen Seiten zuzuordnen. Wenn keine großen Seiten zur Verfügung stehen, startet JVM nicht, und die folgende Fehlernachricht wird angezeigt: `GC: Systemkonfiguration unterstützt Option '-Xlp' nicht`. JVM verwendet shmget(), um dem Freispeicher große Seiten zuzuordnen. Große Seiten werden von Systemen unterstützt, die den Linux-Kernel ab Version 2.6 oder frühere Kernel ausführen, bei denen die Unterstützung großer Seiten nachträglich hinzugefügt wurde. Standardmäßig werden keine großen Seiten verwendet. Siehe Konfigurieren einer Speicherzuordnung von großen Seiten.
- -Xmaxe<Größe>
  - Definiert den Maximalwert, um den der Garbage-Collector den Freispeicher erweitert. Standardmäßig erweitert der Garbage-Collector den Freispeicher, wenn sich der freie Speicherbereich auf unter 30 % verringert (oder um den Wert, der mit -Xminf angegeben wurde). Der Freispeicher wird dann um den Wert erweitert, der für die Wiederherstellung von 30 % freiem Speicherbereich erforderlich ist. Die Option -Xmaxe begrenzt die Erweiterung auf den angegeben Wert. Beispielsweise begrenzt die Angabe von `-Xmaxe10M` die Erweiterung auf 10 MB. Standardmäßig ist keine maximale Größe für die Erweiterung angegeben.
- -Xmaxf<Größe>
  - Definiert den maximalen Prozentsatz des Freispeichers, der nach einer Garbage-Collection frei sein muss. Wenn der freie Speicherbereich diesen Prozentsatz überschreitet, versucht JVM, den Freispeicher zu verkleinern. Geben Sie die Größe als Dezimalwert im Bereich von 0-1 an. Z. B. setzt die Angabe `-Xmaxf0.5` den maximalen freien Speicherbereich auf 50 %. Der Standardwert lautet 0,6 (60 %).
- -Xmca<Größe>
  - Definiert den Erweiterungsschritt für den Speicher, der zum Speichern des Arbeitsspeicherabschnitts für geladene Klassen zugeordnet wurde. Wenn mehr Speicher zum Speichern von Klassen im Arbeitsspeicher erforderlich ist, wird der zugeordnete Speicher um diesen Wert erhöht. Standardmäßig lautet der Erweiterungsschritt 32 K.
- -Xmco<Größe>
  - Definiert den Erweiterungsschritt für den Speicher, der zum Speichern des ROM-Abschnitts für geladene Klassen zugeordnet wurde. Wenn mehr Speicher zum Speichern von Klassen im ROM erforderlich ist, wird der zugeordnete Speicher um diesen Wert erhöht. Standardmäßig lautet der Erweiterungsschritt 128 K.
- -Xmine<Größe>
  - Definiert den Mindestwert, um den der Garbage-Collector den Freispeicher erweitert. Standardmäßig erweitert der Garbage-Collector den Freispeicher um den Wert, der für die Wiederherstellung von 30 % freiem Speicherbereich erforderlich ist (oder um den Wert, der mit -Xminf angegeben wurde). Die Option -Xmine setzt die Erweiterung mindestens auf den angegebenen Wert. Beispielsweise wird mit der Angabe `-Xmine50M` eine Mindesterweiterungsgröße von 50 MB angegeben. Standardmäßig lautet die Erweiterungsgröße 1 MB.
- -Xminf<Größe>
  - Definiert den Mindestprozentsatz des Freispeichers, der nach einer Garbage-Collection frei sein sollte. Wenn der freie Speicherbereich diesen Wert unterschreitet, versucht JVM, den Freispeicher zu erweitern. Geben Sie die Größe als Dezimalwert zwischen 0 und 1 an. Mit `-Xminf0.3` z. B. wird freier Speicherbereich angefordert, der mindestens 30 % des Freispeichers beträgt. Standardmäßig lautet der Mindestwert 0,3.
- -Xmn<Größe>
  - Legt für die Anfangsgröße und die maximale Größe des neuen Freispeichers den angegebenen Wert fest, wenn -Xgcpolicy:gencon verwendet wird. Ist äquivalent mit der Definition von -Xmns und -Xmnx. |Wenn Sie -Xmns oder -Xmnx definieren, können Sie -Xmn nicht definieren. Wenn Sie versuchen, -Xmn mit Hilfe von -Xmns oder -Xmnx zu definieren, startet VM nicht, und eine Fehlermeldung wird zurückgegeben. -Xmn wird standardmäßig intern ausgewählt, je nach der Funktionalität Ihres Systems. Mit der Option -verbose:sizes können Sie die Werte ermitteln, die JVM zurzeit verwendet.
- -Xmns<Größe>
  - Legt für die Anfangsgröße des neuen Freispeichers den angegebenen Wert fest, wenn -Xgcpolicy:gencon verwendet wird. Diese Option wird standardmäßig intern ausgewählt, je nach der Funktionalität Ihres Systems. |Diese Option gibt eine Fehlermeldung zurück, wenn Sie sie mit der Option -Xmn verwenden.
- -Xmnx<Größe>
  - Legt für die maximale Größe des neuen Freispeichers den angegebenen Wert fest, wenn -Xgcpolicy:gencon verwendet wird. Diese Option wird standardmäßig intern ausgewählt, je nach der Funktionalität Ihres Systems. |Diese Option gibt eine Fehlermeldung zurück, wenn Sie sie mit der Option -Xmn verwenden.
- -Xmo<Größe>
  - Legt für die Anfangsgröße und die maximale Größe des Freispeichers für alte Objekte den angegebenen Wert fest, wenn -Xgcpolicy:gencon verwendet wird. Ist äquivalent zur Definition von -Xmos und -Xmox. |Wenn Sie -Xmos oder -Xmox definieren, können Sie -Xmo nicht definieren. Wenn Sie versuchen, -Xmo mit Hilfe von -Xmos oder -Xmox zu definieren, startet VM nicht, und eine Fehlermeldung wird zurückgegeben. Standardmäßig wird -Xmo intern ausgewählt, je nach der Funktionalität Ihres Systems. Mit der Option -verbose:sizes können Sie die Werte ermitteln, die JVM zurzeit verwendet.
- -Xmos<Größe>
  - Legt für die Anfangsgröße des Freispeichers für alte Objekte den angegebenen Wert fest, wenn -Xgcpolicy:gencon verwendet wird. Diese Option wird standardmäßig intern ausgewählt, je nach der Funktionalität Ihres Systems. |Diese Option gibt eine Fehlermeldung zurück, wenn Sie sie zusammen mit der Option -Xmo verwenden.
- -Xmox<Größe>
  - Legt für die maximale Größe des Freispeichers für alte Objekte den angegebenen Wert fest, wenn -Xgcpolicy:gencon verwendet wird. Diese Option wird standardmäßig intern ausgewählt, je nach der Funktionalität Ihres Systems. |Diese Option gibt eine Fehlermeldung zurück, wenn Sie sie zusammen mit der Option -Xmo verwenden.
- -Xmoi<Größe>
  - Definiert den Wert, um den der Java-Freispeicher stufenweise erweitert wird, wenn -Xgcpolicy:gencon verwendet wird. Wenn der Wert null beträgt, ist keine Erweiterung zulässig. Die Größe der einzelnen Stufen wird standardmäßig auf der Grundlage der Erweiterungsgröße, -Xmine und -Xminf berechnet.
- -Xmr<Größe>
  - Definiert die Größe für die "gemerkte Gruppe" der Garbage-Collection, wenn -Xgcpolicy:gencon verwendet wird. Es handelt sich um eine Liste mit Objekten im alten Freispeicher, die auf Objekte im neuen Freispeicher verweisen. Die Standardeinstellung für diese Option lautet 16 Kilobyte.
- -Xms<Größe>
  - Definiert die Anfangsgröße des Java-Freispeichers. Sie können auch -Xmo verwenden. Der Standardwert wird intern entsprechend der Funktionalität Ihres Systems definiert.
- -Xmso<Größe>
  - Definiert die C-Stack-Größe für verzweigte Java-Threads. Die Standardeinstellung für diese Option lautet 32 Kilobyte auf 32-Bit-Plattformen und 256 Kilobyte auf 64-Bit-Plattformen.
- -Xmx<Größe>
  - Definiert die maximale Größe des Java-Freispeichers. Diese Option wird standardmäßig intern entsprechend der Funktionalität Ihres Systems definiert.
- -Xnoclassgc
  - Inaktiviert die Garbage-Collection für Klassen. Diese Option inaktiviert die Garbage-Collection für Speicher, der Java-Klassen zugeordnet ist, die nicht mehr von JVM verwendet werden sollen. Das Standardverhalten ist -Xclassgc.
- -Xnocompactgc
  - Inaktiviert die Komprimierung für den Garbage-Collector. Siehe auch -Xcompactgc. Die Komprimierung ist standardmäßig aktiviert.
- -Xnocompactexplicitgc
  - Inaktiviert die Komprimierung beim Aufruf an `System.gc()`. Siehe auch -Xcompactexplicitgc. Die Komprimierung ist bei Aufrufen an `System.gc()` standardmäßig aktiviert.
- -Xnojit
  - Inaktiviert den JIT-Compiler. Siehe auch -Xjit. Der JIT-Compiler ist standardmäßig aktiviert.
- -Xnolinenumbers
  - Inaktiviert die Zeilennummern für das Debugging. Siehe auch -Xlinenumbers. Zeilennummern sind standardmäßig aktiviert.
- |-Xnoloa |
  |
  - Diese Option verhindert die Zuordnung eines LOAs (Large Object Area). Alle Objekte werden im SOA zugeordnet. Standardmäßig ist der LOA für alle GC-Richtlinien aktiviert, mit Ausnahme des Speicherteilbereichs, in dem der LOA nicht verfügbar ist. Siehe auch -Xloa.
- -Xnopartialcompactgc
  - Inaktiviert die schrittweise ausgeführte Komprimierung. Siehe auch -Xpartialcompactgc. Diese Option ist standardmäßig nicht definiert, somit werden alle Komprimierungen vollständig ausgeführt.
- -Xnosigcatch
  - Inaktiviert den JVM-Signalverarbeitungscode. Siehe auch -Xsigcatch. Die Signalverarbeitung ist standardmäßig aktiviert.
- -Xnosigchain
  - Inaktiviert die Verkettung von Signalroutinen. Siehe auch -Xsigchain. Die Verkettung von Signalroutinen ist standardmäßig aktiviert.
- -Xoptionsfile=<Datei>
  - Gibt eine Datei an, die JVM-Optionen und die zugehörigen Definitionen enthält. Standardmäßig wird keine Optionsdatei verwendet.
- -Xoss<Größe>
  - Definiert die Java-Stackgröße und die C-Stackgröße für einen beliebigen Thread. Diese Option wird aus Kompatibilitätsgründen zur Verfügung gestellt und entspricht der Einstellung von -Xss und von -Xmso auf den angegebenen Wert.
- -Xpartialcompactgc
  - Inaktiviert die Teilkomprimierung. Siehe auch -Xnopartialcompactgc.
- -Xquickstart
  - Verbessert die Startzeit durch das Verzögern der JIT-Kompilierung und der Optimierungen. Diese Option ist standardmäßig inaktiviert und die JIT-Kompilierung wird nicht verzögert.
- -Xrdbginfo:<Host>:<Port>
  - Lädt und übergibt Optionen an den fernen Debuginformationsserver. Der ferne Debuginformationsserver ist standardmäßig inaktiviert.
- -Xrs
  - Reduziert die Verwendung von Betriebssystemsignalen. JVM nutzt die Betriebssystemsignale standardmäßig vollständig. Siehe Von JVM verwendete Signale.
- -Xrun<Bibliotheksname>[:Optionen]
  - Lädt Bibliotheken mit Hilfeprogrammen. Geben Sie zum Laden mehrerer Bibliotheken diese Option mehrmals in der Befehlszeile an. Beispiele für diese Bibliotheken:
    - -Xrunhprof[:help] | [:<Option>=<Wert>, ...]
      - Erstellt Profile für Freispeicher, CPU oder Überwachungsprogramme. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
    - -Xrunjdwp[:help] | [:<Option>=<Wert>, ...]
      - Lädt Debugbibliotheken, damit das ferne Debugging von Anwendungen unterstützt wird. Ist identisch mit -Xdbg. Weitere Informationen finden Sie im Abschnitt Debugging in Java-Anwendungen.
    - -Xrunjnichk[:help] | [:<Option>=<Wert>, ...]
      - Führt zusätzliche Prüfungen für JNI-Funktionen aus, um Fehler in den nativen Programmen nachzuvollziehen, die über JNI auf JVM zugreifen. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
- |-Xscmx<Größe>[k|m|g] |
  |
  - Weitere Informationen zu -Xscmx finden Sie im Abschnitt Verwenden von Befehlszeilenoptionen für die gemeinsame Nutzung von Klassen.
- |-Xshareclasses:<Unteroptionen> |
  |
  - Weitere Informationen zu den -Xshareclasses-Unteroptionen finden Sie im Abschnitt Verwenden von Befehlszeilenoptionen für die gemeinsame Nutzung von Klassen.
- -Xsigcatch
  - Aktiviert den VM-Signalverarbeitungscode. Siehe auch -Xnosigcatch. Die Signalverarbeitung ist standardmäßig aktiviert.
- -Xsigchain
  - Aktiviert die Verkettung von Signalroutinen. Siehe auch -Xnosigchain. Die Verkettung von Signalroutinen ist standardmäßig aktiviert.
- |-Xsoftrefthreshold<Anzahl> |
  |
  - Definiert die Anzahl GCs. Anschließend wird ein indirekter Verweis gelöscht, wenn das zugehörige Verweisobjekt nicht markiert wurde. Die Standardeinstellung lautet 3. Dies bedeutet, dass der indirekte Verweis bei der dritten GC, bei der das Verweisobjekt nicht markiert ist, gelöscht wird.
- -Xss<Größe>
  - Definiert die Maximalgröße für den Java-Stack für einen beliebigen Thread. Die Standardeinstellung dieser Option lautet 256 KB. Weitere Informationen finden Sie im Abschnitt Verwenden der Funktion 'floating stacks'.
- -Xthr:<Optionen>
  - Definiert die Threading-Optionen.
- -Xverbosegclog:<Dateipfad><Dateiname>[X, Y]
  - Die verboseGC-Ausgabe wird in die angegebene Datei geschrieben. Wenn die Datei bereits vorhanden ist, wird sie überschrieben. Ist dies nicht der Fall, wird die Ausgabe an stderr umgeleitet, falls eine vorhandene Datei nicht geöffnet oder eine neue Datei nicht erstellt werden kann. Wenn Sie die Argumente X und Y (bei beiden handelt es sich um ganze Zahlen) angeben, wird die verboseGC-Ausgabe an X Dateien umgeleitet, von denen jede Y gc-Zyklen mit verboseGC-Ausgaben enthält. Diese Dateien weisen folgendes Format auf: Dateiname1, Dateiname2 usw. Die verboseGC-Protokollierung wird nicht standardmäßig durchgeführt.
- -Xverify
  - Aktiviert die genaue Prüfung aller geladenen Klassen. Die genaue Prüfung von Klassen ist standardmäßig inaktiviert.
- -Xverify:none
  - Inaktiviert die genaue Prüfung von Klassen. Die genaue Prüfung von Klassen ist standardmäßig inaktiviert.

## Abrufen der IBM Build- und Versionsnummer

Geben Sie den folgenden Befehl an einer Shelleingabeaufforderung ein, um die IBM Build- und Versionsnummer abzurufen:

    java -version

## Globalisierung des Befehls 'java'

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.

## JIT-Compiler (Just-In-Time)

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.

### Inaktivieren des JIT-Compilers

Zum Inaktivieren des JIT-Compilers haben Sie drei Möglichkeiten:

- Setzen Sie die Umgebungsvariable JAVA_COMPILER auf "NONE" oder auf eine leere Zeichenfolge, bevor Sie die Java-Anwendung ausführen.

  Geben Sie Folgendes an einer Eingabeaufforderung ein:

  1. Für Korn-Shells:

     -     export JAVA_COMPILER=NONE

       (Korn-Shell-Befehle werden in den weiteren Abschnitten dieses Benutzerhandbuchs verwendet.)

  2. Für Bourne-Shells:

     -     JAVA_COMPILER=NONE

     -     export JAVA_COMPILER

  3. Für C-Shells:

     -     setenv JAVA_COMPILER NONE

- Verwenden Sie die Option -D in der JVM-Befehlszeile, um das Merkmal java.compiler auf "NONE" oder auf eine leere Zeichenfolge zu setzen:

      java -Djava.compiler=NONE MeineAnwendung

- Verwenden Sie die Option -Xint in der JVM-Befehlszeile. Beispiel:

      java -Xint MeineAnwendung

Beide Befehlszeilenoptionen überschreiben die Umgebungsvariable JAVA_COMPILER.

### Aktivieren des JIT-Compilers

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 `unset JAVA_COMPILER` an der Shelleingabeaufforderung ein, um die Einstellung der Umgebungsvariablen ordnungsgemäß aufzuheben.

### Prüfen, ob der JIT-Compiler aktiviert ist

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.

## Angeben der Garbage-Collection-Richtlinie

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.

### Optionen der Garbage-Collection

Die Option -Xgcpolicy gibt die Garbage-Collection-Richtlinie an.

-Xgcpolicy nimmt die Werte optthruput (Standardwert und empfohlener Wert), optavgpause|, subpool| (nur PPC und zSeries) 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

|

> -Xgcpolicy:subpool (nur PPC und zSeries)

### Pausezeit

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.

### Verringerung der Pausezeit

JVM verwendet zwei Verfahren zur Verringerung von Pausezeiten:

- Gleichzeitig ablaufende Garbage-Collection
- Garbage-Collection nach Objektalter

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.

### Umgebungen mit sehr vollen Freispeichern

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.

## Signalverarbeitung durch JVM

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.

JVM führt für Signale bei Ausnahmebedingungen und für Fehlersignale eine der folgenden Aktionen aus:

- Verarbeiten der Bedingung und Wiederherstellung
- Beginnen einer Sequenz für einen kontrollierten Systemabschluss. Dabei werden die folgenden Aktionen ausgeführt:
  1. Ausgeben eines Java-Speicherauszugs, um den JVM-Status am Fehlerpunkt zu beschreiben
  2. Aufrufen der Signalroutine Ihrer Anwendung für dieses Signal
  3. Aufrufen eines beliebigen durch die Anwendung installierten Abbruchhooks
  4. Ausführen der erforderlichen Bereinigung, damit ein ordnungsgemäßer Systemabschluss durchgeführt werden kann

Informationen zum Schreiben eines Startprogramms, das die oben aufgeführten Hooks angibt, finden Sie unter der folgenden Adresse: http://www-106.ibm.com/developerworks/java/library/i-signalhandling/. Dieser Abschnitt wurde für Java Version 1.3.1 geschrieben, gilt jedoch auch für spätere Versionen.

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:

- Aufrufen der Signalroutine Ihrer Anwendung für dieses Signal
- Ausführen aller Hooks für das Beenden der Anwendung
- Aufrufen eines beliebigen durch die Anwendung installierten Exit-Hooks
- Ausführen der erforderlichen JVM-Bereinigung

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 SIGQUIT, durch das ein Java-Speicherauszug generiert wird.

### Von JVM verwendete Signale

In Tabelle 1 sind die von JVM verwendeten Signale aufgeführt. Die Signale werden in der Tabelle nach Typ oder Verwendung wie folgt zusammengefasst:

- Ausnahmebedingungen: Das Betriebssystem setzt beim Auftreten einer schwer wiegenden Bedingung ein entsprechendes Signal zum Anzeigen einer Ausnahmebedingung ab.
- Fehler: JVM setzt ein Signal SIGABRT ab, wenn es eine Bedingung feststellt, aus der keine Wiederherstellung möglich ist.
- Interrupts: Interruptsignale werden außerhalb eines JVM-Prozesses asynchron abgesetzt, um einen Systemabschluss anzufordern.
- Steuerzeichen: Hierbei handelt es sich um andere Signale, die von JVM zu Steuerungszwecken verwendet werden.

Tabelle 1. Von JVM verwendete Signale
Signalname | Signaltyp | Beschreibung | Inaktiviert durch -Xrs
--- | --- | --- | ---
SIGBUS | Ausnahmebedingung | Falscher Zugriff auf den Speicher (falsche Datenanordnung) | Ja
SIGSEGV | Ausnahmebedingung | Falscher Zugriff auf den Speicher (es wurden Daten in einen Speicherbereich geschrieben, auf den nicht zugegriffen werden kann). | Ja
SIGILL | Ausnahmebedingung | Nicht zulässige Anweisung (es wurde versucht, eine unbekannte Maschineninstruktion aufzurufen). | Nein
SIGFPE | Ausnahmebedingung | Ausnahmebedingung bei der Gleitkommaverarbeitung (Division durch null). | Ja
SIGABRT | Fehler | Abnormale Beendigung. JVM setzt dieses Signal ab, sobald ein JVM-Fehler festgestellt wird. | Ja
SIGINT | Interrupt | Interaktiver Abruf (Strg-C). JVM wird normal beendet. | Ja
SIGTERM | Interrupt | Beendigungsanforderung. JVM wird normal beendet. | Ja
SIGHUP | Interrupt | Auflegen. JVM wird normal beendet. | Ja
SIGQUIT | Steuerzeichen | Ein Beendigungssignal für ein Terminal. JVM verwendet dieses Signal zum Ausführen von Java-Speicherauszügen. | Ja
|SIGTRAP (5) | |Steuerzeichen | |Vom JIT-Compiler verwendet. | |Ja
|__SIGRTMAX - 2 | |Steuerzeichen | |Von SDK verwendet. | |Nein
|SIGCHLD | |Steuerzeichen | |Von SDK für die interne Steuerung verwendet. | |Nein

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 `1 (SIGHUP)`, `2 (SIGINT)`, `4 (SIGILL)`, `7 (SIGBUS)`, `8 (SIGFPE)`, `11 (SIGSEGV)` 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.

### Verbinden eines nativen Codetreibers mit der Signalverkettungsbibliothek

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 genutzten Bibliothek libjsig.so verbunden werden und diese Bibliothek vor den Systembibliotheken geladen werden. Mit Hilfe der Bibliothek libjsig.so wird sichergestellt, dass Aufrufe (wie z. B. `signal()`, `sigset()` und `sigaction()`) abgefangen werden, so dass die JVM-Signalroutinen nicht durch die zugehörigen Signalroutinen 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.

Führen Sie die folgenden Schritte aus, um libjsig.so zu verwenden:

- Stellen Sie eine Verbindung zu der Anwendung her, die JVM erstellt oder integriert:

      gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm Java-Anwendung.c

  oder

- Verwenden Sie die Umgebungsvariable LD_PRELOAD:

      export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; Java-Anwendung (bash und ksh)

      setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; Java-Anwendung (csh)

  (Dabei wird angenommen, dass `JAVA_HOME` installiert ist. Verwenden Sie andernfalls /opt/ibm/java2-i386-50/jre.)

Wenn Sie Signalroutinen installieren, die `sigaction()` verwenden, werden einige sa_flags nicht überwacht, wenn JVM das Signal verwendet. Dabei handelt es sich um folgende Markierungen:

- SA_NOCLDSTOP - Diese Option ist niemals festgelegt.
- SA_NOCLDWAIT - Diese Option ist niemals festgelegt.
- SA_RESTART - Wird in jedem Fall definiert.

Die Bibliothek libjsig.so verdeckt auch JVM-Signalroutinen vor der Anwendung. Daher geben Aufrufe wie `signal()`, `sigset()` und `sigaction()`, die nach dem Starten von JVM ausgeführt werden, keinen Verweis mehr auf die JVM-Signalroutine, sondern auf eine beliebige vor dem Starten von JVM installierte Routine zurück.

## Verwenden der Funktion 'floating stacks'

Bei bestimmten Linux-Distributionen (z. B. Red Hat) ist eine GLIBC-Funktion mit dem Namen "floating stacks" aktiviert. Auf Grund von Einschränkungen des Linux-Kernels kann JVM auf SMP-Hardware mit aktivierter Funktion "floating stacks" nicht ausgeführt werden, sofern der Kernel-Level unter 2.4.10 ist. In dieser Umgebung muss die Funktion "floating stacks" inaktiviert werden, bevor JVM oder eine beliebige Anwendung, die JVM startet, gestartet wird. Verwenden Sie unter Red Hat den folgenden Befehl, um die Funktion "floating stacks" zu inaktivieren, indem Sie eine Umgebungsvariable wie folgt exportieren:

    export LD_ASSUME_KERNEL=2.2.5

Auf einem Linux-System ohne aktivierte Funktion "floating stacks" wird unabhängig von der Einstellung für -Xss eine Minimalgröße von 256 KB für native Stacks für die einzelnen Threads bereitgestellt. Auf einem Linux-System mit aktivierter Funktion "floating stacks" werden die Werte für -Xss berücksichtigt. Wenn Sie also ein Linux-System ohne die aktivierte Funktion "floating stacks" migrieren, müssen alle Werte für -Xss groß genug sein, und es darf kein Minimum von 256 KB erforderlich sein.

## Umwandeln von XML-Dokumenten

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:

- Ändern der Angaben in der Datei jaxp.properties (unter /opt/ibm/java2-i386-50/jre/lib) oder
- Setzen des Systemmerkmals für den Schlüssel javax.xml.transform.TransformerFactory auf org.apache.xalan.xsltc.trax.TransformerFactoryImpl

Zur Implementierung von Merkmalen in der Datei jaxp.properties müssen Sie die Datei jaxp.properties.sample in die Datei jaxp.properties unter /opt/ibm/java2-i386-50/ 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:

1. Überprüfen Sie die Einstellung für das Systemmerkmal org.apache.xalan.xsltc.dom.XSLTCDTMManager.
2. Überprüfen Sie den Wert für das Systemmerkmal org.apache.xalan.xsltc.dom.XSLTCDTMManager in der Datei /opt/ibm/java2-i386-50/lib/xalan.properties.
3. Überprüfen Sie, ob in der Datei META-INF/services/org.apache.xalan.xsltc.dom.XSLTCDTMManager ein Klassenname aufgeführt ist.
4. Verwenden Sie den Standard-Service-Provider org.apache.xalan.xsltc.dom.XSLTCDTMManager.

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.

### Verwenden einer älteren Version von Xerces oder Xalan

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:

- Führen Sie ein Upgrade auf eine neuere Version der Anwendung aus, die die aktuelle JAXP-Spezifikation (Java API for XML Programming) implementiert (http://java.sun.com/xml/jaxp/index.html).

- Löschen Sie die Datei jaxp.properties aus dem Verzeichnis /opt/ibm/java2-i386-50/jre/lib.

- Entfernen Sie die Kommentarzeichen in der Datei jaxp.properties in /opt/ibm/java2-i386-50/jre/lib.

- Definieren Sie SAXParserFactory, DocumentBuilderFactory oder TransformerFactory explizit unter Verwendung der Umgebungsvariablen IBM_JAVA_OPTIONS. Beispiel:

      export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
        org.apache.xerces.jaxp.SAXParserFactoryImpl

  oder

      export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
        org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

  oder

      export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
        org.apache.xalan.processor.TransformerFactoryImpl

- Legen Sie das Systemmerkmal für javax.xml.parsers.SAXParserFactory, javax.xml.parsers.DocumentBuilderFactory oder javax.xml.transform.TransformerFactory innerhalb des Anwendungscodes fest. Ein Beispiel hierzu finden Sie in der Spezifikation JAXP 1.3.

# Verwenden von SDK zur Entwicklung von Java-Anwendungen

In den folgenden Abschnitten erhalten Sie Informationen zur Verwendung von SDK for Linux zur Entwicklung von Java-Anwendungen. Einzelheiten zu den verfügbaren Tools finden Sie im Abschnitt SDK-Tools.

## Debugging in Java-Anwendungen

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 Linux enthalten ist.

### Java-Debugger (JDB)

Der Java-Debugger (JDB) ist in SDK for Linux 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:

1. Starten Sie JVM unter Angabe folgender Optionen:

       java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<Port>
            MeineAnwendung <Argumente zu MeineAnwendung>

2. Daraufhin startet JVM. Vor dem Starten der Java-Anwendung wird die Ausführung jedoch ausgesetzt. Sie können den Debugger in einer separaten Sitzung über folgenden Befehl JVM zuordnen:

       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:

1. Geben Sie `jdb` ein.
2. Geben Sie bei der JDB-Eingabeaufforderung `help` ein.

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.

1. Starten Sie JVM wie oben beschrieben.
2. Ordnen Sie den Debugger mit folgendem Befehl dem fernen System zu:

       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:

- http://java.sun.com/products/jpda/
- http://java.sun.com/j2se/1.5.0/docs/guide/jpda/
- http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdb.html

## Ermitteln, ob eine Anwendung auf JVM im 32-Bit- oder 64-Bit-Modus ausgeführt wird

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:

- 32 - JVM wird im 32-Bit-Modus ausgeführt
- 64 - JVM wird im 64-Bit-Modus ausgeführt

Mit dem folgenden Aufruf können Sie das Systemmerkmal com.ibm.vm.bitmode innerhalb des Anwendungscodes überprüfen:

    System.getProperty("com.ibm.vm.bitmode");

## Schreiben von JNI-Anwendungen

Gültige JNI-Versionsnummmern, die über native Programme im API-Aufruf JNI_CreateJavaVM() angegeben werden können, lauten wie folgt:

- JNI_VERSION_1_2(0x00010002)
- JNI_VERSION_1_4(0x00010004)

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

Verwenden Sie zum Kompilieren und Verknüpfen einer nativen Anwendung mit IBM 5.0 SDK folgenden Befehl:

    gcc -I/opt/ibm/java2-i386-50/include -L/opt/ibm/java2-i386-50/jre/bin/j9vm
    -ljvm -ldl -lpthread <JNI-Programmdateiname>

Die Option -ljvm gibt an, dass libjvm.so die gemeinsam genutzte Bibliothek ist, über die JVM implementiert wird. Die Option -lpthread gibt an, dass die Unterstützung für native Pthreads aktiviert ist. Falls Sie keine Verbindung zur Pthread-Bibliothek hergestellt haben, tritt beim Ausführen des JNI-Programms möglicherweise ein Segmentierungsfehler (Signal SIGSEGV) auf.

Anmerkung:
Version 1.1 der JNI (Java Native Interface) wird nicht unterstützt.
| | |

## Unterstützung für die Wiederherstellung von blockierten Verbindungen auf Threadebene

|

Dem Paket com.ibm.jvm wurden zur Unterstützung für die Wiederherstellung von blockierten Verbindungen auf Threadebene vier neue IBM spezifische SDK-Klassen hinzugefügt. Die neuen Klassen befinden sich in der Datei |core.jar.

|

Diese Klassen ermöglichen die Aufhebung der Blockierung von Threads, die im Netzbetrieb oder bei Synchronisationsaufrufen auftrat. Wenn eine Anwendung diese Klassen nicht verwendet, muss sie den gesamten Vorgang beenden, anstatt ein einzelnes blockiertes Thread zu unterbrechen.

|

Die folgenden Klassen sind verfügbar:

|

|
InterruptibleContext() (allgemein zugängliche Schnittstelle)
|
  Definiert die beiden Methoden isblocked() und unblock(). Die drei weiteren Klassen implementieren InterruptibleContext. |
|
InterruptibleLockContext() (öffentliche Klasse)
|
  Eine Dienstprogrammklasse für die Unterbrechung von Synchronisationsaufrufen. |
|
InterruptibleIOContext() (öffentliche Klasse)
|
  Eine Dienstprogrammklasse für die Unterbrechung von Netzaufrufen. |
|
InterruptibleThread() (öffentliche Klasse)
|
  Eine Dienstprogrammklasse zur Erweiterung von java.lang.Thread, um die Wiederverwendung von ausführbaren Methoden, die unterbrochen werden können, zu ermöglichen. Sie verwendet Instanzen der Klassen InterruptibleLockContext und InterruptibleIOContext, um die erforderlichen Methoden isblocked() und unblock() auszuführen, unabhängig davon, ob ein Synchronisations- oder Netzbetriebsprozess den Thread blockiert. |
|

|

Die beiden Klassen InterruptibleLockContext und InterruptibleIOContext funktionieren durch Verweis auf den aktuellen Thread. Wenn Sie die Klasse InterruptibleThread nicht verwenden, müssen Sie daher zum Verwenden dieser neuen Klassen eine eigene Klasse bereitstellen, durch die java.lang.Thread erweitert wird.

|

Die Javadoc-Komponente für diese Klassen wird mit SDK in der Datei docs/apidoc.zip mitgeliefert.

## Arbeiten mit Applets

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.

### Ausführen von Applets mit Applet Viewer

Geben Sie zum Ausführen eines Applets mit Applet Viewer Folgendes an einer Shelleingabeaufforderung ein:

       appletviewer Name

Name steht für Folgendes:

- Dateiname einer HTML-Datei, die ein Applet aufruft
- URL einer Webseite, die ein Applet aufruft

Geben Sie z. B. zum Aufrufen von Applet Viewer über eine HTML-Datei, die ein Applet aufruft, an einer Shelleingabeaufforderung Folgendes ein:

      appletviewer $HOME/Dateiname.html

Dateiname ist dabei der Name der HTML-Datei.

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

### Debugging von Applets mit Applet Viewer

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/applets/TicTacToe
    ../../bin/appletviewer -debug Beispiel1.html

Dokumentation zum Debugging von Applets finden Sie mit Hilfe des Applet Viewer auf der Website von Sun: http://java.sun.com.

| | |

## Konfigurieren einer Speicherzuordnung von großen Seiten

|

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.

|

Die Unterstützung für große Seiten muss im Kernel verfügbar und aktiviert sein, |damit Java große Seiten verwenden kann.

|

Stellen Sie zum Konfigurieren einer Speicherzuordnung von großen |Seiten zunächst sicher, dass der aktive Kernel große Seiten |unterstützt. Überprüfen Sie, ob die Datei /proc/meminfo die folgenden Zeilen enthält:

|

    HugePages_Total:     <Anzahl Seiten>
    |HugePages_Free:      <Anzahl Seiten>
    |Hugepagesize:        <Seitengröße in KB>

Die Anzahl verfügbarer Seiten und deren Größe |ist je nach Distribution unterschiedlich.

|

Falls die Unterstützung für große Seiten nicht im Kernel verfügbar ist, |sind die entsprechenden Zeilen nicht in der Datei /proc/meminfo vorhanden. In diesem Fall müssen Sie einen neuen Kernel installieren, der große Seiten unterstützt.

|

Falls die Unterstützung für große Seiten zwar verfügbar, jedoch nicht aktiviert ist, |hat `HugePages_Total` den Wert 0. Dann muss der zuständige Administrator die Unterstützung für große Seiten aktivieren. Weitere Anweisungen hierzu finden Sie im Handbuch zum Betriebssystem.

|

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. Beim Konfigurieren der Anzahl großer Seiten während des Systemstarts |werden diese als zusammenhängende Seiten erstellt.

|

Die Zuordnung großer Seiten ist nur möglich, wenn JVM über Rootberechtigung verfügt. Zur Verwendung großer Seiten können Sie entweder Java als Root |ausführen oder das SUID-Bit des Java-Programms festlegen.

## CORBA-Unterstützung

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.

### Unterstützung für GIOP 1.2

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.

### Unterstützung für portierbare Abfangprozesse

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.

### Unterstützung für den Interoperable Naming Service

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.

### Systemmerkmale für die ORB-Tracefunktion

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.

- Legen Sie Folgendes fest, um die Tracefunktion zu aktivieren: `com.ibm.CORBA.Debug=true`.
- Legen Sie Folgendes fest, um gesendete und empfangene GIOP-Nachrichten zu formatieren und dem Trace hinzuzufügen: `com.ibm.CORBA.CommTrace=true`. Standardmäßig wird die Ausgabe der ORB-Tracefunktion in Dateien geschrieben, deren Namen das folgende Format aufweisen: orbtrc.DDMMYYYY.HHmm.SS.txt.
- Legen Sie Folgendes fest, um die Ausgabe in eine andere Datei zu schreiben: `com.ibm.CORBA.Debug.Output=<Dateiname>`.

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.

### Systemmerkmale zur Optimierung des ORB

Mit den folgenden Merkmalen können Sie den ORB optimieren:

- Legen Sie das Systemmerkmal com.ibm.CORBA.FragmentSize fest, um die Fragmentierung von GIOP 1.2 zu steuern.

  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.

- In einem heterogenen Netz kann sich die Antwort auf eine CORBA-Anforderung verzögern oder verloren gehen. Über das Systemmerkmal com.ibm.CORBA.RequestTimeout können Sie die maximale Wartezeit festlegen. Sie können das Zeitlimit für die Anforderungssuche auch über com.ibm.CORBA.LocateRequestTimeout steuern. Geben Sie z. B. Folgendes ein, um beide Verzögerungen auf 30 Sekunden zu beschränken:

      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.

- Wenn Ihr Programm einen Service im Netz bereitstellt, müssen Sie für die Anzahl Ports, über die der ORB eingehende Anforderungen liest, möglicherweise einen bekannten Wert festlegen. Sie können dies über das Systemmerkmal com.ibm.CORBA.ListenerPort steuern.

  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.

### Java 2-Sicherheitsberechtigungen für den ORB

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:

Tabelle 2. Methoden, auf die sich das Ausführen eines Java 2-Sicherheitsmanagers auswirkt
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.

### ORB-Implementierungsklassen

Die ORB-Implementierungsklassen in diesem Release lauten:

- org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
- org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton
- javax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.UtilDelegateImpl
- javax.rmi.CORBA.StubClass=com.ibm.rmi.javax.rmi.CORBA.StubDelegateImpl
- javax.rmi.CORBA.PortableRemoteObjectClass= com.ibm.rmi.javax.rmi.PortableRemoteObject

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.

## RMI-IIOP

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:

- Im Handbuch RMI-IIOP Programmer's Guide ist eine Einführung zum Schreiben von RMI-IIOP-Programmen enthalten. Dieses Handbuch wird bei der Installation dieser Dokumentation installiert.
- Das Demoverzeichnis umfasst Folgendes:
  - Ein Beispiel mit der Bezeichnung "Hello World", mit dem zwischen dem Java Remote Method Protocol (JRMP) und IIOP-Protokollen umgeschaltet werden kann (demo/rmi-iiop/hello)
  - Ein Beispiel mit der Bezeichnung "Hello World", das mit einem IDL-Standardprogramm interagiert (demo/rmi-iiop/idl)
- Das Dokument Java Language to IDL Mapping enthält detaillierte technische Spezifikationen zu RMI-IIOP und ist unter folgender Adresse verfügbar:
  http://www.omg.org/cgi-bin/doc?ptc/00-01-06.pdf

## Implementieren des Steuerroutinenpools für RMI-Verbindungen

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.

## Erweiterte BiDirectional-Unterstützung

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.

## Funktionale Erweiterungen für BigDecimal

| |

Ü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,*;`.

## Unterstützung des Euro-Symbols

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.

# Verwenden der Java Communications API (JavaComm)

Das Paket mit der Java Communications API (JavaComm) ist ein optional erhältliches Paket, das zusammen mit Runtime Environment for Linux auf IA32-, PPC32-/PPC64- und AMD64/EM64T-Plattformen 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:

- Auflisten von Anschlüssen auf einem System
- Öffnen und Anfordern des Eigentumsrechts von Anschlüssen
- Beheben von Konkurrenzsituationen in Bezug auf das Eigentumsrecht für Anschlüsse zwischen Anwendungen, die mit der Java Communications API arbeiten
- Überwachen asynchroner und synchroner E/A-Anschlüsse mit Hilfe von Ereignisbenachrichtigungen
- Empfangen von Bean-ähnlichen Ereignissen, die Statusänderungen am Anschluss angeben

## Installieren der Java Communications API

Sie sollten vor der Installation der Java Communications API sicherstellen, dass eine Kopie von SDK oder Runtime Environment installiert ist.

Wenn Sie bei der ursprünglichen Installation von Java das RPM-Paket verwendet haben, müssen Sie die Java Communications API über die RPM-Datei installieren. Gehen Sie zur Installation der Java Communications API über ein RPM-Paket folgendermaßen vor:

1. Rufen Sie eine Shelleingabeaufforderung auf, und stellen Sie sicher, dass Sie als Root angemeldet sind.

2. Installieren Sie die RPM-Datei der Java Communications API mit dem Befehl `rpm -ivh`. Beispiel:

       rpm -ivh ibm-java2-<Architektur>-javacomm-5.0-0.0.<Architektur>.rpm

   Die Java Communications API wird in der Verzeichnisstruktur /opt/ibm/java2-i386-50/ installiert.

Gehen Sie zur Installation der Java Communications API über eine Datei mit der Erweiterung .tgz folgendermaßen vor:

1. Stellen Sie die Archivdatei der Java Communications API, ibm-java2-javacomm-50-linux-<Architektur>.tgz, in das Verzeichnis, in dem das Verzeichnis IBMJava2-50 enthalten ist.

2. Dekomprimieren Sie diese Datei über eine Shelleingabeaufforderung in dem Verzeichnis, in dem die Datei mit der Erweiterung .tgz enthalten ist:

       tar -xvzf ibm-java2-javacomm-50-linux-<Architektur>.tgz

   Die Dateien der Java Communications API werden daraufhin in die Unterverzeichnisse des vorhandenen Verzeichnisses IBMJava2-50 extrahiert.

## Speicherposition der Java Communications API-Dateien

Die Java Communications API-Dateien werden in folgenden Verzeichnissen installiert:

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

Falls Sie bei der Installation das Standardverzeichnis verwendet haben, befindet sich die Datei comm.jar im Verzeichnis /opt/ibm/java2-i386-50/jre/lib/ext.

Wenn Sie das Paket in einem anderen Verzeichnis installiert haben, werden die Dateien in dieselbe Verzeichnisstruktur gestellt, an Stelle von /opt/ibm/java2-i386-50/ wird jedoch das Verzeichnis verwendet, in dem Sie die Java Communications API installiert haben.

## Konfigurieren der Java Communications API

Nach der Installation der Java Communications API müssen Sie folgende Schritte durchführen:

- Ändern Sie den Zugriffsmodus für den seriellen Anschluss und den Parallelanschluss.
- Legen Sie einen Wert für die Umgebungsvariable PATH fest, falls dies nicht während der Installation von Java geschehen ist. Siehe hierzu den Abschnitt Festlegen der Umgebungsvariablen PATH.

### Ändern des Zugriffsmodus für den seriellen Anschluss und den Parallelanschluss

Nach der Installation der Java Communications API müssen Sie den Zugriffsmodus für den seriellen Anschluss und den Parallelanschluss so ändern, dass die Benutzer auf diese Einheiten zugreifen können. Sie müssen den Benutzern Schreib-/Lesezugriff auf die erforderlichen Einheiten einräumen. Melden Sie sich dazu als Root an, und verwenden Sie einen der folgenden Befehle:

        chmod 666
    /dev/ttyS0    (wird auch als serieller Anschluss COM1 bezeichnet)
        chmod 666 /dev/lp0      (wird auch als Parallelanschluss LPT1 bezeichnet)
        chmod 666 /dev/ttyS1    (wird auch als serieller Anschluss COM2 bezeichnet)
        chmod 666 /dev/ttyS2    (wird auch als serieller Anschluss COM3 bezeichnet)
        chmod 666 /dev/ttyS3    (wird auch als serieller Anschluss COM4 bezeichnet)

Mit diesen Befehlen wird allen Benutzern auf dem System Schreib-/Lesezugriff erteilt.

Alternativ können auch die Berechtigungen 660 vergeben und bestimmte Benutzer zu der Gruppe hinzugefügt werden, in der sich die Einheiten befinden. Auf einem SUSE-System befinden sich die Einheiten z. B. in der Gruppe `uucp`. Wenn die Benutzer daher in diese Gruppe aufgenommen werden, erhalten sie Zugriff auf die Einheiten.

Ändern Sie bei Bedarf den Zugriffsmodus anderer Anschlüsse.

#### Angeben von Einheiten in der Datei javax.comm.properties

Über die Datei javax.comm.properties können Sie die Präfixe der Einheiten angeben, die der Java Communications API zur Verfügung stehen. Außerdem können Sie angeben, ob es sich um parallele oder serielle Einheiten handelt. Die Anschlussnummern werden allen Einheiten nacheinander zugeordnet. Wenn Sie z. B. `/dev/ttyS=PORT_SERIAL` angeben und die Einheiten `/dev/ttyS0` und `/dev/ttyS1` vorhanden sind, werden diese COM1 bzw. COM2 zugeordnet.

Zur Verwendung der seriellen USB-Anschlüsse müssen Sie das Kommentarzeichen in der Zeile mit der Angabe `/dev/ttyUSB=PORT_SERIAL` in der Datei javax.comm.properties entfernen. Sollten die Einheiten `/dev/ttyUSB0` und `/dev/ttyUSB1` vorhanden, COM1 und COM2 aber bereits zugeordnet sein, werden die seriellen USB-Einheiten den nächsten Anschlüssen, COM3 und COM4, zugeordnet.

## Aktivieren von seriellen Anschlüssen auf IBM ThinkPads

Bei den meisten ThinkPads sind die seriellen Anschlüsse standardmäßig im BIOS inaktiviert. Derzeit besteht keine Möglichkeit, die Anschlüsse unter Linux zu aktivieren (mit dem Paket tpctl können die Anschlüsse nicht aktiviert werden, wenn sie im BIOS inaktiviert sind).

Zum Aktivieren der Anschlüsse im BIOS müssen Sie die DOS-Version des ThinkPad-Konfigurationsprogramms verwenden. Dieses Programm steht auf der Download-Site für IBM ThinkPads zur Verfügung. Für die Verwendung des ThinkPad-Konfigurationsprogramms benötigen Sie eine startfähige DOS-Diskette. Beachten Sie, dass das ThinkPad-Konfigurationsprogramm - je nach den verwendeten Installationsoptionen - möglicherweise als Teil der ThinkPad-Dienstprogramme unter Windows installiert wurde. In diesem Fall können Sie es über eine Eingabeaufforderung unter Windows aufrufen.

Das unter Windows verfügbare ThinkPad-Konfigurationsprogramm bietet Optionen zum Aktivieren oder Inaktivieren der seriellen Anschlüsse und Parallelanschlüsse. Dadurch werden allerdings nicht die Einstellungen im BIOS geändert. Wenn Sie mit diesem Programm daher unter Windows arbeiten, sind die Anschlüsse verfügbar. Sobald Ihre Maschine allerdings unter Linux erneut gestartet wird, werden die Anschlüsse nicht aktiviert.

## Einschränkung beim Drucken mit der Java Communications API

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.

## Deinstallieren der Java Communications API

Die Vorgehensweise zur Deinstallation der Java Communications API hängt davon ab, ob Sie das installierbare RPM-Paket (Red Hat Package Manager) oder das komprimierte TAR-Paket (Tape Archive) installiert haben.

### Deinstallieren des RPM-Pakets (Red Hat Package Manager)

Gehen Sie zum Deinstallieren der Java Communications API folgendermaßen vor, falls Sie das installierbare RPM-Paket installiert haben:

1. Geben Sie an einer Shelleingabeaufforderung Folgendes ein:

           rpm -e ibm-java2-<Architektur>-javacomm-5.0-0.0

   Wahlweise können Sie auch ein grafisches Tool, wie z. B. kpackage oder yast2, verwenden.

2. Sollten in dem Verzeichnis, in dem Sie die Java Communications API installiert haben, keine anderen Tools enthalten sein, die Sie benötigen, entfernen Sie dieses Verzeichnis aus der Anweisung PATH.

### Deinstallieren des komprimierten TAR-Pakets (Tape Archive)

Löschen Sie zum Deinstallieren der Java Communications API, falls Sie das komprimierte TAR-Paket installiert haben, die folgenden Dateien aus dem Verzeichnis, in dem sie installiert wurden:

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

## Dokumentation zur Java Communications API

Dokumentation zu APIs und Beispiele zur Java Communications API finden Sie auf der Sun-Website unter folgender Adresse: http://java.sun.com

# Implementieren von Java-Anwendungen

## (Nur Linux IA (32 Bit) und PPC32) Verwenden des Java-Plug-ins

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.

### Unterstützte Browser

|Für Linux PPC32 wird Mozilla 1.6 als Browser unterstützt.

|Informationen zu Linux IA32 finden Sie |in Tabelle 3.

|Tabelle 3. Vom Java-Plug-in unterstützte Browser unter Linux IA32
|Distribution | |Netscape-Standardversion | |Von Netscape unterstützte Versionen | |Mozilla-Standardversion | |Von Mozilla unterstützte Versionen
--- | --- | --- | --- | ---
|Red Hat Enterprise Linux 3.0 | |- | |7.x | |1.4.2 | |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x
|Red Hat Enterprise Linux 4.0 | |4.8 | |7.x | |1.7.3 | |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x
|SUSE Linux Enterprise Server 9.0 | |- | |7.x | |1.6 | |1.4.1, 1.4.2, 1.6, 1.7.8, Firefox 1.0.x

|

### Installieren und Konfigurieren des Java-Plug-ins

|Mehrere Versionen des Java-Plug-ins werden mit SDK geliefert. Sie können die korrekte Version für Ihren Browser auswählen. Am häufigsten werden folgende Versionen verwendet:

| |
libjavaplugin_oji.so
|
  Das allgemeinste Plug-in. Es basiert auf der Initiative Open JVM Integration von Mozilla und wird für die meisten Mozilla-Produkte und von Mozilla abgeleiteten Produkte, einschließlich Firefox, verwendet. |
|
libjavaplugin_ojigtk2.so
|
  Dasselbe Plug-in wie oben, jedoch mit dem GTK2-Toolkit kompiliert. |

|Im Folgenden finden Sie Anweisungen zum Installieren des Plug-ins auf einigen gängigen Browsern.

|Sie müssen das Plug-in symbolisch verlinken, statt es zu kopieren, so dass es JVM finden kann.

#### Mozilla

|Nur Mozilla ab Version 1.4 wird unterstützt.

Gehen Sie wie folgt vor, um das Java-Plug-in allen Benutzern zur Verfügung zu stellen:

1. Melden Sie sich als Root an.

2. Wechseln Sie in das Plug-ins-Verzeichnis für Mozilla (dieses Verzeichnis kann bei einigen Linux-Distributionen anders lauten).

       cd /usr/local/mozilla/plugins/

3. |Erstellen Sie einen symbolischen Link zu libjavaplugin_oji.so. |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

Sie müssen das Plug-in symbolisch verlinken, statt es zu kopieren, so dass es JVM finden kann.

| | |

#### Firefox

|

Gehen Sie wie folgt vor, um das Java-Plug-in allen Benutzern zur Verfügung zu stellen:

|

|
1. Melden Sie sich als Root an.
|

2. Wechseln Sie in das Plug-ins-Verzeichnis für Firefox (dieses Verzeichnis kann bei einigen |Linux-Distributionen anders lauten). |

       cd /usr/local/mozilla-firefox/plugins/

|
3. |Erstellen Sie einen symbolischen Link zu libjavaplugin_oji.so. |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

   |

Sie müssen das Plug-in symbolisch verlinken, statt es zu kopieren, so dass es JVM finden kann.

#### Netscape 7.1 und höher

Zum Installieren und Konfigurieren des Java-Plug-ins für Netscape müssen Sie einen symbolischen Link von der Bibliotheksdatei /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so zum Plug-ins-Verzeichnis Ihres Browsers definieren (/Installationspfad Ihres Browsers/plugins).

1. Melden Sie sich als Root an.

2. Wechseln Sie in das Plug-ins-Verzeichnis für Netscape (dieses Verzeichnis kann bei einigen Linux-Distributionen anders lauten).

       cd /usr/local/netscape/plugins/

3. Erstellen Sie einen symbolische Link zu javaplugin_oji.so.

       ln -s /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so .

Sie müssen das Plug-in symbolisch verlinken, statt es zu kopieren, so dass es JVM finden kann.

### Allgemeine Dokumentobjektmodellunterstützung (Document Object Model, DOM)

Auf Grund von Einschränkungen bei bestimmten Browsern können Sie möglicherweise nicht alle Funktionen des Pakets org.w3c.dom.html implementieren.

- Für einige dieser Funktionen wird eine Ausnahmebedingung sun.plugin.dom.exception.NotSupportedException ausgegeben.
- Wenn der Browser eine bestimmte Funktion nicht unterstützt, wird eine Ausnahmebedingung sun.plugin.dom.exception.InvalidStateException ausgegeben.

### Verwenden von DBCS-Parametern

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:

- Netscape 4: Ansicht -> Zeichensatz
- Mozilla: Anzeigen -> Zeichencodierung

## (nur Linux IA (32 Bit), PPC32 und PPC64) Verwenden von Java Web Start

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.

### Ausführen von Java Web Start

Java Web Start Version 5.0 wird automatisch installiert, wenn Sie Java mit Hilfe der RPM- oder TGZ-Pakete installieren.

|Wenn Sie Java aus dem TGZ-Paket extrahieren, führen Sie das Shell-Script jre/lib/javaws/updateSettings.sh aus, um die Dateien .mailcap und .mime.types auf Ihrem System zu aktualisieren.

Sie können Web Start auf drei Arten aufrufen:

1. Wählen Sie auf einer Webseite einen Link aus, der auf eine JNLP-Datei verweist.
2. Geben Sie an einer Shelleingabeaufforderung den Befehl `javaws <URL>` ein, wobei `<URL>` die Speicherposition einer JNLP-Datei ist.
3. |Falls Sie Java Web Start bereits zum Öffnen der Anwendung verwendet haben, führen Sie javaws im Verzeichnis JRE/bin aus, um Java Application Cache Viewer zu starten.

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.

## Ausliefern von Java-Anwendungen

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:

- Ihre eigenen Klassen-, Ressourcen- und Datendateien
- Ein Installationsverfahren oder Installationsprogramm

Zum Ausführen der Anwendung benötigt der Benutzer Runtime Environment for Linux. In SDK for Linux ist Runtime Environment enthalten. Sie können jedoch nicht davon ausgehen, dass SDK for Linux auf den Systemen aller Benutzer installiert ist.

Die Lizenz für SDK for Linux 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 Linux installiert ist.

| | |

# Gemeinsame Nutzung von Klassendaten auf verschiedenen JVMs

|

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.

| |

## Übersicht über die gemeinsame Nutzung von Klassen

|

Mit IBM SDK können Sie so viele Klassen wie möglich gemeinsam nutzen. Dieser Vorgang läuft für den Benutzer transparent ab.

| |

### Cache-Inhalte

|

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

| |

### Dynamisches Aktualisieren des Caches

|

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.

| |

### Aktivieren der gemeinsamen Nutzung von Klassen

|

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

| |

### Cache-Sicherheit

|

Der Zugriff auf den Cache für gemeinsam genutzte Klassen wird durch Berechtigungen des Betriebssystems und Java-Sicherheitsberechtigungen begrenzt. Der Cache für gemeinsam genutzte Klassen wird standardmäßig mit Benutzerzugriff erstellt, außer wenn die Befehlszeilenunteroption groupAccess verwendet wird. 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.

| |

### Lebensdauer des Caches

|

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.

| |

### Cache-Dienstprogramme

|

Alle Cache-Dienstprogramme sind Unteroptionen des |Befehls -Xshareclasses. Mit |-Xshareclasses:help können Sie eine Liste der |verfügbaren Unteroptionen anzeigen.

| |

## Verwenden von Befehlszeilenoptionen für die gemeinsame Nutzung von Klassen

|

Die gemeinsame Nutzung von Klassen wird mit Hilfe der Befehlszeilenoptionen -Xshareclasses und -Xscmx aktiviert und konfiguriert.

|

|
- -Xscmx<Größe>[k|m|g] |
  |
  - Gibt die Cachegröße an. Diese Option wird nur angewendet, wenn ein Cache erstellt wird und noch kein Cache mit demselben Namen vorhanden ist. Die Standardcachegröße hängt von der |jeweiligen Plattform ab. |Den verwendeten Größenwert können Sie durch Hinzufügen von -verbose:sizes als Befehlszeilenargument ermitteln. Der Cache ist mindestens 4 KB groß. Die maximale Größe des |Caches hängt ebenfalls von der Plattform ab. (Siehe hierzu die |Informationen im Abschnitt Grenzwerte für die Cachegröße.)
|
- -Xshareclasses:<Unteroption1>[,<Unteroption2>...] |
  |
  - Aktiviert die gemeinsame Nutzung von Klassen. Hierfür liegt |eine Reihe von Unteroptionen vor, bei denen es sich bei einigen um |Cache-Dienstprogramme handelt. Cache-Dienstprogramme führen den erforderlichen Vorgang für den angegebenen Cache durch, ohne VM zu starten. Sie können mehrere Unteroptionen miteinander |kombinieren, wobei diese durch Kommas voneinander getrennt sein |müssen. Die Cache-Dienstprogramme schließen sich allerdings |gegenseitig aus.
  Zusammen mit der Option -Xshareclasses können Sie folgende Unteroptionen verwenden, z. B. |-Xshareclasses:help. |
  |
  - help |
    |
    - Listet alle Befehlszeilenoptionen auf.
  |
  - name=<Name> |
    |
    - Stellt die Verbindung zu einem Cache mit einem bestimmten |Namen her und erstellt den Cache, falls er nicht bereits |vorhanden ist. Mit der Dienstprogrammoption listAllCaches |kann angezeigt werden, welche Caches derzeit verfügbar sind. Wenn Sie keinen Namen angeben, wird als Cachename der Standardname |"sharedcc_" verwendet, an den der aktuelle Benutzername angehängt wird.
  |
  - groupAccess |
    |
    - Legt die Betriebssystemberechtigungen für einen neuen Cache so fest, dass der Gruppenzugriff auf den Cache erlaubt wird. Standardmäßig ist nur Benutzerzugriff zulässig.
  |
  - verbose |
    |
    - Mit dieser Option kann eine ausführliche Ausgabe zu E/A-Aktivitäten im Cache angezeigt werden. Dabei werden Informationen zu Klassen aufgelistet, |die gespeichert und gefunden wurden. Für jedes |Klassenladeprogramm wird eine eindeutige ID vergeben (das |Bootladeprogramm hat immer die ID 0), und in der Ausgabe ist |die Funktionsweise der Hierarchie von Klassenladeprogrammen dargestellt. |Die Klassenladeprogramme müssen bei den zugehörigen |übergeordneten Programmen eine Klasse anfordern, bevor sie diese selbst |laden können. Es ist normal, dass zahlreiche fehlgeschlagene Anforderungen angezeigt werden. Dieses Verhalten wird in der Hierarchie von Klassenladeprogrammen erwartet. Beachten Sie, dass mit der Standardoption -verbose:class auch die |ausführliche Ausgabe für die gemeinsame Klassennutzung aktiviert wird, falls die gemeinsame Nutzung von Klassen aktiviert ist.
  |
  - modified=<Geänderter Inhalt> |
    |
    - Diese Option muss angegeben werden, wenn ein Bytecode-Agent |installiert wurde, der möglicherweise den Bytecode während der Laufzeit |ändert. Wenn Sie diese Option nicht angeben und ein Bytecode-Agent |installiert ist, werden im Cache keine Klassen gespeichert oder |gefunden. Bei der Angabe <Geänderter Inhalt> handelt es sich um einen vom Benutzer |ausgewählten Deskriptor, z. B. "MeineÄnderungen1". Hiermit wird der Cache so partitioniert, dass nur JVMs, die den |Kontext "MeineÄnderungen1" verwenden, dieselben Klassen gemeinsam |nutzen können. Wenn Sie z. B. "HelloWorld" zusammen mit einem |Änderungskontext ausführen und anschließend mit einem |anderen Änderungskontext erneut ausführen, werden alle |Klassen zweimal im Cache gespeichert.
  |
  - destroy (Dienstprogrammoption) |
    |
    - Löscht einen Cache unter Verwendung des Namens, der mit |der Unteroption name=<Name> |angegeben wurde. Falls kein Name angegeben wird, wird der Standardcache gelöscht. Ein Cache kann nur gelöscht werden, wenn alle VMs, die |diesen Cache verwenden, heruntergefahren wurden und der Benutzer über |die erforderlichen Berechtigungen verfügt.
  |
  - destroyAll (Dienstprogrammoption) |
    |
    - Versucht, alle für den Benutzer verfügbaren Caches zu |löschen. Ein Cache kann nur gelöscht werden, wenn alle VMs, die |diesen Cache verwenden, heruntergefahren wurden und der Benutzer über |die erforderlichen Berechtigungen verfügt.
  |
  - expire=<Zeit in Minuten> (Dienstprogrammoption) |
    |
    - Löscht alle Caches, die während des angegebenen |Zeitraums nicht verwendet wurden.
  |
  - listAllCaches (Dienstprogrammoption) |
    |
    - Listet alle Caches im System auf und zeigt an, ob diese im Gebrauch sind und wann sie zum letzten Mal verwendet wurden.
  |
  - printStats (Dienstprogrammoption) |
    |
    - Zeigt eine Zusammenfassung statistischer Daten zu dem |Cache an, der über die Unteroption name=<Name> |angegeben wurde. Falls kein Name angegeben wird, werden statistische Daten zum |Standardcache angezeigt. Zu den nützlichsten |Informationen gehören die Angaben zur Speicherbelegung im Cache und die Anzahl der darin enthaltenen Klassen. Beachten Sie, dass es sich bei "veralteten" Klassen um Klassen handelt, die auf dem |Dateisystem aktualisiert wurden und die der Cache daher mit "veraltet" gekennzeichnet hat. Veraltete Klassen werden nicht |aus dem Cache gelöscht. Weitere Informationen finden Sie im Handbuch Diagnostics |Guide.
  |
  - printAllStats (Dienstprogrammoption) |
    |
    - Zeigt ausführliche Informationen zum Inhalt des Caches an, |der in der Unteroption name=<Name> |angegeben wurde. |Falls kein Name angegeben wird, werden statistische Daten zum |Standardcache angezeigt. |Alle Klassen werden in chronologischer |Reihenfolge zusammen mit einem Verweis auf die Speicherposition |aufgelistet, von der aus sie geladen wurden. Weitere Informationen finden Sie im Handbuch Diagnostics |Guide.

| |

## Erstellen, Belegen, Überwachen und Löschen eines Caches

|

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.

| |

## Leistung und Speicherbelegung

|

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.

| |

## Einschränkungen und besondere Aspekte bei der gemeinsamen Nutzung von Klassen

| |

### Grenzwerte für die Cachegröße

|

Der Cache für gemeinsam genutzte Klassen wird mit dem Mechanismus 'System V IPC' für gemeinsam genutzten Speicher zugewiesen.

|

Die maximale theoretische Cachegröße beträgt 2 GB. Die Cachegröße, die Sie angeben können, wird durch den auf dem System verfügbaren physikalischen Speicher und den Umlagerungsspeicher begrenzt.

|

Da der virtuelle Adressraum eines Prozesses vom Cache für gemeinsam genutzte Klassen und dem Java-Freispeicher gemeinsam genutzt wird, verringert sich bei Erhöhung der maximalen Größe des Java-Freispeichers die Größe des Caches für gemeinsam genutzte Klassen, den Sie erstellen können.

|

Die Cachegröße ist durch die Einstellungen für |SHMMAX begrenzt, da hiermit der |gemeinsam genutzte Speicher begrenzt wird, der |zugeordnet werden kann. Diese Einstellungen sind in der Datei |/proc/sys/kernel/shmmax enthalten. Der Wert für SHMMAX |wird normalerweise auf 30 MB festgelegt.

| |

### Änderungen bei Laufzeitbytecodes

|

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.

| |

### Betriebssystemeinschränkungen

|

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 |/tmp/javasharedresources 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. Mit dem Befehl `ipcs` können Sie |die von VM oder einer Anwendung verwendeten Speichersegmente |anzeigen.

|

Benutzer, die JVM ausführen, müssen zur Verwendung |eines Caches für gemeinsam genutzte Klassen in derselben Gruppe |sein. 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.

| |

### Verwenden von SharedClassPermission

|

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.

| |

## Anpassen benutzerdefinierter Klassenladeprogramme an gemeinsam genutzte Klassen

|

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.

# Service und Unterstützung für unabhängige Softwareanbieter

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.

# Eingabehilfen

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.

## iKeyman-Eingabehilfen

|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:

<Objekt>
  steht für Folgendes:
  -keydb
    Aktionen, die für die Schlüsseldatenbank ausgeführt werden (eine CMS-Schlüsseldatei, eine WebDB-Schlüsselringdatei oder SSLight-Klasse).
  -cert
    Aktionen, die für ein Zertifikat in einer Schlüsseldatenbank ausgeführt werden sollen.
  -certreq
    Aktionen, die für eine Zertifikatsanforderung in einer Schlüsseldatenbank ausgeführt werden sollen.
  -version
    Zeigt Versionsinformationen für IKEYCMD an.
  -help
    Zeigt einen Hilfetext für die IKEYCMD-Aufrufe an.
<Aktion>
  |Die Aktion, die für das Objekt ausgeführt werden soll. Wenn Sie die verfügbaren Aktionen für ein Objekt anzeigen wollen, rufen Sie IKEYCMD auf, wobei nur das Objekt als Argument übergeben wird. In der kontextbezogenen Hilfe werden die verfügbaren Aktionen für dieses Objekt angezeigt.
-Dikeycmd.properties
  Gibt den Namen einer optionalen Merkmaldatei an, die für diesen Java-Aufruf verwendet werden soll. Die Standardmerkmaldatei ikeycmd.properties wird als Musterdatei zur Verfügung gestellt, die geändert und von einer beliebigen Java-Anwendung verwendet werden kann.

Anmerkung:
Die Objekt- und Aktionsschlüsselwörter müssen in der angegebenen Reihenfolge aufgeführt sein. Optionen sind jedoch nicht positionsgebunden und können in beliebiger Reihenfolge aufgeführt werden, sofern sie als Option und Operandenpaar angegeben werden.

Weitere Informationen finden Sie im Handbuch "iKeyman User Guide" unter http://www.ibm.com/developerworks/java/jdk/security/index.html.

## Verschieben des Eingabefokus von JComboBox-Komponenten in Swing per Tastatur

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.

## (nur Linux IA (32 Bit), PPC32 und PPC64) Web Start-Eingabehilfen

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

# Bekannte Einschränkungen

In den folgenden Abschnitten werden bekannte Einschränkungen von SDK und Runtime Environment for Linux erläutert.

## Einschränkungen, die für alle Linux-Plattformen gelten (wenn nicht anders angegeben)

- |Ihr Window Manager setzt möglicherweise einige Java-Tastaturkurzbefehle außer Kraft. Wenn Sie einen außer Kraft gesetzten Tastaturkurzbefehl verwenden wollen, ziehen Sie das Handbuch zu Ihrem Betriebssystem zu Rate, und ändern Sie die Tastaturkurzbefehle des Window Managers. |

- |X Window System kann keine Dateideskriptoren über 255 verwenden. Da JVM Dateideskriptoren für geöffnete Jar-Dateien verwendet, ist es möglich, dass für X nicht mehr genügend Dateideskriptoren zur Verfügung stehen. Als Fehlerumgehung können Sie die Umgebungsvariable JAVA_HIGH_ZIPFDS so definieren, dass sie JVM anweist, höhere Dateideskriptoren für Jar-Dateien zu verwenden. |

  Setzen Sie die Umgebungsvariable JAVA_HIGH_ZIPFDS auf einen Wert zwischen 0 und 512, um sie zu verwenden. JVM öffnet dann die ersten JAR-Dateien mit den Dateideskriptoren bis 1024. Legen Sie die Umgebungsvariable z. B. wie folgt fest, wenn Ihr Programm voraussichtlich 300 JAR-Dateien öffnet:

  `export JAVA_HIGH_ZIPFDS=300` |

  Die ersten 300 JAR-Dateien werden dann mit den Dateideskriptoren 724 bis 1023 geladen. Alle JAR-Dateien, die danach geöffnet werden, werden im normalen Bereich geöffnet.

- Möglicherweise können Sie bei Verwendung von KDE (K Desktop Environment) keine DBCS-Daten (Double Byte Character Set, Doppelbytezeichensatz) über die Systemzwischenablage zwischen Linux-Anwendungen und Java-Anwendungen kopieren.

- Unter RHEL3, SLES9 und neueren Distributionen ist die Standardthreadbibliothek NPTL. Sie implementiert Java-Threads als native Threads. Unter früheren Distributionen lautete die Standardthreadbibliothek LinuxThreads. Sie implementiert Threads als neue Prozesse. Wenn die Anzahl der Java-Threads die maximal zulässige Anzahl an Prozessen überschreitet, blockiert Ihr System möglicherweise.

  Die maximale Anzahl der verfügbaren Threads wird durch das Minimum für die folgenden Werte bestimmt:

  - Die Einstellung für die Benutzerprozesse (ulimit -u) in /etc/security/limits.conf
  - Die in /proc/sys/kernel/threads_max definierte Begrenzung
  - Die in libpthreads.so definierte Begrenzung PTHREAD_THREADS_MAX (bei Änderung dieses Werts muss glibc erneut kompiliert werden)

  Bevor die maximale Anzahl an Threads erreicht wird, kann jedoch der virtuelle Speicher voll sein.

- Wenn Sie eine Java-Anwendung mit Strg-C beendet haben, bleiben einige Prozesse möglicherweise verwaist.

- Die Ergebnisse von Tastenkombinationen mit der Taste ALT weichen bei Verwendung verschiedener Window Manager unter Linux ab. Sie weichen auch von Ergebnissen anderer Betriebssysteme ab. Im Window Manager "Enlightenment" generieren die Tastenkombinationen Alt+A und Umschalt+Alt+A verschiedene Änderungswerte, und Strg+Alt+A erzeugt kein Ereignis. Bei Verwendung des Window Managers "WindowMaker" erzeugt die Tastenkombination Strg+Alt+A jedoch ein Tastenereignis.

- Auf einem X Window System unter Linux ist die Tastenbelegung wie folgt festgelegt: 64 0xffe9 (Alt_L) 0xffe7 (Meta_L) und 113 0xffea (Alt_R) 0xffe8 (Meta_R). Dies können Sie überprüfen, indem Sie an einer Shelleingabeaufforderung den folgenden Befehl eingeben:

      xmodmap -pk

  Daher erwartet SDK, dass Meta zusammen mit Alt gedrückt wird. Sie können dies umgehen und die Meta_x-Zuordnung entfernen, indem Sie Folgendes an der Shelleingabeaufforderung eingeben:

      xmodmap -e "keysym Alt_L = Alt_L" -e "keysym Alt_R = Alt_R"

  Anmerkung:
  Diese Lösung kann sich auf andere X-Windows-Anwendungen auswirken, die über dieselbe Anzeige ausgeführt werden, wenn die Meta-Tastenkombination verwendet wird, die Sie zuvor entfernt haben.

- Das Erstellen von besonders langen DSA-Schlüsselpaaren kann auf langsamen Maschinen sehr lange dauern. Interpretieren Sie die Verzögerung nicht als Blockierung, weil der Prozess nach ausreichender Zeit beendet wird. Der Algorithmus für die Generierung von DSA-Schlüsseln wurde optimiert, um Schlüssel mit Standardlängen (z. B. 512 oder 1024) schneller zu generieren als andere.

- Native Programme können keine VM mit JNI_VERSION_1_1(0x00010001)-Schnittstellen erstellen. Es ist nicht möglich, JNI_CreateJavaVM() aufzurufen und eine Version von JNI_VERSION_1_1(0x00010001) weiterzuleiten. Die folgenden Versionen können weitergeleitet werden:
  - JNI_VERSION_1_2(0x00010002)
  - JNI_VERSION_1_4(0x00010004)

  Bei der erstellten VM handelt es sich um diejenige, die über die vorhandenen Bibliotheken (1.2.2., 1.3.x, 1.4.x, 5.x) festgelegt wird, und nicht um diejenige, die über die weitergeleitete JNI-Schnittstellenversion festgelegt wird.

  Die Schnittstellenversion hat nur Auswirkungen auf die für den nativen Code verfügbaren Funktionen.

- Der Aufruf von JNI_CreateJavaVM() über eine JNI-Anwendung kann zu einem Segmentierungsfehler führen (Signal SIGSEGV). Zum Vermeiden dieses Fehlers müssen Sie das JNI-Programm unter Angabe der Option -lpthread erneut erstellen.

- (Nur für Benutzer der Version in traditionellem Chinesisch) Funktionstasten, wie die Eingabetaste, die Leertaste, die Rückschritt-Taste und die Taste Esc funktionieren nicht ordnungsgemäß, wenn zum Eingeben der TCH-Zeichen die IMEs LinYi ZhuYin, YiTian ZhuYin und Bosham verwendet werden. Mit der Eingabetaste wird eine neue Zeile eingefügt, die Taste Esc wird zum Abbrechen der zuvor editierten Zeichenfolgen oder des Kandidatenfensters verwendet, und mit der Leertaste wird ein Leerzeichen eingefügt. Nachdem die Taste zum Festschreiben gedrückt wurde, sollte das Kandidatenfenster nicht mehr angezeigt werden. Es sollte außerdem nicht angezeigt werden, wenn Sie die Rückschritt-Taste drücken, während Sie für die Eingabe von Zeichen in traditionellem Chinesisch die IMEs LinYi ZhuYin, YiTian ZhuYin und Bosham verwenden.

- Wenn Sie viele gleichzeitig ablaufende Threads ausführen, wird möglicherweise eine Warnung angezeigt: `java.lang.OutOfMemoryError`. Es handelt sich dabei um eine Meldung, dass nicht genügend Systemressourcen zur Verfügung stehen und Nachrichten aus folgenden Gründen angezeigt werden können:
  1. Neue Threads können aus folgenden Gründen nicht erstellt werden:
     - Die Anzahl der erstellten Prozesse überschreitet den für den Benutzer festgelegten Grenzwert. (Wenn Ihre Linux-Installation eher LinuxThreads als NPTL verwendet.)
     - Es stehen nicht genügend Systemressourcen zum Erstellen neuer Threads zur Verfügung. In diesem Fall werden möglicherweise weitere Java-Ausnahmebedingungen angezeigt, abhängig davon, welche Operationen Ihre Anwendung ausführt.
  2. Der Kernelspeicher bietet entweder nicht genügend Kapazität oder ist fragmentiert. Im Verzeichnis /var/log/messages finden Sie entsprechende Kernelnachrichten, die darauf hinweisen, dass nicht genügend Speicher vorhanden ist, und die die ID des mit dem Befehl 'kill' beendeten Prozesses aufweisen.
  Versuchen Sie, Ihr System dahingehend zu optimieren, dass die entsprechenden Systemressourcen erhöht werden.

- Wenn Sie bereits eine frühere Version dieses Produkts installiert haben, das von Red Hat verteilt wurde, berichtet Red Hat Package Manager (RPM), dass das IBM-Paket älter als alle Versionen der Red Hat Distribution ist. Diese Situation tritt ein, weil Red Hat dem RPM-Paket eine "Seriennummer" hinzufügt, die das Schema zur Versionssteuerung des Produkts im Paket außer Kraft setzt. Standardmäßig verweigert RPM die Installation eines Pakets, das älter als das bereits installierte Paket zu sein scheint. Die Option --oldpackage des Befehls rpm ermöglicht die Installation des neuen IBM-Pakets.

- Wenn Sie eine Java AWT/Swing-Anwendung auf einer Linux-Maschine ausführen und die Anzeige auf eine andere Maschine exportieren, treten möglicherweise Fehler beim Anzeigen einiger Dialoge auf, wenn die Gruppe der geladenen Schriftarten auf der X-Clientmaschine sich von der Gruppe unterscheidet, die auf der X-Servermaschine geladen wurde. Dieser Fehler tritt hauptsächlich unter SLES8 mit chinesischen Ländereinstellungen auf. Dort werden während der Standardinstallation der Serverversion Arphic Fonts installiert, bei der Standardinstallation des Clients werden diese Schriftarten jedoch nicht installiert. Installieren Sie zur Vermeidung dieses Fehlers auf beiden Maschinen dieselben Schriftarten.

- Wenn in der Ländereinstellung Ihres Systems eine UTF-8-Verschlüsselung verwendet wird, lösen einige SDK-Tools möglicherweise die Ausnahmebedingung sun.io.MalformedInputException aus. Wenn Sie herausfinden möchten, ob Ihr System eine UTF-8-Verschlüsselung verwendet, untersuchen Sie die für die Ländereinstellung spezifischen Umgebungsvariablen, wie z. B. LANG oder LC_ALL, um zu prüfen, ob sie mit dem Suffix ".UTF-8" enden. Wenn Sie die Ausnahmebedingung sun.io.MalformedInputException abrufen, ändern Sie die Zeichen, die nicht im 7-Bit-ASCII-Bereich (0x00 - 0x7f) liegen und nicht als Java-Unicode-Zeichenliterale dargestellt werden, in Java-Unicode-Zeichenliterale (z. B. '\u0080'). Sie können dieses Problem auch umgehen, indem Sie das Suffix ".UTF-8" aus den für die Ländereinstellung spezifischen Umgebungsvariablen entfernen. Wenn Ihre Maschine beispielsweise die Standardländereinstellung "en_US.UTF-8" hat, setzen Sie LANG auf "en_US".
  Anmerkung:
  Einige Distributionen von Red Hat, einschließlich Red Hat 9 und RHEL3, verwenden die UTF-8-Verschlüsselung standardmäßig.

- Wenn Sie AMI und xcin in einer plattformübergreifenden Umgebung verwenden (z. B., wenn Sie versuchen, die Anzeige von einem 32-Bit- in ein 64-Bit-System bzw. von einem Big Endian- in ein Little Endian-System zu exportieren), treten möglicherweise Probleme auf. Wenden Sie sich an Ihren Linux-Distributor, wenn dies der Fall ist.

- Unter Red Hat Enterprise Linux 3 werden chinesische Zeichen möglicherweise nicht in AWT-Textkomponenten angezeigt, mit Ausnahme von GB2312-Zeichen in der chinesischen Ländereinstellung GB18030.

- |Im Tool JConsole von IBM ist die Indexzunge Local, über die Sie Verbindungen zu anderen virtuellen Maschinen auf dem selben System herstellen können, nicht verfügbar. Verwenden Sie stattdessen die Indexzunge Remote in JConsole, um eine Verbindung zu der virtuellen Maschine herzustellen, die Sie überwachen wollen. Legen Sie beim Starten der zu überwachenden Anwendung die folgenden Befehlszeilenoptionen fest: |
  |
  - -Dcom.sun.management.jmxremote.port=<Wert> zum Angeben des Ports, an dem der Managementagent empfangsbereit sein soll
  |
  - -Dcom.sun.management.jmxremote.authenticate=false zum Inaktivieren der Authentifizierung, sofern Sie keine Benutzernamendatei erstellt haben
  |
  - -Dcom.sun.management.jmxremote.ssl=false zum Inaktivieren der SSL-Verschlüsselung
  |

- |Nur für Benutzer der chinesischen, koreanischen und japanischen Version von Red Hat Enterprise Linux 4: Wenn Sie IIIMF (Internet/Intranet Input Method Framework) verwenden, verwenden Sie IIIMF-Pakete, die in Red Hat Enterprise |Linux 4 Update 2 oder höher enthalten sind. Beachten Sie außerdem das folgende Problem. Wenn das folgende Problem auftritt, wenden Sie sich an Red Hat unter http://www.redhat.com, um Hilfe zu erhalten. |
  |
  - Unter Linux zSeries (64 bit) können IIIMF-Fehler oder Startfehler auftreten. Benutzer der japanischen Version finden Informationen hierzu unter der Red Hat Bugzilla-Nummer RIT73533.
  |

- |Nur für Benutzer der Version von Red Hat Enterprise |Linux 4 in vereinfachtem Chinesisch. Die Ländereinstellung zh_CN.GB18030 wird von xlib in RHEL4 nicht unterstützt. xterm kann den Input Method Server nicht für die Eingabe von GB18030-Zeichen aktivieren. Verwenden Sie stattdessen, die Ländereinstellung zh_CN.UTF8. Wenn Sie über traditionelle Programme oder Daten verfügen, die mit GB2312, GBK oder GB18030 verschlüsselt sind, und Sie diese auf RHEL4 migrieren wollen, müssen Sie sie mit iconv vorverarbeiten, um sie in UTF-8 zu konvertieren. Dadurch können die Programme ausgeführt und die Daten ordnungsgemäß in RHEL4 mit der Ländereinstellung zh_CN.UTF8 angezeigt werden. |

- |Unter RHEL 3 mit miniChinput (XIM-Server für vereinfachtes Chinesisch) kann in 64-Bit-Umgebungen (z. B. AMD64- oder zSeries-64-Bit-Plattformen) ein nicht erwartetes Verhalten mit Java auftreten. Wenden Sie sich an Red Hat unter http://www.redhat.com, um Hilfe zu erhalten. Informationen hierzu finden Sie unter der Red Hat Bugzilla-Nummer RIT75701. |

- |Unter RHEL 3 mit ami (XIM-Server für Koranisch) kann mit Java in 64-Bit-Umgebungen (z. B. AMD64- oder zSeries-64-Bit-Plattformen) ein nicht erwartetes Verhalten auftreten. Wenden Sie sich an Red Hat unter http://www.redhat.com, um Hilfe zu erhalten. Informationen hierzu finden Sie unter den Red Hat Bugzilla-Nummern RIT73605 und RIT75708. |

- |Unter RHEL 4 mit xcin (XIM-Server für traditionelles Chinesisch) kann mit Java in 64-Bit-Umgebungen (z. B. AMD64- oder zSeries-64-Bit-Plattformen) ein nicht erwartetes Verhalten (z. B. ein Segmentierungsfehler) auftreten. Wenden Sie sich an Red Hat unter http://www.redhat.com, um Hilfe zu erhalten. Informationen hierzu finden Sie unter der Red Hat Bugzilla-Nummer RIT78430. |

- |Benutzer der japanischen, chinesischen und koreanischen Version können XIM nicht für die Eingabe ihrer eigenen Zeichen in Textkomponenten in einem Java-Applet in einem Web-Browser verwenden. |Diese Einschränkung tritt auf, da XEmbed eine Programmkorrektur für die X11-Bibliotheksdatei erfordert. |Wenn Sie diese Situation vermeiden wollen, geben Sie den Systemparameter -Dsun.awt.noxembed=true an, um XEmbed zu inaktivieren. Sie können diese Option mit Hilfe der Systemsteuerung definieren: |
  |
  1. Öffnen Sie die Systemsteuerung des Java-Plug-ins, und wechseln Sie in die Indexzunge Java.
  |
  2. Klicken Sie den Knopf Anzeigen in den Java-Applet-Laufzeiteinstellungen an.
  |
  3. Geben Sie -Dsun.awt.noxembed=true in den Java-Laufzeitparametern ein, und klicken Sie OK an.
  |
  4. Klicken Sie Anwenden an.
  |
  5. Starten Sie einen Browser.
  |

## Einschränkungen für Linux IA (32 Bit)

- (Für Benutzer von arabischem Text) Bei der Verwendung von Linux mit einer Matrox-Videokarte und aktivierter Beschleunigung können Zeichen nur verzerrt angezeigt werden, wenn zum Anzeigen großer Schriftarten drawString verwendet wird. Dieser Fehler wird durch den Treiber dieser Karten verursacht. Die empfohlene Fehlerumgehung besteht darin, die Beschleunigung für diese Einheit zu inaktivieren.

- Bei Verwendung der NPTL unter SLES 9 verursacht der Parallelanschlusstreiber einen Kernelabsturz und stoppt einen Java-Thread. Die JVM stellt diesen Absturz fest, wenn sie versucht, den Thread für die Garbage-Collection zurückzustellen, und stürzt dann ab. Dabei wird eine Kerndatei erstellt und die Nachricht "JVMLH030: threads are disappearing when trying to suspend all threads" angezeigt.

  Dieser Fehler wird im SUSE Bugzilla Report 47947 beschrieben. Er wurde unter SLES 9 Service-Pack 1 behoben.

## Einschränkungen für Linux AMD64

| |
- Wichtiger Hinweis zu BIOS-Einstellungen auf AMD64 SMP-Systemen: |

  Die BIOS-Einstellung Node memory interleaving muss auf |`DISABLED` gesetzt werden. Andernfalls können unvorhersehbare Fehler auftreten, |wie z. B. Ausfälle und Blockierungen in Java-Anwendungen. Diese Anweisung stimmt mit den |Empfehlungen von AMD überein.

## Einschränkungen für Linux PPC (32 Bit) und (64 Bit)

- Wenn der Java-Code JNI-Aufrufe verwendet und ein bestimmter Aufruf mehr als acht FLOAT- oder DOUBLE-Parameter aufweist, muss der C-Code mit der FSF-Stufe (Free Software Foundation) gcc-2.95.3 des GNU-C-Compilers (GCC) kompiliert werden.

- Wenn Sie XFree86 Version 3.x ausführen, wird möglicherweise ein SIGSEGV-Fehler angezeigt. Zur Vermeidung dieses Fehlers sollten Sie XFree86 Version 4.x verwenden.

- Wenn auf dem System ein Datum vor 1970 eingestellt ist, wird beim Starten von Java eine Ausnahmebedingung angezeigt. Sie können diesen Fehler vermeiden, wenn Sie auf Ihrer Maschine das aktuelle Datum festlegen.

- Das JavaComm-Paket kann unter der GA-Version von SLES 9 und auf SP1-Kerneln keine Parallelanschlussoperationen unterstützen. Diese Einschränkung wird im SP2-Kernel behoben. Die SUSE Bugzilla-Nummer ist 50028.

- Auf Grund einer nicht implementierten IOCTL-Funktion im 32-Bit-Modus des 64-Bit-Kernels kann JavaComm Operationen über den seriellen Anschluss unter SLES 9 und RHEL 4 nicht unterstützen. Diese Einschränkung wird unter SLES 9 SP2 (Bugzilla-Nummer 49787) und RHEL 4 Update 1 (Bugzilla-Nummer 144904) behoben.

## Einschränkungen für Linux PPC (64 Bit)

- Der systemübergreifende gcc-Standardcompiler (Version 3.2-49) verursacht verschiedene Fehler. Wenn Sie die gemeinsam genutzte Bibliothek libFileStat.so generieren wollen, führen Sie `/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<SDK_PATH>/include FileStat.c` aus, wobei `<SDK_PATH>` der Pfad zum Verzeichnis des installierten SDKs ist.

## Einschränkungen für Linux zSeries (64 Bit)

Die folgenden Einschränkungen gelten für Benutzer der chinesischen und taiwanesischen Version unter Linux zSeries (64 Bit):

- Der chinesische und taiwanesische Input Method Server (xcin) wurde mit Version 5.0 nicht getestet.

## Einschränkungen für Linux zSeries (31 und 64 Bit)

- Wenn Sie die Audiofunktion auf einer Maschine ohne Audiokarte verwenden, wird möglicherweise die Fehlernachricht angezeigt, dass nicht genügend Speicher vorhanden ist, wenn Java versucht, einen Ton wiederzugeben. Die Nachricht wird in der Konsole angezeigt, sie hat jedoch keine Auswirkungen auf die Java-Anwendung.

- Obwohl der Linux-Kernel in den aktuellen Verteilungen Unterstützung für Internet Protocol Version 6 (IP6) bietet, treten bei der Verwendung möglicherweise Probleme auf. In diesem Release ist die Unterstützung für IP6 durch Java enthalten. Es wird allerdings empfohlen, dass Sie diese Unterstützung mit der Option -Djava.net.preferIPv4Stack=true des Befehls Java inaktivieren. Wenn Sie einen Kernel installieren, der IP6 vollständig unterstützt, benötigen Sie diese Option nicht.

- |Wenn Sie Java für zSeries (31 Bit oder 64 Bit) mit X Windows Server verwenden und eine hohe Auflösung eingestellt haben, werden die Zeichen in einer AWT Choice-Komponente mit Motif AWT möglicherweise abgeschnitten. Verringern Sie die Einstellung für die Auflösung, oder verwenden Sie XAWT an Stelle von Motif AWT, um diese Situation zu vermeiden. |

# Kommentare zu diesem Handbuch

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:

- Per E-Mail: idrcf@hursley.ibm.com
- Per Fax:
  - Von Großbritannien: 01962 842327
  - Von anderen Ländern: <Internationaler Code>44 1962 842327
- Per Post:
  IBM United Kingdom Ltd
  User Technologies,
  Mail Point 095
  Hursley Park
  Winchester
  Hampshire
  SO21 2JN
  United Kingdom

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.

# Bemerkungen

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):

- IBM Europe
  Director of Licensing
  92066 Paris La Defense Cedex
  France

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:

- JIMMAIL@uk.ibm.com
  [Ansprechpartner im Hursley Java Technology Center (JTC)]

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.

## Marken

IBM, iSeries, pSeries und zSeries sind in gewissen Ländern Marken oder eingetragene Marken der International Business Machines Corporation.

Intel ist in gewissen Ländern eine Marke der Intel Corporation.

Java und alle Java-basierten Marken und Logos sind in gewissen Ländern Marken oder eingetragene Marken von Sun Microsystems, Inc.

Linux ist in gewissen Ländern eine Marke von Linus Torvalds.

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.