# IBM Runtime Environment for Linux on AMD64 architecture, Java 2 Technology Edition, Version 1.4.2

# Runtime Environment 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 Runtime Environment for Linux on AMD64 architecture, Java 2 Technology Edition, Version 1.4.2.

(c) Copyright Sun Microsystems, Inc. 1997, 2003, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Alle Rechte vorbehalten.

(c) Copyright International Business Machines Corporation, 1999, 2004. Alle Rechte vorbehalten.

(c) Copyright IBM Deutschland GmbH 1999, 2004. Alle Rechte vorbehalten.

# Vorwort

Dieses Benutzerhandbuch beschreibt IBM(R) Runtime Environment for Linux(TM) on AMD64 architecture.

IBM Runtime Environment umfasst Java(TM) Virtual Machine (JVM), die wichtigsten Java-Klassen von Sun Microsystems und Unterstützungsdateien. Runtime Environment enthält nicht alle Klassen des SDK-Pakets.

Das Benutzerhandbuch stellt allgemeine Informationen zu Runtime Environment und spezielle Informationen zu allen Unterschieden zwischen der IBM Implementierung und der Sun Microsystems-Implementierung von Runtime Environment zur Verfügung. Lesen Sie dieses Benutzerhandbuch zusammen mit der ausführlicheren Dokumentation auf der folgenden Website von Sun Microsystems: http://java.sun.com.

Das Handbuch IBM JVM Diagnostics Guide enthält weitere Informationen zu IBM JVM.

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

Beachten Sie, dass es sich bei Runtime Environment for Linux um eine Untergruppe von SDK handelt, mit der Sie nur Java-Anwendungen ausführen können. Wenn Sie SDK installiert haben, ist auch Runtime Environment enthalten.

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

# Inhaltsverzeichnis

Copyrightvermerk
Vorwort
Übersicht
In Runtime Environment for Linux enthaltene Dateien
Lizenzvereinbarung
Der JIT-Compiler (Just-in-Time)
Java Native Interface und Native Method Interface
Konfigurieren von Runtime Environment
Deinstallieren von Runtime Environment for Linux
Deinstallieren des installierbaren RPM-Pakets (Red Hat Package Manager)
Deinstallieren des komprimierten TAR-Pakets (Tape Archive)
Starten einer Java-Anwendung
Befehle im Überblick
Optionen
Standardoptionen
Vom Standard abweichende Optionen
Globalisierung des Befehls 'java'
Arbeiten mit Klassenpfaden
Angeben der Garbage-Collection-Richtlinie
Pausezeit
Verringerung der Pausezeit
Umgebungen mit sehr vollen Freispeichern
Signalverarbeitung durch die JVM
Von der JVM verwendete Signale
Verbinden eines nativen Codetreibers mit der Signalverkettungsbibliothek
Implementieren des Steuerroutinenpools für Verbindungen für RMI
Abrufen der IBM Build- und Versionsnummer
Verwenden der Funktion 'floating stacks'
Ändern der Eingabemethode in DBCS-Sprachen
Installieren Ihrer Anwendung auf dem System eines Benutzers
Bekannte Einschränkungen
Kommentare zu diesem Handbuch
Bemerkungen
Marken

# Übersicht

Runtime Environment umfasst die Java Virtual Machine, Java-Klassen und Unterstützungsdateien. Runtime Environment enthält nur eine Untergruppe der Klassen, die im SDK gefunden werden, und ermöglicht es Ihnen, Java-Klassen auszuführen. Es ist jedoch nicht zulässig, Java-Programme zu kompilieren.

## In Runtime Environment for Linux enthaltene Dateien

Runtime Environment for Linux enthält binäre Objektdateien und Klassendateien, die zur Unterstützung eines Programms zur Laufzeit benötigt werden. Runtime Environment for Linux enthält keines der Entwicklungstools, wie appletviewer oder den Java-Compiler (javac), und auch keine Klassen, die nur zu einem Entwicklungssystem gehören.

Außerdem wird das Paket von Java Communications API für die Verwendung mit Runtime Environment for Linux bereitgestellt. Wenn Sie Java Communications API installiert haben, finden Sie zugehörige Informationen im Handbuch JavaComm API User Guide.

## Lizenzvereinbarung

Die Datei LICENSE_xx.html enthält die Lizenzvereinbarung für die Software von Runtime Environment for Linux. (xx ist eine Abkürzung für die Sprache.)

Zum Anzeigen oder Drucken der Lizenzvereinbarung können Sie die Datei in einem Webbrowser öffnen.

## Der JIT-Compiler (Just-in-Time)

Der JIT-Compiler (Just-in-Time), libjitc.so, generiert während der Ausführung dynamisch Maschinencode für häufig verwendete Bytecodesequenzen in Java-Anwendungen und Java-Applets.

Runtime Environment für Linux enthält den JIT-Compiler (libjitc.so), der standardmäßig aktiviert ist. Sie können den JIT-Compiler inaktivieren, um beispielsweise mögliche Probleme mit einer Java-Anwendung, einem Java-Applet oder dem Compiler selbst einzugrenzen.

Verwenden Sie zum Inaktivieren des JIT-Compilers die Option -Xint. Geben Sie in der Shelleingabeaufforderung, in der Sie die Anwendung ausführen, Folgendes ein:

        java -Xint Klasse

Wenn Sie prüfen wollen, ob der JIT-Compiler aktiviert ist, geben Sie folgenden Befehl an der Shelleingabeaufforderung ein:

        java -version

Wenn der JIT-Compiler aktiv ist, wird folgende Nachricht angezeigt:

    (JIT enabled)

Wenn der JIT-Compiler nicht aktiv ist, wird folgende Nachricht angezeigt:

    (JIT disabled)

## Java Native Interface und Native Method Interface

Java Native Interface (JNI) ist in Runtime Environment enthalten. Weitere Informationen zur Verwendung von JNI finden Sie auf der Sun-Website ( http://java.sun.com/j2se/1.4.2/docs/guide/jni).

IBM unterstützt Native Method Interface in diesem Release nicht. Diese Schnittstelle dürfen Sie in Ihren Anwendungen nicht verwenden.

# Konfigurieren von Runtime Environment

Nach der Installation von Runtime Environment müssen Sie Ihr Shellanmeldescript editieren und in der Anweisung PATH folgendes Verzeichnis hinzufügen:

/opt/IBMJava2-142/jre/bin

Wenn Sie Runtime Environment in einem Verzeichnis installiert haben, das nicht /opt/IBMJava2-142/ ist, müssen Sie das Verzeichnis /opt/IBMJava2-142/ durch das Verzeichnis ersetzen, in dem Sie Runtime Environment installiert haben.

# Deinstallieren von Runtime Environment for Linux

Der von Ihnen verwendete Deinstallationsprozess von Runtime Environment for Linux ist davon abhängig, ob auf Ihrem System das installierbare RPM-Paket (Red Hat Package Manager) oder das komprimierte TAR-Paket (Tape Archive) installiert ist. Anweisungen hierzu finden Sie im Abschnitt Deinstallieren des installierbaren RPM-Pakets (Red Hat Package Manager) oder Deinstallieren des komprimierten TAR-Pakets (Tape Archive).

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

Gehen Sie wie folgt vor, um Runtime Environment for Linux zu deinstallieren, wenn Sie das installierbare RPM-Paket installiert haben:

1. Geben Sie Folgendes an einer Shelleingabeaufforderung ein:

   -         rpm -e IBMJava2-JRE-1.4.2-0.0

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

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

Gehen Sie wie folgt vor, um Runtime Environment for Linux zu deinstallieren, wenn Sie das komprimierte TAR-Paket installiert haben:

1. Entfernen Sie die Runtime Environment-Dateien aus dem Verzeichnis, in dem Sie Runtime Environment installiert haben.
2. Entfernen Sie das Verzeichnis, in dem Sie Runtime Environment installiert haben, aus der Anweisung PATH.

# Starten einer Java-Anwendung

Mit dem Tool java wird eine Java-Anwendung gestartet. Dabei ist der Name einer ursprünglichen Java-Klasse als Parameter erforderlich. Wenn Sie keinen Java-Klassennamen angeben, wird ein Benutzungshinweis ausgegeben.

Die JVM sucht die ursprüngliche Klasse und andere verwendete Klassen in den drei folgenden Positionsgruppen: im Klassenpfad des Bootprogramms, in den installierten Erweiterungen und im Benutzerklassenpfad. Argumente, die auf den Klassennamen oder den Namen der JAR-Datei folgen, werden an die Funktion "main" weitergegeben.

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.

## Befehle im Überblick

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 Datei mit der Erweiterung 'jar', 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.

### 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 (.). Siehe auch den Abschnitt Arbeiten mit Klassenpfaden.
- -help oder -?
  - Zeigt einen Benutzungshinweis an.
- -showversion
  - Zeigt die Produktversion an und setzt den Vorgang fort.
- -verbose:[class | gc | dynload | stack | debug | sizes | stackwalk]
  - Aktiviert die ausführliche Ausgabe.
- -version
  - Zeigt die Produktversion an.
- -X
  - Zeigt Hilfe für vom Standard abweichende Optionen an.

### Vom Standard abweichende Optionen

Die unten aufgelisteten Optionen -X weichen vom Standard ab und können jederzeit ohne vorherige Ankündigung geändert werden.

- -Xargencoding
  - Ermöglicht es Ihnen, Unicode-Escapezeichenfolgen in die Argumentenliste zu stellen.
- -Xbootclasspath:<durch Semikolon getrennte Verzeichnisse und ZIP- oder JAR-Dateien>
  - Definiert den Suchpfad für Bootklassen und -ressourcen.
- -Xbootclasspath/a:<durch Semikolon getrennte Verzeichnisse und ZIP- oder JAR-Dateien>
  - Fügt die angegebenen Verzeichnisse, ZIP- oder JAR-Dateien am Ende des Bootklassenpfads hinzu.
- -Xbootclasspath/p:<durch Semikolon getrennte Verzeichnisse und ZIP- oder JAR-Dateien>
  - Stellt die angegebenen Verzeichnisse, ZIP- oder JAR-Dateien vor den Bootklassenpfad. Implementieren Sie keine Anwendungen, bei denen mit der Option -Xbootclasspath: oder -Xbootclasspath/p: eine Klasse in den Dateien core.jar, graphics.jar, server.jar, security.jar, xml.jar, tools.jar oder charsets.jar überschrieben wird, da eine solche Implementierung gegen die Java 2 Runtime Environment-Binärcodelizenz verstößt.
- -Xcheck:jni
  - Führt zusätzliche Prüfungen für JNI-Funktionen aus. Sie können auch -Xrunjnichk verwenden.
- -Xcheck:nabounds
  - Führt zusätzliche Prüfungen für JNI-Bereichsoperationen aus. Sie können auch -Xrunjnichk verwenden.
- -Xcompactexplicitgc
  - Komprimierung bei jedem Aufruf von `System.gc()`. Siehe auch -Xnocompactexplicitgc.
- -Xcompactgc
  - Komprimierung bei jedem Garbage-Collector-Zyklus. Siehe auch -Xnocompactgc.
- -Xdbg:<Optionen>
  - Lädt Debugbibliotheken, damit das ferne Debugging von Anwendungen unterstützt wird. Diese Option ist identisch mit -Xrunjdwp.
- -Xdbginfo:<Symboldateipfad>
  - Lädt Optionen und übergibt sie an den Debuginformationsserver.
- -Xdisablejavadump
  - Verursacht beim Auftreten von Fehlern die Generierung von Systemspeicherauszügen an Stelle von Java-Speicherauszügen.
- -Xdebug
  - Startet die JVM mit aktiviertem Debugger.
- -Xdisableexplicitgc
  - Ändert Aufrufe von `System.gc()` in `no-op`.
- -Xfuture
  - Aktiviert strenge Überprüfungen des Klassendateiformats. Verwenden Sie diese Markierung, wenn Sie neuen Code entwickeln, da strengere Überprüfungen in zukünftigen Releases des Startprogramms für Java-Anwendungen standardmäßig erfolgen.
- -Xgc:<Optionen>
  - Übergibt Optionen, wie verbose, compact, nocompact usw., an den Garbage-Collector.
- -Xgcpolicy:[:optthruput]|[:optavgpause]
  - 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.
- -Xgcthreads<Anzahl Threads>
  - Legt die Anzahl Threads fest, die eine Garbage-Collection ausführen müssen.
- -Xinitsh<Größe>
  - Definiert die Anfangsgröße des Speichers, der Systemklassen enthalten soll.
- -Xint
  - Veranlasst die JVM, nur den Interpreter zu verwenden, wodurch der JIT- und der AOT-Compiler inaktiviert werden.
- -Xiss
  - Definiert die Anfangsgröße des Java-Thread-Stacks.
- -Xjit[:<Anzahl Threads>]
  - Aktiviert den JIT-Compiler und/oder übergibt Optionen an ihn. Siehe auch -Xnojit.
- -Xlinenumbers
  - Aktiviert die Zeilennummern für das Debug. Siehe auch -Xnolinenumbers.
- -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.
- -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 die 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 ist 0.6.
- -Xmca<Größe>
  - Legt fest, dass das RAM-Klassensegment um die angegebene Größe erhöht wird.
- -Xmco<Größe>
  - Legt fest, dass das ROM-Klassensegment um die angegebene Größe erhöht wird.
- -Xmine<Größe>
  - Definiert die Mindestgröße, um die 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.
- -Xminf<Größe>
  - Definiert den Mindestprozentsatz des Freispeichers, der nach einer Garbage-Collection frei sein sollte. Wenn der freie Speicherbereich diesen Wert unterschreitet, versucht die JVM, den Freispeicher zu erweitern. Geben Sie die Größe als Dezimalwert im Bereich von 0-1 an. Z. B. fordert der Wert `-Xminf0.3` an, dass der freie Speicherbereich mindesten 30 % des Freispeichers beträgt.
- -Xmjit[:<Anzahl Threads>]
  - Aktiviert MicroJIT und/oder übergibt Optionen an diesen Compiler.
- -Xmn<Größe>
  - Setzt die Größe des neuen Freispeichers auf die angegebene Größe.
- -Xmo<Größe>
  - Definiert die Anfangsgröße des Java-Freispeichers. Sie können auch -Xms verwenden.
- -Xmoi<Größe>
  - Erhöht die Anfangsgröße des Java-Freispeichers.
- -Xmr<Größe>
  - Definiert die gespeicherte Größe.
- -Xms<Größe>
  - Definiert die Anfangsgröße des Java-Freispeichers. Sie können auch -Xmo verwenden.
- -Xmso<Größe>
  - Definiert die Größe des BS-Thread-Stacks.
- -Xmx<Größe>
  - Definiert die Maximalgröße des Java-Freispeichers.
- -Xnm
  - Definiert die Größe des Überwachungspools.
- -Xnoagent
  - Inaktiviert die Schnittstelle old sun.tools.debug, damit Sie die JPDA-Debugunterstützung verwenden können.
- -Xnoaot
  - Inaktiviert AOT-Compiler.
- -Xnoclassgc
  - Inaktiviert Garbage-Collection für Klassen. Dadurch wird die Garbage-Collection von Speicher inaktiviert, der Java-Klassen zugeordnet ist, die nicht mehr von der JVM verwendet werden.
- -Xnocompactgc
  - Inaktiviert die Komprimierung für den Garbage-Collector. Siehe auch -Xcompactgc.
- -Xnocompactexplicitgc
  - Inaktiviert die Komprimierung bei einem Aufruf von `System.gc()`. Siehe auch -Xcompactexplicitgc.
- -Xnojit
  - Inaktiviert den JIT-Compiler. Siehe auch -xjit.
- -Xnolinenumbers
  - Inaktiviert die Zeilennummern für das Debug. Siehe auch -Xlinenumbers.
- -Xnopartialcompactgc
  - Inaktiviert die inkrementelle Komprimierung bei einem Aufruf von `System.gc()`. Siehe auch -Xpartialcompactgc.
- -Xnosigcatch
  - Inaktiviert den JVM-Wiederherstellungscode. Siehe auch -Xsigcatch.
- -Xnosigchain
  - Inaktiviert das Verketten von Signalroutinen. Siehe auch -Xsigchain.
- -Xoptionsfile=<Datei>
  - Definiert eine Datei mit JVM-Optionen und -definitionen.
- -Xoss<Größe>
  - Definiert die Maximalgröße für den Java-Stack für einen beliebigen Thread.
- -Xpartialcompactgc
  - Aktiviert die inkrementelle Komprimierung bei einem Aufruf von `System.gc()`. Siehe auch -Xnopartialcompactgc.
- -Xquickstart
  - Verbessert die Systemstartzeit durch die Verzögerung der Kompilierung.
- -Xrdbginfo:<Host>:<Port>
  - Lädt Optionen und übergibt sie an den fernen Debuginformationsserver.
- -Xrs
  - Reduziert die Verwendung von Betriebssystemsignalen.
- -XrunBibliothekname[: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.
    - -Xrunjdwp[:help] | [:<Option>=<Wert>, ...]
      - Lädt Debugbibliotheken, damit das ferne Debug von Anwendungen unterstützt wird. Diese Option ist identisch mit -Xdbg.
    - -Xrunjnichk[ :verbose | trace | profile | nonfatal | nowarn | noadvice | pedantic | help]
      - Führt zusätzliche Prüfungen für JNI-Funktionen aus.
- -Xsigcatch
  - Aktiviert den JVM-Wiederherstellungscode. Siehe auch -Xnosigcatch.
- -Xsigchain
  - Aktiviert das Verketten von Signalroutinen. Siehe auch -Xnosigchain.
- -XsigquitToFile<Dateipfad><Dateiname>
  - Erstellt einen Speicherauszug der Informationen aus dem sigquit-Trace in der angegebenen Datei.
- -Xss<Größe>
  - Definiert die Maximalgröße für den nativen Stack für einen beliebigen Thread. Weitere Informationen finden Sie im Abschnitt Arbeiten mit 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.
- -Xverify
  - Aktiviert strenge Klassenüberprüfung aller geladenen Klassen.
- -Xverify:none
  - Inaktiviert strenge Klassenüberprüfung.

## Globalisierung des Befehls 'java'

Mit dem Befehl java und mit anderen Java-Startbefehlen (wie beispielsweise javaw) kann ein Klassenname mit beliebigen Unicode-Zeichen angegeben werden, die im Zeichensatz der aktuellen Ländereinstellung enthalten sind.

Sie können außerdem beliebige Unicode-Zeichen im Klassennamen und in den Argumenten angeben, indem Sie Java-Escapezeichen verwenden. 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 alternativ angeben möchten, dass der Klassenname und die Befehlsargumente im UTF8- oder ISO8859_1-Code verschlüsselt sind, verwenden Sie für UTF8 -Xargencoding:utf8 und für ISO8859_1 -Xargencoding:latin.

Die Befehle java und javaw geben übersetzte Ausgabenachrichten aus. Diese Nachrichten sind abhängig von der Ländereinstellung unterschiedlich, unter der Java ausgeführt wird. Die detaillierte Fehlerbeschreibung und andere von java zurückgegebene Fehlerinformationen werden in Englisch angezeigt.

## Arbeiten mit Klassenpfaden

Sie können einen Klassennamen als vollständigen Dateinamen mit einem vollständigen Pfad und der Erweiterung .class angeben. In früheren Versionen konnten Sie die Klasse nur in Relation zu CLASSPATH angeben. Die Erweiterung .class war nicht zulässig. Durch Angabe des vollständigen Dateinamens können Sie eine Java-Anwendung über den Desktop oder über ein Dateistartprogramm starten. Wenn Sie eine Datei mit der Erweiterung .class mit Pfad und Erweiterung angeben, wird der angegebene Pfad in CLASSPATH eingefügt. Beispielsweise entspricht der Befehl `java ~/myapp/thisapp.class` der Angabe `java -classpath ~/myapp thisapp`.

## Angeben der Garbage-Collection-Richtlinie

Die JVM-Laufzeitoption -Xgcpolicy gibt die Garbage-Collection-Richtlinie an.

-Xgcpolicy nimmt die Werte optthruput (Standardwert), optavgpause oder gencon an. Die Option steuert das Verhalten der Garbage-Collection, so dass zwischen dem Durchsatz der Anwendung und des Gesamtsystems und den durch die Garbage-Collection verursachten Pausezeiten abgewogen werden kann.

Das Format der Option und der zugehörigen Werte lautet wie folgt:

> -Xgcpolicy:optthruput

> -Xgcpolicy:optavgpause

> -Xgcpolicy:gencon

### Pausezeit

Wenn eine Anwendung wegen des verfügbaren Freispeichers nicht sofort ein Objekt erstellen kann, ist die Garbage-Collection 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 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

Die JVM verwendet zur Verringerung der Pausezeit zwei Verfahren:

- 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 Projekte 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 wenn 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 die JVM wird beendet, es sei denn, die Ausnahmebedingung wird abgefangen und bearbeitet. Zu diesem Zeitpunkt erstellt die JVM die Diagnosedatei "javadump". In diesen Situationen sollten Sie entweder die Freispeichergröße mit der Option -Xmx erhöhen oder die Anzahl der verwendeten Anwendungsobjekte verringern.

# Signalverarbeitung durch die JVM

Wenn ein für die 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 die 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 die JVM die Verarbeitung abgeschlossen hat.

Wurde das Signal für einen Nicht-Java-Thread aufgerufen und wurde zuvor mit der Anwendung, mit der die JVM installiert wurde, eine eigene Routine für das Signal installiert, übernimmt diese Signalroutine die Steuerung. Wenn das Signal jedoch von der JVM oder der Java-Anwendung angefordert wird, wird esignoriert, oder die Standardaktion wird ausgeführt.

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

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

Information 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 die JVM ebenfalls eine Sequenz für einen kontrollierten Systemabschluss, der jedoch in diesem Fall wie eine normale Beendigung behandelt wird. Hierbei führt die JVM die folgenden Aktionen aus:

- Aufruf der Signalroutine Ihrer Anwendung für dieses Signal
- Ausführen aller Hooks für das Beenden der Anwendung
- Aufruf 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 der JVM verwendete Signale werden für die interne Steuerung verwendet und führen nicht zur Beendigung der JVM. Das einzige wichtige Steuerungssignal ist SIGQUIT, durch das ein Java-Speicherauszug generiert wird.

## Von der JVM verwendete Signale

In Tabelle 1 sind die von der 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: Die JVM setzt ein Signal SIGABRT ab, wenn sie 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 der JVM zu Steuerungszwecken verwendet werden.

Tabelle 1. Von der JVM verwendete Signale
Signalname | Signaltyp | Beschreibung | Inaktiviert durch -Xrs
--- | --- | --- | ---
SIGBUS | Ausnahmebedingung | Falscher Zugriff auf den Speicher (falsche Datenanordnung) | Nein
SIGSEGV | Ausnahmebedingung | Falscher Zugriff auf den Speicher (es wurden Daten in einen Speicherbereich geschrieben, auf den nicht zugegriffen werden kann). | Nein
SIGILL | Ausnahmebedingung | Nicht zulässige Anweisung (es wurde versucht, eine unbekannte Maschineninstruktion aufzurufen). | Nein
SIGFPE | Ausnahmebedingung | Ausnahmebedingung bei der Gleitkommaverarbeitung (Division durch Null). | Nein
SIGABRT | Fehler | Abnormale Beendigung. Die JVM setzt dieses Signal ab, sobald sie einen JVM-Fehler feststellt. | Nein
SIGINT | Interrupt | Interaktiver Abruf (Strg-C). Die JVM wird normal beendet. | Ja
SIGTERM | Interrupt | Beendigungsanforderung. Die JVM wird normal beendet. | Ja
SIGHUP | Interrupt | Auflegen. Die JVM wird normal beendet. | Ja
SIGQUIT | Steuerzeichen | Ein Beendigungssignal für ein Terminal. Die JVM verwendet dieses Signal zum Erstellen von Java-Speicherauszügen. | Nein
SIGPIPE | Steuerzeichen | Unterbrochene Pipe. Auf SIG_IGN setzen. | Nein

Mit Hilfe der Option -Xrs (Reduzierung der Verwendung von Signalen) können Sie verhindern, dass die 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.

Auf Grund der Signale `1 (SIGHUP)`, `2 (SIGINT)`, `4 (SIGILL)`, `7 (SIGBUS)`, `8 (SIGFPE)`, `11 (SIGSEGV)` und `15 (SIGTERM)` für JVM-Threads wird die JVM beendet. Daher sollte eine Anwendungssignalroutine bei diesen Signalen keine Wiederherstellung versuchen, es sei denn, die Services der JVM werden nicht mehr benötigt.

## Verbinden eines nativen Codetreibers mit der Signalverkettungsbibliothek

Runtime Environment enthält eine Signalverkettungsfunktion. Die Signalverkettung ermöglicht eine effizientere Interaktion der JVM mit nativem Code, über den eigene Signalroutinen installiert werden.

Mit der Signalverkettungsfunktion kann eine Anwendung mit der gemeinsam benutzten 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 die JVM installierten Signalroutinen hinzugefügt. Wenn diese Signale zu einem späteren Zeit gesendet werden und nicht an die 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 eine 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, das `JAVA_HOME` installiert ist. Verwenden Sie andernfalls /opt/IBMJava2-142/jre.)

Wenn Sie Signalroutinen installieren, die `sigaction()` verwenden, werden einige sa_flags nicht überwacht, wenn die 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 der JVM ausgeführt werden, keinen Verweis mehr auf die JVM-Signalroutine sondern auf eine beliebige vor dem Starten der JVM installierte Routine zurück.

# Implementieren des Steuerroutinenpools für Verbindungen für RMI

Thread-Pooling für Steuerroutinen von RMI-Verbindungen wird nicht standardmäßig aktiviert.

Wenn Sie das Verbindungs-Pooling 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.

# Abrufen der IBM Build- und Versionsnummer

Geben Sie den folgenden Befehl an einer Shell-Eingabeaufforderung ein, um die IBM Buildnummer und die Versionsnummer abzurufen:

`java -version`

# Verwenden der Funktion 'floating stacks'

Auf einem Linux-System ohne aktivierter 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.

# Ändern der Eingabemethode in DBCS-Sprachen

Wenn Sie die Eingabemethode ändern möchten, sollten Sie auf DBCS-Systemen (Double-Byte Character Set, Doppelbytezeichensatz) die Klasse java.util.prefs.Preferences und nicht die Umgebungsvariablen IBMJAVA_INPUTMETHOD_SWITCHKEY und IBMJAVA_INPUTMETHOD_SWITCHKEY_MODIFIERS verwenden. Weitere Informationen hierzu finden Sie im Handbuch Input Method Framework Specification von Sun.

# Installieren Ihrer Anwendung auf dem System eines Benutzers

Wenn Sie das Produkt entwickelt haben und für die Auslieferung bereit sind, müssen Sie das Produkt auf dem System eines Benutzers installieren, das System des Benutzers zur Unterstützung Ihrer Software sowie die Laufzeitumgebung konfigurieren.

Wenn Sie Runtime Environment for Linux verwenden, müssen Sie sicherstellen, dass Ihr Installationsverfahren keine vorhandene Installation überschreibt (es sei denn, die vorhandene Version von Runtime Environment for Linux ist eine ältere Version).

Zum erneuten Verteilen von Runtime Environment for Linux können Sie es auf Ihrem eigenen System installieren und anschließend die erforderlichen Runtime Environment-Dateien in Ihr Installationspaket kopieren. Wenn Sie diese Methode wählen, müssen Sie alle mit Runtime Environment for Linux zur Verfügung gestellten Dateien berücksichtigen. Die Software von Runtime Environment for Linux kann nur erneut verteilt werden, wenn alle Dateien enthalten sind. Wenn Sie die Anwendung verteilt haben, hat sie dadurch eine eigene Kopie von Runtime Environment for Linux.

Weitere Informationen zu den Dateien, die erneut verteilt werden müssen, finden Sie in der Lizenzvereinbarung, die im Lieferumfang dieses Produkts enthalten ist.

# Bekannte Einschränkungen

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

##

- 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.
- SDK implementiert Java-Threads als native Threads, wodurch jeder Thread zu einem separaten Linux-Prozess wird. Wenn die Anzahl der Java-Threads die maximal zulässige Anzahl an Prozessen überschreitet, empfängt Ihr Programm möglicherweise eine Fehlernachricht, einen SIGSEGV-Fehler, oder Ihr System blockiert 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 Änderungen 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 Ctrl-C beendet haben, bleiben einige Prozesse möglicherweise verwaist.
- Die vollständige Anzeige von Dialogfenstern, die mit Swing erstellt wurden, kann sich um einige Sekunden verzögern.
- 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 Linux-System mit X Window 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.
- Ein Aufruf von JNI_CreateJavaVM() durch eine JNI-Anwendung verursacht möglicherweise einen Segmentierungsfehler (Signal SIGSEGV). Erstellen Sie Ihr JNI-Programm erneut unter Angabe der Option -lpthread, um diesen Fehler zu vermeiden.
- (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.
     - 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 Kernel-Speicher bietet entweder nicht genügend Kapazität oder ist fragmentiert. Im Verzeichnis /var/log/messages finden Sie entsprechenden Kernel-Nachrichten, 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 awt/swing-Java-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".
- 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 Redhat Enterprise Linux 3.0 werden chinesische Zeichen möglicherweise nicht in AWT-Textkomponenten angezeigt, mit Ausnahme von GB2312-Zeichen in der chinesischen Ländereinstellung GB18030.

# 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 US-amerikanischen 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 Dienstleistungen von IBM verwendet werden können. Anstelle der IBM Produkte, Programme oder Dienstleistungen können auch andere ihnen äquivalente Produkte, Programme oder Dienstleistungen verwendet werden, solange diese keine gewerblichen 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. IBM kann jederzeit ohne Vorankündigung Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.

Verweise in dieser Veröffentlichung 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 Garantie, 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. Diese Daten stellen deshalb keine Leistungsgarantie dar.

Informationen über Produkte anderer Hersteller als IBM wurden von den Herstellern dieser Produkte zur Verfügung gestellt, bzw. aus von ihnen veröffentlichten Ankündigungen oder anderen öffentlich zugänglichen Quellen entnommen. IBM hat diese Produkte nicht getestet und übernimmt im Hinblick auf Produkte anderer Hersteller keine Verantwortung für einwandfreie Funktion, Kompatibilität oder andere Ansprüche. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.

## Marken

IBM ist in gewissen Ländern eine Marke der International Business Machines Corporation.

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

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 enthält Software, die von der Apache Software Foundation (http://www.apache.org/) entwickelt wurde.