IBM SDK for Linux platforms, Java Technology Edition, Version 6

SDK und Runtime



Copyright International Business Machines Corporation 2003, 2007. Alle Rechte vorbehalten.

Inhaltsverzeichnis

Vorwort
Übersicht
Konventionen
Versionskompatibilität
Migrieren von weiteren IBM JVMs
Unterstützte Hardware für System z
Inhalt von SDK und Runtime Environment
Runtime Environment-Klassen und -Tools
SDK-Tools und -Referenzinformationen
Installieren und Konfigurieren von SDK und Runtime Environment
Ausführen eines Upgrades für SDK
Installieren unter Red Hat Enterprise Linux (RHEL) 4
Installieren unter Red Hat Enterprise Linux (RHEL) 5
Ausführen von Java mit SELinux unter RHEL 5
Installieren eines 32-Bit-SDK auf einer 64-Bit-Architektur
Installieren aus einer RPM-Datei
Installieren aus einer .tgz-Datei
Verwenden eines JPackage-kompatiblen Formats
Konfigurieren von SDK und Runtime Environment für Linux
Festlegen des Pfads
Festlegen des Klassenpfades
Deinstallieren von SDK und Runtime Environment for Linux
Deinstallieren des RPM-Pakets (Red Hat Package Manager)
Deinstallieren des komprimierten TAR-Pakets (Tape Archive)
Ausführen von Java-Anwendungen
Die Befehle java und javaw
Erhalten von Versionsinformationen
Angeben von Java-Optionen und Systemmerkmalen
Standardoptionen
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
Unterstützung des Euro-Symbols
Schriftartkonfigurationsdateien zur Zurücksetzung
| |
Verwenden von Eingabemethoden für Indisch und Thailändisch
Verwenden von SDK zur Entwicklung von Java-Anwendungen
| |
Verwenden von XML
| |
Migrieren auf den XL-TXE-J-Compiler
| |
XML-Referenzinformationen
Debugging in Java-Anwendungen
Java-Debugger (JDB)
Ermitteln, ob eine Anwendung auf JVM im 32-Bit- oder 64-Bit-Modus ausgeführt wird
Signalverarbeitung durch JVM
Von JVM verwendete Signale
Verbinden eines nativen Codetreibers mit der Signalverkettungsbibliothek
Schreiben von JNI-Anwendungen
Unterstützung für die Wiederherstellung von blockierten Verbindungen auf Threadebene
Konfigurieren einer Speicherzuordnung von großen Seiten
CORBA-Unterstützung
Systemmerkmale für die ORB-Tracefunktion
Systemmerkmale zur Optimierung des ORB
Java-Sicherheitsberechtigungen für den ORB
ORB-Implementierungsklassen
RMI-IIOP
Implementieren des Steuerroutinenpools für RMI-Verbindungen
Funktionale Erweiterungen für BigDecimal
Plug-in, Applet Viewer und Web Start
(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
Arbeiten mit Applets
Ausführen von Applets mit Applet Viewer
Debugging von Applets mit Applet Viewer
(Nur Linux IA 32 Bit, PPC32 und PPC64) Verwenden von Web Start
Ausführen von Java Web Start
(Nur Linux IA 32 Bit) Sichere statische Versionssteuerung für WebStart
Ausliefern von Java-Anwendungen
Gemeinsame Nutzung von Klassendaten auf verschiedenen JVMs
Übersicht über die gemeinsame Nutzung von Klassendaten
Aktivieren und Konfigurieren der gemeinsamen Nutzung von Klassendaten
Erstellen, Belegen, Überwachen und Löschen eines Caches
Leistung und Speicherbelegung
Besondere Aspekte und Einschränkungen bei der gemeinsamen Nutzung von Klassendaten
Grenzwerte für die Cachegröße
Änderungen bei Laufzeitbytecodes
Betriebssystemeinschränkungen
Verwenden von 'SharedClassPermissions'
Anpassen benutzerdefinierter Klassenladeprogramme an gemeinsam genutzte Klassen
Verwenden der Java Communications API (JavaComm)
Installieren der Java Communications API aus einer komprimierten Datei
Installieren der Java Communications API über eine RPM-Datei
Speicherposition der Java Communications API-Dateien
Konfigurieren der Java Communications API
Ändern des Zugriffsmodus für den seriellen Anschluss und den Parallelanschluss
Angeben von Einheiten in der Datei javax.comm.properties
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
Service und Unterstützung für unabhängige Softwareanbieter
Eingabehilfen
Verschieben des Eingabefokus von JComboBox-Komponenten in Swing per Tastatur
Web Start-Eingabehilfen (nur Linux IA 32 Bit, PPC32 und PPC64)
Kommentare zu diesem Handbuch
Anhang A. Vom Standard abweichende Optionen
Anhang B. Bekannte Einschränkungen
Bemerkungen
Marken

Vorwort

In diesem Benutzerhandbuch erhalten Sie allgemeine Informationen zu IBM SDK and Runtime Environment for Linux platforms, Java Technology Edition, Version 6 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

(Nur Intel-32-Bit-Plattformen) Diese virtualisierten Umgebungen werden unterstützt:

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

Dieses Handbuch ist Teil eines Releases und ist nur auf dieses bestimmte Release anwendbar. Stellen Sie sicher, dass Sie das für das Release entsprechende Handbuch verwenden.

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

|Technische Änderungen, die für diese Version des Benutzerhandbuchs vorgenommen wurden, sind mit Ausnahme von unwichtigen oder offensichtlichen Änderungen mit blauen Winkeln gekennzeichnet, wenn sie in einem Information Center angezeigt werden, oder rot mit vertikalen Balken links neben den Änderungen, wenn sie als HTML-Datei angezeigt oder als Farbkopie ausgedruckt werden. Werden sie im PDF-Format angezeigt, wird mit vertikalen Balken am linken Rand auf die Änderungen hingewiesen.

Der Programmcode wurde nicht für die Verwendung in Echtzeitanwendungen wie z. B. den folgenden entworfen und ist nicht für diese bestimmt: Onlinesteuerung von Flugzeugen, Flugverkehr, Flugzeugnavigation oder Kommunikation im Flugverkehr sowie Entwurf, Konstruktion, Betrieb oder Instandhaltung von nuklearen Einrichtungen (Liste kann erweitert werden).

Übersicht

Bei IBM SDK handelt es sich um eine Entwicklungsumgebung zum Schreiben und Ausführen von Applets und Anwendungen, die der Java 6 Core-API (Application Programming Interface - Anwendungsprogrammierschnittstelle) entsprechen.

Das SDK umfasst Runtime Environment for Linux. Mit dieser Komponente können Sie nur Java-Anwendungen ausführen. Wenn Sie das 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 im SDK enthalten sind. Mit dieser Komponente können Sie ein Java-Programm während der Laufzeit verwenden; Sie haben jedoch nicht die Möglichkeit, Java-Programme zu 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/PPC64 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 die Runtime Environment for Linux-Software, wobei xx eine Abkürzung für die Sprache darstellt. Öffnen Sie diese Datei in einem Web-Browser, um die Lizenzvereinbarung anzuzeigen oder zu drucken.

Konventionen

In diesem Handbuch lautet das Standardinstallationsverzeichnis des SDK /opt/ibm/java-i386-60/. Wenn Sie nicht Linux IA 32 Bit verwenden, ist das Standardinstallationsverzeichnis ein anderes.

Die hier aufgeführten Plattformen haben verschiedene Standardinstallationsverzeichnisse. Verwenden Sie das für Ihre Plattform entsprechende Verzeichnis, wenn /opt/ibm/java-i386-60/ angezeigt wird:

In den Beispielen in diesem Benutzerhandbuch werden Korn-Shellbefehle verwendet.

Versionskompatibilität

Normalerweise müssten alle Applets oder Anwendungen, die mit einer Vorversion von SDK ausgeführt wurden, zusammen mit IBM SDK for Linux Version 6 ordnungsgemäß ausgeführt werden. Für Klassen, die auf der Grundlage dieses Releases kompiliert wurden, kann nicht garantiert werden, dass sie zusammen mit früheren Releases eingesetzt werden können.

Weitere Informationen zu Kompatibilitätsproblemen zwischen Releases finden Sie auf den folgenden Sun-Websites unter:

|http://java.sun.com/javase/6/webnotes/compatibility.html

http://java.sun.com/j2se/5.0/compatibility.html

http://java.sun.com/j2se/1.4/compatibility.html

http://java.sun.com/j2se/1.3/compatibility.html

Wenn Sie das SDK als Teil eines anderen Produkts verwenden (z. B. von IBM WebSphere Application Server) und von einer früheren Version des SDK aus ein Upgrade durchführen, z. B. von Version 5.0, sind serialisierte Klassen möglicherweise nicht kompatibel. Klassen verschiedener Serviceaktualisierungen sind jedoch miteinander kompatibel.

Migrieren von weiteren IBM JVMs

Ab Version 5.0 enthält IBM Runtime Environment for Linux neue Versionen von IBM Virtual Machine for Java und des JIT-Compilers (JIT - Just-in-Time).

Wenn Sie von einer älteren IBM Runtime Environment-Version migrieren, beachten Sie Folgendes:

Unterstützte Hardware für System z

Die 31-Bit- und 64-Bit-SDKs und Runtime Environments von System z werden auf System z9- und zSeries-Hardware ausgeführt.

Die SDKs und Runtime Environments werden auf den folgenden Servern oder funktional entsprechenden Servern ausgeführt:

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, dürfen 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önnte zu Fehlern bei der Portierbarkeit von Anwendungen führen.

SDK for Linux enthält lediglich die Benutzerhandbücher, die Javadoc-Komponente und die zugehörigen Lizenzdateien, die zugehörigen Copyrightdateien, das Javadoc-Verzeichnis und 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.

Runtime Environment-Klassen und -Tools

Eine Liste von Klassen und Tools, die Sie mit der Standardversion von Runtime Environment verwenden können.

SDK-Tools und -Referenzinformationen

Eine Liste von Tools und Referenzinformationen, die zum Lieferumfang der Standardversion des SDK gehört.

Die folgenden Tools sind Teil des SDK und befinden sich im Verzeichnis /opt/ibm/java-i386-60/bin:
appletviewer (Java Applet Viewer)
Testet und führt Applets außerhalb eines Web-Browsers aus.
apt (Tool zur Verarbeitung von Annotationen)
Sucht und führt Annotationsprozessoren aus, basierend auf den Annotationen, die in der Gruppe der angegebenen, zu untersuchenden Quellendateien vorhanden sind.
extcheck (Extcheck-Dienstprogramm)
Stellt Versionskonflikte zwischen einer JAR-Zieldatei und neu installierten JAR-Erweiterungsdateien fest.
(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.
idlj (IDL für Java-Compiler)
Generiert Java-Bindungen über eine festgelegte IDL-Datei.
ikeycmd (iKeyman-Befehlszeilendienstprogramm)
Ermöglicht das Verwalten von Schlüsseln, Zertifikaten und Zertifikatsanforderungen über die Befehlszeile. Weitere Informationen finden Sie im zugehörigen Handbuch Security Guide und unter http://www.ibm.com/developerworks/java/jdk/security.
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.
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.
javac (Java-Compiler)
Kompiliert Programme, die in der Programmiersprache Java in Bytecodes (kompilierter Java-Code) geschrieben werden.
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.
javap (Disassembler für Klassendateien)
Zerlegt kompilierte Dateien und kann eine Darstellung der Bytecodes drucken.
javaw (Java-Interpreter)
Führt Java-Klassen genauso aus wie der Befehl java, verwendet jedoch kein Konsolfenster.
(Nur Linux IA 32 Bit, PPC32 und PPC64) javaws (Java Web Start)
Ermöglicht die Implementierung und automatische Verwaltung von Java-Anwendungen. Weitere Informationen finden Sie unter Ausführen von Java Web Start.
jconsole (JConsole - Überwachungs- und Verwaltungstool)
Überwacht lokale und ferne JVMs mit Hilfe einer grafischen Benutzerschnittstelle. JMX-kompatibel.
jdb (Java-Debugger)
Hilft beim Debugging Ihres Java-Programms.
jdmpview (plattformunabhängiges Formatierprogramm für Speicherauszüge)
Analysiert Speicherauszüge. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
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).
schemagen
Erstellt eine Schemadatei für jeden Namensbereich, der in Ihren Java-Klassen angegeben ist.
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.
wsgen
Generiert portierbare JAX-WS-Artefakte, die in JAX-WS-Web-Services verwendet werden.
wsimport
Generiert portierbare JAX-WS-Artefakte aus einer WSDL-Datei.
xjc
Kompiliert XML-Schemadateien.
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. |Ab Version 6 ist die RMI-IIOP-Demo nicht mehr im SDK enthalten.
Copyright
Der Copyrightvermerk für die SDK for Linux-Software.
Lizenz

Die Lizenzdatei /opt/ibm/java-i386-60/docs/content/<Ländereinstellung>/LA_<Ländereinstellung> enthält die Lizenzvereinbarung für die SDK for Linux-Software (wobei <Ländereinstellung> die Bezeichnung Ihrer Ländereinstellung ist, wie z. B. de). Öffnen Sie diese Datei in einem Web-Browser, um die Lizenzvereinbarung anzuzeigen oder zu drucken.

Installieren und Konfigurieren von SDK und Runtime Environment

Sie können IBM Java SDK und Runtime Environment entweder aus einer RPM- oder .tgz-Datei installieren. Sofern Sie nicht allen Benutzern des Systems den Zugriff auf diese Java-Installation erlauben wollen, führen Sie die Installation anhand der .tgz-Datei durch. Wenn Sie nicht über Rootberechtigung 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/java-i386-60/ installiert. Bei den Beispielen in diesem Handbuch wird vorausgesetzt, dass Sie Java in diesem Verzeichnis installiert haben.

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 das Upgrade starten.

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.

Installieren unter Red Hat Enterprise Linux (RHEL) 4

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

Bei RHEL 4 sind diese Bibliotheken in folgenden RPM-Dateien enthalten:

Gehen Sie wie folgt vor, um diese Bibliotheken bei der Installation von RHEL 4 einzuschließen:

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

Installieren unter Red Hat Enterprise Linux (RHEL) 5

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

Bei RHEL 5 sind diese Bibliotheken in folgenden RPM-Dateien enthalten:

Gehen Sie wie folgt vor, um diese Bibliotheken bei der Installation von RHEL 5 einzuschließen:

  1. Wählen Sie Customize now in der Softwareauswahlanzeige aus.
  2. Wählen Sie in der nächsten Anzeige im linken Fenster Base System aus. Wählen Sie im rechten Fenster Legacy Software Support aus. Mit diesen Optionen werden die compat-libstdc++-Pakete installiert.
  3. Das Paket 'libXp' ist erforderlich, kann aber in der grafischen Benutzerschnittstelle nicht zur Installation ausgewählt werden. Wenn die Installation beendet ist, öffnen Sie eine Shell, suchen das Paket 'libXp' auf den Red Hat-Installationsmedien und installieren es. Beispiel: Geben Sie für die Installation auf einer 32-Bit-Intel-Plattform folgenden Befehl ein: rpm -i /media/cdrom/Server/libXp-1.0.0-8.i386.rpm.

Ausführen von Java mit SELinux unter RHEL 5

Zum Ausführen von IBM SDK for Java unter Red Hat Enterprise Linux Version 5 mit aktiviertem SELinux muss Java im Standardverzeichnis installiert werden, oder es muss ein Befehl eingegeben werden.

Wenn Java nicht im Standardverzeichnis installiert wurde, geben Sie folgenden Befehl ein:

chcon -R -t texrel_shlib_t <Pfad des SDK>

Dabei gilt Folgendes: <Pfad des SDK> ist der Pfad, in dem Java installiert wurde.

Weitere Informationen zu SELinux finden Sie unter Introduction to SELinux in der Red Hat-Dokumentation.

Installieren eines 32-Bit-SDK auf einer 64-Bit-Architektur

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

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

Sie können mit dem Tool RPM überprüfen, welche Versionen der Pakete installiert sind. Fügen Sie dazu die Option --queryformat "%{NAME}.%{ARCH}\n" an den Befehl RPM an. Beispiel:

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

Installieren aus einer RPM-Datei

Eine Prozedur für die Installation aus einer RPM-Datei.

Zum Durchführen eines Upgrade von JVM mit dem Tool 'rpm' müssen Sie die vorherige Version deinstallieren. Möchten Sie zwei Versionen von JVM an unterschiedlichen Speicherpositionen installieren, verwenden Sie die rpm-Option '--force', um den Versionskonflikt zu ignorieren, oder installieren Sie JVM aus der .tgz-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-6.0-0.0.<Architektur>.rpm
    oder
    rpm -ivh ibm-java2-<Architektur>-jre-6.0-0.0.<Architektur>.rpm

    Dabei gilt Folgendes: <Architektur> stellt Ihre Architektur dar: i386, x86_64, ppc, ppc64, s390 oder s390x.

Installieren aus einer .tgz-Datei

Eine Prozedur für die Installation aus einer .tgz-Datei.

  1. Erstellen Sie ein Verzeichnis zum Speichern der Java-Paketdateien. Bei den Beispielen in diesem Handbuch wird eine Installation im Verzeichnis /opt/ibm/java-i386-60/ vorausgesetzt. Ersetzen Sie im restlichen Handbuch /opt/ibm/java-i386-60/ durch das Verzeichnis, in dem Sie Java installiert haben.
  2. Geben Sie an einer Shelleingabeaufforderung tar -zxvf <.tgz-Datei> ein.
    tar -zxvf ibm-java2-sdk-60-linux-<Architektur>.tgz
    oder
    tar -zxvf ibm-java2-jre-60-linux-<Architektur>.tgz

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

  3. Wenn Sie SELinux (Security-Enhanced Linux) ausführen, müssen Sie die gemeinsam genutzten Java-Bibliotheken im System angeben. Geben Sie Folgendes ein:
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/jre
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/bin
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/lib

Verwenden eines JPackage-kompatiblen Formats

Das IBM Java-Paket ist auch in einem JPackage-kompatiblen Format verfügbar.

Zur einfacheren Verwaltung des SDK sind dessen verschiedene Komponenten jetzt auch als separate RPM-Dateien verfügbar: das Java Runtime Environment-Basispaket, Development Kit, Plug-in, JDBC, Demo, Sound, Source und Fonts. Die RPM-Datei 'jpackage-utils' (unter http://jpackage.org für den Download verfügbar), die die Verwaltung mehrerer Java-RPM-Dateien auf einem System ermöglicht, ist auch eine Voraussetzung für die IBM SDKs. Weitere Informationen zur JPackage-Spezifikation finden Sie unter http://jpackage.org.

Konfigurieren von SDK und Runtime Environment für Linux

Inkonsistenzen bei den Schriftartcodierungen unter Red Hat Advanced Server

Anmerkung: (Nur für Benutzer von Linux IA 32 Bit in Chinesisch) Auf Grund der Inkonsistenzen bei den Schriftartcodierungen unter Red Hat Advanced Server ist es bei der Installation für eine Umgebung mit Chinesisch als Standardsprache besser, zunächst Englisch als Standardsprache zu installieren und diese dann nach Abschluss der Installation in Chinesisch zu ändern. Andernfalls werden chinesische Schriftarten möglicherweise nicht angezeigt.

Festlegen des Pfads

Alle vorhandenen Java-Startprogramme in dem von Ihnen verwendeten Pfad werden überschrieben, wenn Sie die Umgebungsvariable PATH ändern.

Mit der Umgebungsvariablen PATH können unter Linux Programme und Dienstprogramme wie z. B. javac, java und javadoc in allen aktuellen Verzeichnissen gesucht werden. Geben Sie zum Anzeigen des aktuellen Werts der Umgebungsvariablen PATH Folgendes an einer Eingabeaufforderung ein:

echo $PATH

Gehen Sie wie folgt vor, um die Java-Startprogramme Ihrem Pfad hinzuzufügen:

  1. Editieren Sie die Shellstartdatei im Ausgangsverzeichnis (in der Regel .bashrc, je nach der von Ihnen verwendeten Shell), und fügen Sie der Umgebungsvariablen PATH die absoluten Pfade hinzu. Beispiel:
    export PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
  2. Melden Sie sich erneut an, oder führen Sie das aktualisierte Shell-Script aus, um die neue Umgebungsvariable PATH zu aktivieren.

Nach dem Festlegen des Pfads können Sie ein Tool ausführen, indem Sie an einer Eingabeaufforderung den Namen des Tools eingeben. Geben Sie beispielsweise zum Kompilieren der Datei MeineDatei.Java Folgendes an einer Eingabeaufforderung ein:

javac MeineDatei.Java

Festlegen des Klassenpfades

Der Klassenpfad teilt den SDK-Tools (z. B. java, javac und javadoc) die Speicherposition der Java-Klassenbibliotheken mit.

Sie müssen den Klassenpfad explizit nur in folgenden Fällen festlegen:

Geben Sie zum Anzeigen des aktuellen Werts der Umgebungsvariable CLASSPATH an einer Shelleingabeaufforderung folgenden Befehl 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, muss jede Anwendung in einem separaten Befehlsfenster in einer separaten Shelleingabeaufforderung ausgeführt werden.

Deinstallieren von SDK und Runtime Environment for Linux

Welchen Prozess Sie zum Entfernen von SDK und Runtime Environment for Linux verwenden, hängt vom verwendeten Installationstyp ab.

Anweisungen finden Sie unter Deinstallieren des RPM-Pakets (Red Hat Package Manager) oder Deinstallieren des komprimierten TAR-Pakets (Tape Archive).

Deinstallieren des RPM-Pakets (Red Hat Package Manager)

Eine Prozedur zum Deinstallieren des RPM-Pakets (Red Hat Package Manager).

Gehen Sie wie folgt vor, um SDK oder Runtime Environment for Linux zu deinstallieren, wenn Sie diese als RPM-Paket installiert haben:

  1. Geben Sie zum Überprüfen der installierten RPM-Pakete folgenden Befehl ein: rpm -qa | grep -i java.

    Anschließend wird eine Liste aller installierten IBM Java-Pakete angezeigt. Beispiel:

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

    Diese Ausgabe gibt an, welche Pakete Sie mit dem Befehl rpm -e deinstallieren können. Beispiel:

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

    Sie können auch ein grafisches Tool verwenden, wie beispielsweise kpackage oder yast2.

  2. Löschen Sie das Verzeichnis, in dem Sie SDK and Runtime Environment installiert haben, aus der Anweisung PATH.
  3. (Nur Linux IA 32 Bit und PPC32) Wenn Sie das Java Plug-in installiert haben, löschen Sie die Dateien für das Java Plug-in aus dem Verzeichnis des Web-Browsers.

Deinstallieren des komprimierten TAR-Pakets (Tape Archive)

Eine Liste der Schritte zum Löschen des aus dem komprimierten Paket extrahierten IBM SDK for Linux Version 6.

  1. Löschen Sie die Dateien für SDK oder Runtime Environment aus dem Verzeichnis, in dem Sie SDK oder Runtime Environment installiert haben.
  2. Löschen 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, löschen Sie die Dateien für das Java Plug-in aus dem Verzeichnis des Web-Browsers.

Ausführen von Java-Anwendungen

Java-Anwendungen können mit Hilfe des Startprogramms java oder durch JNI gestartet werden. Einstellungen werden mit Hilfe von Befehlszeilenargumenten, Umgebungsvariablen und Merkmaldateien an eine Java-Anwendung übergeben.

Die Befehle java und javaw

Eine kurze Übersicht über die Befehle java und javaw.

Zweck

Mit den Tools java und javaw wird durch Starten von Java Runtime Environment und Laden einer angegebenen Klasse eine Java-Anwendung gestartet.

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 Dialogfeld mit Fehlerinformationen an.

Verwendung

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.

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

Parameter

[Optionen]
Befehlszeilenoptionen, die an die Laufzeitumgebung übergeben werden.
<Klasse>
Systemstartklasse. Die Klasse muss eine Methode main() enthalten.
<Datei.jar>
Der Name der JAR-Datei, die aufgerufen werden soll. Sie wird nur mit der Option -jar verwendet. Die benannte JAR-Datei muss Klassen- und Ressourcendateien für die Anwendung enthalten, wobei die Systemstartklasse über den Manifestheader für die Hauptklasse angegeben wird.
[Argumente ...]
Befehlszeilenargumente, die an die Funktion main() der Systemstartklasse übergeben werden sollen.

Erhalten von Versionsinformationen

Die IBM Build- und Versionsnummer für Ihre Java-Installation erhalten Sie mit Hilfe der Option -version. |Sie können auch die Versionsnummer für alle jar-Dateien im Klassenpfad mit Hilfe der Option -Xjarversion abrufen.

  1. Öffnen Sie eine Shelleingabeaufforderung.
  2. Geben Sie den folgenden Befehl ein:
    java -version
    Sie werden Informationen sehen wie etwa:
    Java Version "1.6.0-internal"
    Java(TM) SE Runtime Environment (Build 20070329_01)
    IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20070326_12091 (JIT enabled)
    J9VM - 20070326_12091_lHdSMR
    JIT  - dev_20070326_1800
    GC   - 20070319_AA)
    Die präzisen Datumsangaben für Builds und Versionen ändern sich.

| |

Geben Sie den folgenden Befehl ein, um Versionsinformationen zu allen verfügbaren |jar-Dateien im Klassenpfad, im Klassenpfad des Bootprogramms und im Erweiterungsverzeichnis anzuzeigen:

|
Java -Xjarversion
|

Sie werden Informationen sehen wie etwa:

|
...
|/opt/ibm/java-i386-60/jre/lib/ext/ibmpkcs11impl.jar  VERSION: 1.0 build_20070125
|/opt/ibm/java-i386-60/jre/lib/ext/dtfjview.jar
|/opt/ibm/java-i386-60/jre/lib/ext/xmlencfw.jar  VERSION: 1.00, 20061011  LEVEL: -20061011
|
|...
|

Die für jede JAR-Datei verfügbaren Informationen variieren und sind den |Merkmalen Implementation-Version und Build-Level im Inhaltsverzeichnis der JAR-Datei entnommen.

Angeben von Java-Optionen und Systemmerkmalen

Sie können Java-Optionen und Systemmerkmale in die Befehlszeile eingeben, indem Sie eine Optionsdatei oder eine Umgebungsvariable verwenden.

Diese Methoden zum Angeben von Java-Optionen sind nach der Ausführungspriorität aufgelistet:

  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=<Datei>.
  3. Durch Erstellen einer Umgebungsvariable mit der Bezeichnung IBM_JAVA_OPTIONS, die die Optionen enthält. Beispiel:
    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. Folgendes angeben

java -Xint -Xjit MeineKlasse

hat die Option -Xjit Vorrang.

Standardoptionen

Die Definitionen für die Standardoptionen.

-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.
-cp <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 die Umgebungsvariable CLASSPATH nicht definiert wurde, ist der Benutzerklassenpfad standardmäßig das aktuelle Verzeichnis (.).
-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 die Umgebungsvariable CLASSPATH nicht definiert wurde, ist der Benutzerklassenpfad standardmäßig das aktuelle Verzeichnis (.).
-D<Merkmalname>=<Wert>
Definiert ein Systemmerkmal.
-help oder -?
Zeigt einen Benutzungshinweis an.
-javaagent:<JAR-Pfad>[=<Optionen>]
Lädt einen Agenten der Programmiersprache Java. Weitere Informationen finden Sie in der Dokumentation zur API java.lang.instrument.
-jre-restrict-search
Nimmt private Benutzer-JREs in die Versionssuche auf.
-no-jre-restrict-search
Schließt private Benutzer-JREs von der Versionssuche aus.
-showversion
Zeigt die Produktversion an und setzt den Vorgang fort.
-verbose:<Option>
Aktiviert die ausführliche Ausgabe. Die folgenden Optionen sind verfügbar:
class
Schreibt für jede geladene Klasse einen Eintrag an 'stderr'.
gc
Schreibt Informationen zur ausführlichen Garbage-Collection an 'stderr'. Verwenden Sie -Xverbosegclog, um die Ausgabe zu steuern. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
jni
Schreibt Informationen an 'stderr', die die von der Anwendung und von JVM aufgerufenen JNI-Services beschreiben.
sizes
Schreibt Informationen an 'stderr', die die Einstellungen der aktiven Speicherbelegung beschreiben.
stack
Schreibt Informationen an 'stderr', die die Java- und C-Stack-Belegung für jeden Thread beschreiben.
-version
Zeigt die Produktversion an.
-version:<Wert>
Erfordert, dass die angegebene Version ausgeführt wird, z. B. "1.5".
-X
Zeigt Hilfe für vom Standard abweichende Optionen an.

Globalisierung des Befehls java

Die Startprogramme java und javaw akzeptieren Argumente und Klassennamen mit beliebigen Zeichen, 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 Befehlszeilenoption -Xargencoding verwenden.

-Xargencoding
Verwenden Sie die Argumentverschlüsselung. Verwenden Sie zum Angeben eines Unicode-Zeichens Escapezeichenfolgen im Format \u####. Dabei ist # eine Hexadezimalziffer (0-9, A-F).
-Xargencoding:utf8
Verwenden Sie die UTF8-Verschlüsselung.
-Xargencoding:latin
Verwenden Sie 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, führen Sie den folgenden Befehl aus:

java -Xargencoding '\u0048ello\u0057orld'

Die Befehle java und javaw stellen übersetzte Nachrichten bereit. Diese Nachrichten unterscheiden sich je nach der Ländereinstellung, in der Java ausgeführt wird. Die detaillierte Fehlerbeschreibung und andere von java zurückgegebene Fehlerinformationen 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 V6 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 beide den JIT-Compiler, der standardmäßig in Benutzeranwendungen und in SDK-Tools aktiviert ist. In der Regel rufen Sie den JIT-Compiler nicht explizit auf. Die Kompilierung des Java-Bytecodes in Maschinencode erfolgt transparent. Sie können den JIT-Compiler inaktivieren, um ein Problem besser eingrenzen zu können. Wenn ein Problem beim Ausführen einer Java-Anwendung oder eines Java-Applets auftritt, können Sie den JIT-Compiler inaktivieren, um es besser eingrenzen zu können. Die Inaktivierung des JIT-Compilers ist nur eine vorübergehende Maßnahme. Der JIT-Compiler ist für die Optimierung der Leistung erforderlich.

Weitere Informationen zum JIT-Compiler finden Sie im Handbuch Diagnostics Guide.

Inaktivieren des JIT-Compilers

Der JIT-Compiler kann auf verschiedene Arten inaktiviert werden. Beide Befehlszeilenoptionen überschreiben die Umgebungsvariable JAVA_COMPILER.

Das Inaktivieren des JIT-Compilers ist eine vorübergehende Maßnahme, die dazu beitragen kann, Probleme beim Debugging von Java-Anwendungen einzugrenzen.

Aktivieren des JIT-Compilers

Der JIT-Compiler ist standardmäßig aktiviert. Sie können ihn aber auch auf verschiedene Arten explizit aktivieren. Beide Befehlszeilenoptionen überschreiben die Umgebungsvariable JAVA_COMPILER.

Prüfen, ob der JIT-Compiler aktiviert ist

Sie können den Status des JIT-Compilers mit der Option -version ermitteln.

Führen Sie das Java-Startprogramm mit der Option -version aus. Geben sie Folgendes an einer Shelleingabeaufforderung 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 JVM ausgeführt werden.

Sobald der Garbage-Collector eine Speicheranforderung empfängt, wird hierfür nicht verwendeter Freispeicher durch einen Prozess vorgesehen, der auch als "Zuordnung" bezeichnet wird. 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 Aufruf System.gc() 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 können sich die Auswirkungen auf Ihre Anwendungen verringern.

Ausführliche Informationen zur Garbage-Collection finden Sie im Handbuch Diagnostics Guide.

Optionen der Garbage-Collection

Die Optionen -Xgcpolicy steuern das Verhalten des Garbage-Collectors. Sie führen einen Kompromiss herbei zwischen dem Durchsatz der Anwendung und des Gesamtsystems und den durch die Garbage-Collection verursachten Pausezeiten.

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

-Xgcpolicy:optthruput
(Standardmäßiger und empfohlener Wert.) Ermöglicht einen sehr hohen Anwendungsdurchsatz, wobei jedoch gelegentliche Pausen auftreten.
-Xgcpolicy:optavgpause
Verringert die Zeit der Garbage-Collection-Pausen. Außerdem werden die Auswirkungen 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.
-Xgcpolicy:gencon
Fordert die kombinierte Verwendung von gleichzeitig ablaufendem GC und GC nach Objektalter an, um alle Garbage-Collection-Pausen zu verringern.
-Xgcpolicy:subpool
(Nur PPC und zSeries.) 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.

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 -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 und 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 sehr nützlich. 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 Garbage-Collection nur auf die Objekte konzentriert, die höchstwahrscheinlich wiederverwendbar sind, können Sie die Pausezeit für einige Anwendungen weiter verringern. Die GC nach Objektalter verringert die Pausezeit, indem der Freispeicher in zwei "Generationen" aufgeteilt wird: 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 wenn sehr wenig Garbagespeicher freigegeben werden kann, 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 Garbage-Collection-Optionen Sie verwenden; wenn weiterhin Freispeicher angefordert wird, empfängt die Anwendung möglicherweise eine Ausnahmebedingung OutOfMemoryError wegen ungenügender Speicherkapazität und JVM wird beendet, es sei denn, die Ausnahmebedingung wird abgefangen und bearbeitet. In diesem Fall erstellt JVM eine Java-Speicherauszugsdatei, die während der Diagnose verwendet wird. Unter diesen Umständen sollten Sie entweder die Freispeichergröße mit der Option -Xmx erhöhen oder die Anzahl der verwendeten Objekte verringern.

Weitere Informationen finden Sie im Handbuch Diagnostics Guide.

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. Ab dem 1. Januar 2008 gilt der Euro auch für Zypern und Malta 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.

Schriftartkonfigurationsdateien zur Zurücksetzung

Die Linux-Schriftartkonfigurationsdateien zur Zurücksetzung (fontconfig.RedHat.bfc und fontconfig.SuSE.bfc) werden installiert, da sie Schriftarteinstellungen enthalten, die für neue unternehmensweite Linux-Varianten geeignet sind.

Das Vorhandensein dieser Dateien bedeutet nicht, dass die neue Linux-Variante eine unterstützte Plattform für IBM SDK and Runtime Environment for Linux platforms, Java Technology Edition, Version 6 darstellt.

| | |

Verwenden von Eingabemethoden für Indisch und Thailändisch

|
|

Ab Version 6 sind die Eingabemethoden für Indisch und Thailändisch nicht standardmäßig verfügbar. Sie müssen die entsprechenden JAR-Dateien manuell in den Java-Erweiterungspfad einschließen, um die Eingabemethoden für Indisch und Thailändisch verwenden zu können.

|

Bei Version 5.0 waren die JAR-Dateien für die Eingabemethoden im Verzeichnis jre/lib/ext enthalten und wurden von JVM automatisch geladen. Bei Version 6 sind diese JAR-Dateien im Verzeichnis |jre/lib/im enthalten und müssen dem Java-Erweiterungspfad manuell hinzugefügt werden, um die Eingabemethoden für Indisch und Thailändisch zu aktivieren. Dies wird durch eine der folgenden Methoden erreicht:

| |

|

Wenn SDK oder Runtime Environment in einem anderen Verzeichnis installiert sind, ersetzen Sie /opt/ibm/java-i386-60/ durch das Verzeichnis, in dem SDK oder Runtime Environment installiert sind.

Verwenden von SDK zur Entwicklung von Java-Anwendungen

Das SDK für Linux enthält viele Tools und Bibliotheken, die für die Java-Softwareentwicklung erforderlich sind.

Einzelheiten zu den verfügbaren Tools finden Sie in SDK-Tools und -Referenzinformationen.

| | |

Verwenden von XML

|
|

IBM SDK enthält die Parser XML4J und |XL XP-J, den Compiler XL TXE-J 1.0 XSLT und den Interpreter XSLT4J XSLT. |Mit Hilfe dieser Tools |können Sie XML-Dokumente unabhängig von einer bestimmten Implementierung zur XML-Verarbeitung |syntaktisch analysieren, umwandeln und serialisieren.

|

|

Verwenden Sie Factory-Finder zum Suchen von Implementierungen der abstrakten Factory-Klassen, wie unter Auswählen eines XML-Prozessors beschrieben. |Mit Hilfe der Factory-Finder können Sie eine andere XML-Bibliothek auswählen, ohne Ihren |Java-Code zu ändern.

|

| |

Verfügbare XML-Bibliotheken

|

IBM SDK for Java enthält die folgenden XML-Bibliotheken.

|
|
XML4J 4.5
|
|

XML4J ist ein Validierungsparser mit Unterstützung für die folgenden Standards: |

|
    |
  • XML 1.0 (4. Ausgabe)
  • |
  • Namespaces in XML 1.0 (2. Ausgabe)
  • |
  • XML 1.1 (2. Ausgabe)
  • |
  • Namespaces in XML 1.1 (2. Ausgabe)
  • |
  • W3C XML Schema 1.0 (2. Ausgabe)
  • |
  • XInclude 1.0 (2. Ausgabe)
  • |
  • OASIS XML Catalogs 1.0
  • |
  • SAX 2.0.2
  • |
  • DOM Level 3 Core, Load and Save
  • |
  • DOM Level 2 Core, Events, Traversal and Range
  • |
  • JAXP 1.4
| |

XML4J 4.5 basiert auf Apache Xerces-J 2.9.0. Weitere Informationen hierzu finden Sie unter http://xerces.apache.org/xerces2-j/.

|
|
XL XP-J 1.1
|
|

XL XP-J 1.1 ist ein leistungsfähiger Parser ohne Validierung mit Unterstützung für |StAX 1.0 (JSR 173); eine bidirektionale Anwendungsprogrammierschnittstelle für Pull-Parsing- und Streaming-Serialisierung |von XML 1.0- und XML 1.1-Dokumenten. Weitere Informationen dazu, was von XL XP-J 1.1 unterstützt wird, finden Sie in Referenzinformationen zu XL XP-J.

|
|
XL TXE-J 1.0.1 Beta
|
|

Bei Version 5.0 umfasste IBM SDK for Java den XSLT4J-Compiler und -Interpreter. |Der XSLT4J-Interpreter wurde standardmäßig verwendet.

| |

Bei Version 6 umfasst IBM SDK for Java |XL TXE-J. XL TXE-J umfasst den XSLT4J-Interpreter und einen neuen |XSLT-Compiler. |Der neue Compiler wird standardmäßig verwendet. Der XSLT4J-Compiler |ist in IBM SDK |for Java nicht mehr enthalten. Weitere Informationen zum Migrieren auf XL TXE-J finden Sie in Migrieren auf den XL-TXE-J-Compiler.

| |

XL TXE-J unterstützt die folgenden Standards: |

|
    |
  • XSLT 1.0
  • |
  • XPath 1.0
  • |
  • JAXP 1.4
|
|
|

| |

Auswählen eines XML-Prozessors

|

Die Auswahl eines XML-Prozessors wird mit Hilfe von Service-Providern durchgeführt. Bei Verwendung eines Factory-Finders schließt Java bei der Suche nach einem entsprechenden Service-Provider Folgendes ein: |

|
    |
  1. Das Systemmerkmal, das denselben Namen wie der Service-Provider hat.
  2. |
  3. Nur für XMLEventFactory, XMLInputFactory und |XMLOutputFactory. Den Wert des Service-Providers in der Datei /opt/ibm/java-i386-60/jre/lib/stax.properties.
  4. |
  5. Für andere Factorys. Den Wert des Service-Providers in der Datei /opt/ibm/java-i386-60/jre/lib/jaxp.properties.
  6. |
  7. Den Inhalt der Datei META-INF/services/<Service.Provider>.
  8. |
  9. Den standardmäßigen Service-Provider.
|

Die folgenden Service-Provider steuern die XML verarbeitenden Bibliotheken, die von Java verwendet werden: |

|
|
javax.xml.parsers.SAXParserFactory
|
Wählt den SAX-Parser aus. Standardmäßig wird org.apache.xerces.jaxp.SAXParserFactoryImpl aus der XML4J-Bibliothek verwendet. |
|
javax.xml.parsers.DocumentBuilderFactory
|
Wählt das Dokumenterstellungsprogramm aus. Standardmäßig wird org.apache.xerces.jaxp.DocumentBuilderFactoryImpl aus der |XML4J-Bibliothek verwendet. |
|
javax.xml.datatype.DatatypeFactory
|
Wählt die Datentypfactory aus. Standardmäßig wird org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl aus der |XML4J-Bibliothek verwendet. |
|
javax.xml.stream.XMLEventFactory
|
Wählt die StAX-Ereignisfactory aus. Standardmäßig wird com.ibm.xml.xlxp.api.stax.XMLEventFactoryImpl aus der |XL XP-J-Bibliothek verwendet. |
|
javax.xml.stream.XMLInputFactory
|
Wählt den StAX-Parser aus. Standardmäßig wird com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl aus der |XL XP-J-Bibliothek verwendet. |
|
javax.xml.stream.XMLOutputFactory
|
Wählt die StAX-Serialisierungsmethode aus. Standardmäßig wird com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl aus der |XL XP-J-Bibliothek verwendet. |
|
javax.xml.transform.TransformerFactory
|
Wählt den XSLT-Prozessor aus. Gültige Werte sind: | |
|
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
|
Verwendet den XL TXE-J-Compiler. Dies ist der Standardwert. |
|
org.apache.xalan.processor.TransformerFactoryImpl
|
Verwendet den XSLT4J-Interpreter. |
|
|
|
javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema
|
Wählt die Schemafactory für die W3C XML Schemasprache aus. Standardmäßig wird org.apache.xerces.jaxp.validation.XMLSchemaFactory aus der XML4J-Bibliothek verwendet. |
|
javax.xml.xpath.XPathFactory
|
Wählt den XPath-Prozessor aus. Standardmäßig wird org.apache.xpath.jaxp.XPathFactoryImpl aus der |XSLT4J-Bibliothek verwendet. |
|

| |

Migrieren auf den XL-TXE-J-Compiler

|
|

Der XL TXE-J-Compiler hat den XSLT4J-Interpreter als XSLT-Standardprozessor ersetzt. Führen Sie die folgenden Schritte aus, um Ihre Anwendung für die neue Bibliothek vorzubereiten.

|

|

Der XL TXE-J-Compiler ist schneller als der XSLT4J-Interpreter, wenn Sie die gleichen Transformationen mehrmals anwenden. Wenn Sie jede einzelne Transformation nur einmal anwenden, ist der XL TXE-J-Compiler auf Grund des Kompilierungs- und Optimierungsaufwands langsamer als der XSLT4J-Interpreter.

|

Setzen Sie den Service-Provider javax.xml.transform.TransformerFactory auf |org.apache.xalan.processor.TransformerFactoryImpl, um den XSLT4J-Interpreter weiterhin als Ihren XSLT-Prozessor zu verwenden.

|

Führen Sie zum Migrieren auf den XL-TXE-J-Compiler die folgenden Schritte aus:

|
    |
  1. Verwenden Sie com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl, wenn Sie den Service-Provider javax.xml.transform.TransformerFactory festlegen.
  2. |
  3. Generieren Sie vom XSLT4J-Compiler generierte Klassendateien neu. XL TXE-J kann keine Klassendateien ausführen, die vom XSLT4J-Compiler generiert wurden.
  4. |
  5. Durch einige vom Compiler generierten Methoden wird möglicherweise die JVM-Methodengrößenbegrenzung überschritten. In diesem Fall versucht der Compiler, diese Methoden in kleinere Methoden zu teilen. | |
      |
    • Wenn die Methode vom Compiler erfolgreich geteilt werden konnte, erhalten Sie die folgende Warnung: |"Einige generierte Funktionen überschritten die Größenbegrenzung der JVM-Methode und wurden automatisch in kleinere Funktionen geteilt. Sie können eine bessere Leistung erzielen, indem Sie sehr große Vorlagen manuell in kleinere Vorlagen teilen. Verwenden Sie dazu die Option 'splitlimit' mit dem Verarbeitungs- und Kompilierungsbefehl, oder legen Sie das Transformer-Factory-Attribut 'http://www.ibm.com/xmlns/prod/xltxe-j/split-limit' fest.". Sie können die kompilierten Klassen verwenden, aber Sie erzielen möglicherweise eine bessere Leistung, wenn Sie den Teilungsgrenzwert manuell steuern.
    • |
    • Wenn die Methode vom Compiler nicht erfolgreich geteilt wurde, erhalten Sie eine der folgenden Ausnahmebedingungen: "com.ibm.xtq.bcel.generic.ClassGenException: Branch target offset too large for short" oder "bytecode array size > 65535 |at offset=#####". Versuchen Sie, den Teilungsgrenzwert manuell festzulegen oder einen niedrigeren Teilungsgrenzwert zu verwenden.
    Verwenden Sie zum Festlegen des Teilungsgrenzwerts die Option -SPLITLIMIT, wenn Sie die Befehle |'Process' oder 'Compile' verwenden, oder das Transformer-Factory-Attribut http://www.ibm.com/xmlns/prod/xltxe-j/split-limit, wenn Sie die Transformer-Factory verwenden. Der Teilungsgrenzwert kann zwischen 100 und 2000 liegen. Verwenden Sie beim manuellen Festlegen des Teilungsgrenzwerts den größtmöglichen Teilungsgrenzwert, um die höchste Leistung zu erhalten.
  6. |
  7. Der XL TXE-J-Compiler benötigt möglicherweise mehr Speicher als der XSLT4J-Compiler. Erhöhen Sie mit Hilfe der Option -Xmx die Größe des Freispeichers, wenn Ihnen der Speicherplatz ausgeht, oder die Leistung nachlässt.
  8. |
  9. Migrieren Sie Ihre Anwendung, so dass sie die neuen Attributschlüssel verwendet. Die alten Attributschlüssel von Transformer-Factory sind veraltet. Die alten Namen werden unter Ausgabe einer Warnung akzeptiert. | | |||||||||||||||||||||||||||||||||||||||||||||||||||
    Tabelle 1. Änderungen an Attributschlüsseln zwischen dem XSL4J- und dem XL TXE-J-Compiler
    Attribut des XSL4J-Compilers Attribut des XL TXE-J-Compilers
    translet-name http://www.ibm.com/xmlns/prod/xltxe-j/translet-name
    destination-directory http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory
    package-name http://www.ibm.com/xmlns/prod/xltxe-j/package-name
    jar-name http://www.ibm.com/xmlns/prod/xltxe-j/jar-name
    generate-translet http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet
    auto-translet http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet
    use-classpath http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath
    debug http://www.ibm.com/xmlns/prod/xltxe-j/debug
    indent-number http://www.ibm.com/xmlns/prod/xltxe-j/indent-number
    enable-inlining Im neuen Compiler veraltet
  10. |
  11. Optional: Stellen Sie für eine optimale Leistung sicher, dass Sie wiederverwendbare XSLT-Transformationen nicht erneut kompilieren. Verwenden Sie zur Wiederverwendung kompilierter Transformationen eine der folgenden Methoden: | |
      |
    • Falls sich Ihr Style-Sheet während der Laufzeit nicht ändert, kompilieren Sie das Style-Sheet als Teil Ihres Erstellungsprozesses, |und stellen Sie die kompilierten Klassen in Ihren Klassenpfad. |Verwenden Sie den Befehl org.apache.xalan.xsltc.Compile zum Kompilieren des Style-Sheet und setzen Sie das Transformer-Factory-Attribut |http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath auf true, um die Klassen aus dem Klassenpfad zu laden.
    • |
    • Falls Ihre Anwendung dasselbe Style-Sheet für mehrere Ausführungen verwendet, setzen Sie das Transformer-Factory-Attribut http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet auf true, um das kompilierte Style-Sheet zur Wiederverwendung automatisch auf Platte zu speichern. Der Compiler verwendet ein kompiliertes Style-Sheet, falls ein solches verfügbar ist, und kompiliert das Style-Sheet, falls es nicht verfügbar oder nicht auf dem neuesten Stand ist. Verwenden Sie das Transformer-Factory-Attribut http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory, um das Verzeichnis festzulegen, in dem kompilierte Style-Sheets gespeichert werden sollen. |Kompilierte Style-Sheets werden standardmäßig im selben Verzeichnis wie das Style-Sheet gespeichert.
    • |
    • Handelt es sich bei Ihrer Anwendung um eine Anwendung mit langer Laufzeit, die dasselbe Style-Sheet wiederverwendet, verwenden Sie die Transformer-Factory zum Kompilieren des Style-Sheet, und erstellen Sie ein Templates-Objekt. Sie können das Objekt Templates zum Erstellen von Transformer-Objekten verwenden, ohne das Style-Sheet erneut kompilieren zu müssen. Auch die Transformer-Objekte können wiederverwendet werden, sind allerdings nicht threadsicher.
| |

XML-Referenzinformationen

|
|

Die XL XP-J- und XL TXE-J-XML-Bibliotheken sind bei Version 6 des SDK neu. In folgenden Referenzinformationen werden die von diesen Bibliotheken unterstützten Features beschrieben.

| | |

Referenzinformationen zu XL XP-J

|
|

XL XP-J 1.1 ist ein leistungsfähiger Parser ohne Validierung mit Unterstützung für |StAX 1.0 (JSR 173); eine bidirektionale Anwendungsprogrammierschnittstelle für Pull-Parsing- und Streaming-Serialisierung |von XML 1.0- und XML 1.1-Dokumenten.

|

| |

Nicht unterstützte Features
|

Die folgenden optionalen StAX-Features werden von |XL XP-J nicht unterstützt: |

|

|

| |

Referenzinformationen zu XMLInputFactory
|

Die folgenden Merkmale werden von der javax.xml.stream.XMLInputFactory-Implementierung unterstützt. Sie werden unter XMLInputFactory Javadoc beschrieben.

| |||||||||||||||||||||||||||||||||||||||||||
Tabelle 2.
Merkmalname Unterstützt
javax.xml.stream.isValidating Nein. Der XL XP-J-Scanner unterstützt keine Validierung.
javax.xml.stream.isNamespaceAware Ja (unterstützt 'true' und 'false'). Für XMLStreamReader, die aus |DOMSources erstellt wurden, ist die Namensbereichsverarbeitung abhängig von den Methoden, die zum Erstellen der DOM-Struktur verwendet wurden; dieser Wert hat keine Auswirkungen.
javax.xml.stream.isCoalescing Ja
javax.xml.stream.isReplacingEntityReferences Ja. Für XMLStreamReader, die aus |DOMSources erstellt wurden, hat die Festlegung dieses Parameters keine Auswirkungen, wenn bereits Entitäten in der DOM-Struktur ersetzt wurden.
javax.xml.stream.isSupportingExternalEntities Ja
javax.xml.stream.supportDTD Nein. DTDs werden immer unterstützt. Die Festlegung dieses Werts auf 'false' hat keine Auswirkungen.
javax.xml.stream.reporter Ja
javax.xml.stream.resolver Ja
|

XL XP-J unterstützt auch die optionale Methode createXMLStreamReader(javax.xml.transform.Source), |so dass StAX-Eingabeprogramme aus DOM- und SAX-Quellen erstellt werden können.

|

| |

Referenzinformationen zu XMLStreamReader
|

Die folgenden Merkmale werden von der javax.xml.stream.XMLStreamReader-Implementierung unterstützt. Sie werden unter XMLStreamReader Javadoc beschrieben.

| |||||||||||||||||||
Tabelle 3.
Merkmalname Unterstützt
javax.xml.stream.entities Ja
javax.xml.stream.notations Ja
|

XL XP-J unterstützt auch das Merkmal javax.xml.stream.isInterning, die einen booleschen Wert zurückgibt, der angibt, ob von den API-Aufrufen zurückgegebene XML-Namen und Namensbereichs-URIs vom Parser mit der Methode 'intern' verarbeitet wurden.

|

| |

Referenzinformationen zu XMLOutputFactory
|

Die folgenden Merkmale werden von der javax.xml.stream.XMLOutputFactory-Implementierung unterstützt. Sie werden unter XMLOutputFactory Javadoc beschrieben.

| |||||||||||||||
Tabelle 4.
Merkmalname Unterstützt
javax.xml.stream.isRepairingNamespaces Ja
|

| |

Referenzinformationen zu XMLStreamWriter
|

Die folgenden Merkmale werden von der javax.xml.stream.XMLStreamWriter-Implementierung unterstützt. Sie werden unter XMLStreamWriter Javadoc beschrieben.

| |||||||||||||||
Tabelle 5.
Merkmalname Unterstützt
javax.xml.stream.isRepairingNamespaces Ja
|

Die Merkmale bei XMLStreamWriter-Objekten sind schreibgeschützt.

| | |

Referenzinformationen zu XL TXE-J

|
|

XL TXE-J ist eine XSLT-Bibliothek, die den Interpreter XSLT4J 2.7.8 und einen XSLT-Compiler umfasst.

|

| |

Funktionsvergleichstabelle

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tabelle 6. Vergleich der Features von XSLT4J-Interpreter, XSLT4J-Compiler und XL TXE-J-Compiler
Funktion XSLT4J-Interpreter (enthalten) XSLT4J-Compiler (nicht enthalten) XL TXE-J-Compiler (enthalten)
http://javax.xml.transform.stream.StreamSource/feature - Funktion Ja Ja Ja
http://javax.xml.transform.stream.StreamResult/feature - Funktion Ja Ja Ja
http://javax.xml.transform.dom.DOMSource/feature - Funktion Ja Ja Ja
http://javax.xml.transform.dom.DOMResult/feature - Funktion Ja Ja Ja
http://javax.xml.transform.sax.SAXSource/feature - Funktion Ja Ja Ja
http://javax.xml.transform.sax.SAXResult/feature - Funktion Ja Ja Ja
http://javax.xml.transform.stax.StAXSource/feature - Funktion Ja Nein Ja
http://javax.xml.transform.stax.StAXResult/feature - Funktion Ja Nein Ja
http://javax.xml.transform.sax.SAXTransformerFactory/feature - Funktion Ja Ja Ja
http://javax.xml.transform.sax.SAXTransformerFactory/feature/xmlfilter - Funktion Ja Ja Ja
http://javax.xml.XMLConstants/feature/secure-processing - Funktion Ja Ja Ja
http://xml.apache.org/xalan/features/incremental - Attribut Ja Nein Nein
http://xml.apache.org/xalan/features/optimize - Attribut Ja Nein Nein
http://xml.apache.org/xalan/properties/source-location - Attribut Ja Nein Nein
Attribut 'translet-name' nicht zutreffend Ja Ja (mit neuem Namen)
Attribut 'destination-directory' nicht zutreffend Ja Ja (mit neuem Namen)
Attribut 'package-name' nicht zutreffend Ja Ja (mit neuem Namen)
Attribut 'jar-name' nicht zutreffend Ja Ja (mit neuem Namen)
Attribut 'generate-translet' nicht zutreffend Ja Ja (mit neuem Namen)
Attribut 'auto-translet' nicht zutreffend Ja Ja (mit neuem Namen)
Attribut 'use-classpath' nicht zutreffend Ja Ja (mit neuem Namen)
Attribut 'enable-inlining' Nein Ja Nein (in TL TXE-J veraltet)
Attribut 'indent-number' Nein Ja Ja (mit neuem Namen)
Attribut 'debug' Nein Ja Ja (mit neuem Namen)
Java-Erweiterungen Ja Ja (nur abgekürzte Syntax, Konstrukte 'xalan:component/xalan:script' werden nicht unterstützt)
JavaScript-Erweiterungen Ja Nein Nein
Erweiterungselemente Ja Nein Nein
EXSLT-Erweiterungsfunktionen Ja Ja (außer dynamischen) Ja (außer dynamischen)
Erweiterung 'redirect' Ja Ja (außer 'redirect:open' und 'redirect:close') Ja
Erweiterung 'output' Nein Ja Ja
Erweiterung 'NodeSet' Ja Ja Ja
Erweiterungsfunktionen 'NodeInfo' Ja Nein Nein
SQL-Bibliothekserweiterung Ja Nein Nein
Erweiterung 'pipeDocument' Ja Nein Nein
Erweiterung 'evaluate' Ja Nein Nein
Erweiterung 'tokenize' Ja Nein Nein
XML 1.1 Ja Ja Ja
|

| |

Hinweise
|

Verwenden Sie mit dem Verarbeitungsbefehl (Process) die Option -FLAVOR sr2sw für eine Umsetzung mit Hilfe der StAX-Streamverarbeitung und -FLAVOR er2ew für die StAX-Ereignisverarbeitung.

|

Der neue Compiler sucht nicht nach dem |Service-Provider org.apache.xalan.xsltc.dom.XSLTCDTMManager. Stattdessen schaltet der Compiler bei Verwendung von StreamSource auf einen leistungsfähigen XML-Parser um.

|

Inlining ist in XL TXE-J nicht mehr erforderlich. |

| |

Die Klasse org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl wird nicht mehr unterstützt.

| |

Verwenden einer älteren Version von Xerces oder Xalan

|
|

Wenn Sie im Überschreibungsverzeichnis eine älteren Version von Xerces (vor Version 2.0) oder Xalan (vor Version 2.3) verwenden, wird beim Starten der Anwendung möglicherweise die Ausnahmebedingung NullPointerException 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: |

|

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.

Weitere Informationen zur Problemdiagnose unter Verwendung von Java finden Sie im Handbuch Diagnostics Guide.

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> <Klasse>
    Daraufhin startet JVM. Vor dem Starten der Java-Anwendung wird die Ausführung jedoch ausgesetzt.
  2. Sie können den Debugger in einer separaten Sitzung über folgenden Befehl JVM zuordnen:
    jdb -attach <Port>
    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 starten.

Wenn Sie weitere Informationen zu JDB-Optionen aufrufen möchten, geben Sie Folgendes ein:

jdb -help

Wenn Sie weitere Informationen zu JDB-Befehlen aufrufen möchten:

  1. Geben Sie jdb ein.
  2. Geben Sie an 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 unter Angabe folgender Optionen:
    java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<Port> <Klasse>
    Daraufhin startet JVM. Vor dem Starten der Java-Anwendung wird die Ausführung jedoch ausgesetzt.
  2. Ordnen Sie den Debugger mit folgendem Befehl der fernen JVM zu:
    jdb -attach <Host>:<Port>

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:

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:

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

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

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:

Informationen zum Schreiben eines Startprogramms, das die oben aufgeführten Hooks angibt, finden Sie unter der folgenden Adresse: http://www.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:

  1. Aufrufen der Signalroutine Ihrer Anwendung für dieses Signal.
  2. Ausführen aller Hooks für das Beenden der Anwendung.
  3. Aufrufen eines beliebigen durch die Anwendung installierten Exit-Hooks.
  4. 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

Die Signaltypen sind Ausnahmebedingungen, Fehler, Interrupts und Steuerzeichen.

In Tabelle 7 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 7. Von JVM verwendete Signale
Signalname Signaltyp Beschreibung Inaktiviert durch -Xrs
SIGBUS (7) Ausnahmebedingung Falscher Zugriff auf den Speicher (falsche Datenanordnung) Ja
SIGSEGV (11) Ausnahmebedingung Falscher Zugriff auf den Speicher (es wurden Daten in einen Speicherbereich geschrieben, auf den nicht zugegriffen werden kann). Ja
SIGILL (4) Ausnahmebedingung Nicht zulässige Anweisung (es wurde versucht, eine unbekannte Maschineninstruktion aufzurufen). Nein
SIGFPE (8) Ausnahmebedingung Ausnahmebedingung bei der Gleitkommaverarbeitung (Division durch null). Ja
SIGABRT (6) Fehler Abnormale Beendigung. JVM setzt dieses Signal ab, sobald ein JVM-Fehler festgestellt wird. Ja
SIGINT (2) Interrupt Interaktiver Abruf (Strg-C). JVM wird normal beendet. Ja
SIGTERM (15) Interrupt Beendigungsanforderung. JVM wird normal beendet. Ja
SIGHUP (1) Interrupt Auflegen. JVM wird normal beendet. Ja
SIGQUIT (3) Steuerzeichen Ein Beendigungssignal für ein Terminal. Standardmäßig wird dadurch ein Java-Speicherauszug ausgelöst. Ja
SIGTRAP (5) Steuerzeichen Vom JIT-Compiler verwendet. Ja
__SIGRTMAX - 2 Steuerzeichen Von SDK verwendet. Nein
SIGCHLD (17) 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.

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 Routinen ersetzt werden. Stattdessen werden die neuen Signalroutinen durch diese Aufrufe gesichert oder nach den durch JVM installierten Signalroutinen hinzugefügt. Wenn diese Signale zu einem späteren Zeit gesendet werden und nicht an JVM gerichtet sind, werden die vorinstallierten Signalroutinen aufgerufen.

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

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.

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

Die Umgebungsvariable JAVA_HOME muss auf die Speicherposition des SDK gesetzt werden. Beispiel: /opt/ibm/java-i386-60/.

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

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) und JNI_VERSION_1_4(0x00010004).

Einschränkung: Version 1.1 der JNI (Java Native Interface) wird nicht unterstützt.

Ü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 JSE-Bibliotheken angegeben (d. h. V6). 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 finden Sie unter http://java.sun.com/javase/6/docs/technotes/guides/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 JVM derzeit im 32- oder 64-Bit-Modus ausgeführt wird, und wählen Sie dann die geeignete Bibliothek aus.

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

gcc -I/opt/ibm/java-i386-60/include -L/opt/ibm/java-i386-60/jre/lib/<Architektur>/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.

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 Synchronisationsaufrufen.
InterruptibleThread (öffentliche Klasse)
Eine Dienstprogrammklasse zur Erweiterung von java.lang.Thread, um die Wiederverwendung von Methoden zu ermöglichen, die unterbrochen werden können. Sie verwendet Instanzen der Klassen InterruptibleLockContext und InterruptibleIOContext, um die erforderlichen Methoden isBlocked() und unblock() auszuführen, abhängig davon, ob ein Synchronisations- oder Netzbetriebsprozess den Thread blockiert.

Die Klassen InterruptibleLockContext und InterruptibleIOContext funktionieren beide 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 dem SDK in der Datei docs/content/apidoc.zip mitgeliefert.

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, dass 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 führen Sie Java als Root aus, oder Sie legen das SUID-Bit des Java-Startprogramms fest.

CORBA-Unterstützung

Java Platform, Standard Edition (JSE) unterstützt mindestens die Spezifikationen, die in der Erfüllungsbestätigung von Sun definiert sind. In einigen Fällen unterstützt IBM JSE ORB neuere Versionen der Spezifikationen.

Die unterstützten Mondestspezifikationen sind in Offizielle Spezifikationen für die CORBA-Unterstützung in Java SE 6 definiert.

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.

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

Merkmale der Tracefunktion

com.ibm.CORBA.Debug=wahr
Aktiviert die ORB-Tracefunktion.
com.ibm.CORBA.CommTrace=wahr
Fügt dem Trace GIOP-Nachrichten hinzu (gesendete und empfangene).
com.ibm.CORBA.Debug.Output=<Datei>
Geben Sie die Datei für die Traceausgabe an. Diese muss standardmäßig im folgenden Format eingegeben werden: orbtrc.TTMMJJJJ.HHmm.SS.txt.

Beispiel für die ORB-Tracefunktion

Geben Sie z. B. Folgendes ein, um ein Trace für Ereignisse und formatierte GIOP-Nachrichten über die Befehlszeile durchzuführen:

 java -Dcom.ibm.CORBA.Debug=true
     -Dcom.ibm.CORBA.CommTrace=true <MeineAnwendung>

Einschränkungen

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 schwer wiegende Fehler dokumentiert werden. Wenn eine Debugausgabedatei generiert wird, prüfen Sie sie in Bezug auf dieses Problem. Der Server könnte z. B. seinen Betrieb eingestellt haben, 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

Der ORB kann optimiert werden, so dass er mit Ihrem spezifischen Netzwerk gut zusammenarbeitet. Die erforderlichen Merkmale für die Optimierung sind hier beschrieben.

com.ibm.CORBA.FragmentSize=<Größe in Byte>
Wird zur Kontrolle der GIOP 1.2-Fragmentierung verwendet. Die Standardgröße ist 1024 Byte.

Setzen Sie die Fragmentgröße auf 0 Byte, um die Fragmentierung zu inaktivieren:

java -Dcom.ibm.CORBA.FragmentSize=0 <MeineAnwendung>
com.ibm.CORBA.RequestTimeout=<Zeit in Sekunden>
Legt die maximale Zeit fest, während der auf eine CORBA-Anforderung gewartet wird. Standardmäßig wartet der ORB unbegrenzt. Legen Sie für das Zeitlimit keinen zu niedrigen Wert fest, um zu vermeiden, dass Verbindungen unnötigerweise beendet werden.
com.ibm.CORBA.LocateRequestTimeout=<Zeit in Sekunden>
Legt die maximale Zeit fest, während der auf eine CORBA-Anforderung 'LocateRequest' gewartet wird. Standardmäßig wartet der ORB unbegrenzt.
com.ibm.CORBA.ListenerPort=<Portnummer>
Legt den Port fest, an der der ORB einkommende Anforderungen liest. 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-Sicherheitsberechtigungen für den ORB

Bei der Ausführung von Java-SecurityManager kann das Aufrufen einiger Methoden in den CORBA-API-Klassen Berechtigungsprüfungen verursachen, die wiederum zu einer Ausnahmebedingung SecurityException führen. Falls Ihr Programm eine der aufgeführten Methoden verwendet, müssen Sie sicherstellen, dass die erforderlichen Berechtigungen vorliegen.

Tabelle 8. Methoden, auf die sich das Ausführen von Java-SecurityManager 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

ORB-Implementierungsklassen

Eine Liste der ORB-Implementierungsklassen.

Die ORB-Implementierungsklassen in diesem Release lauten:

Hierbei handelt es sich um die Standardwerte. Es wird jedoch empfohlen, diese Merkmale nicht direkt festzulegen bzw. nicht direkt auf die Implementierungsklassen zu verweisen. Aus Gründen der Portierbarkeit sollte ausschließlich auf die CORBA-API-Klassen und nicht auf die Implementierungsklassen verwiesen werden. Diese Werte werden in zukünftigen Releases möglicherweise geändert.

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:

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

Diese Runtime Environment-Version verfügt über keine Einstellung, die Sie verwenden können, um die Anzahl Threads im Verbindungspool zu begrenzen.

Funktionale Erweiterungen für BigDecimal

Über Java 5.0 wurde die IBM BigDecimal-Klasse von Sun als java.math.BigDecimal übernommen. Die Klasse com.ibm.math.BigDecimal ist für eine mögliche zukünftige Verwendung von IBM reserviert und wird derzeit nicht weiter unterstützt. Migrieren Sie bereits vorhandenen Java-Code für die Verwendung von java.math.BigDecimal.

Die neue Klasse java.math.BigDecimal verwendet dieselben Methoden wie die Vorversion java.math.BigDecimal und wie com.ibm.math.BigDecimal. Der bereits vorhandene Code, der java.math.BigDecimal verwendet, funktioniert weiterhin ordnungsgemäß. Die beiden Klassen serialisieren nicht.

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

Plug-in, Applet Viewer und Web Start

Das Java Plug-in dient zum Ausführen von Java-Anwendungen im Browser. appletviewer dient zum Testen von Anwendungen, die für die Ausführung in einem Browser entworfen wurden. Java Web Start dient zum Implementieren von Java-Desktopanwendungen in einem Netzwerk und stellt einen Mechanismus zum Aktualisieren dieser Anwendungen bereit.

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

Das Java Plug-in ist ein Web-Browser Plug-in. Sie verwenden das Java Plug-in zum Ausführen von Applets im Browser.

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 wird von Sun auf folgender Website dokumentiert: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.

Unterstützte Browser

Das Java Plug-in unterstützt SeaMonkey, Mozilla, und Mozilla Firefox.

Tabelle 9. Vom Java Plug-in unterstützte Browser unter Linux IA32
Browser Unterstützte Versionen
Mozilla 1.7.12, 1.8
Firefox 1.5, 2.0
Tabelle 10. Vom Java Plug-in unterstützte Browser unter Linux PPC32
Browser Unterstützte Versionen
Mozilla 1.6
|SeaMonkey |1.0.8

Neuere untergeordnete Releases von Browsern werden ebenfalls unterstützt.

Installieren und Konfigurieren des Java Plug-ins

Verlinken Sie das Java Plug-in zum Installieren symbolisch mit dem Plug-in-Verzeichnis Ihres Browsers.

Das Java Plug-in basiert auf der Initiative Open JVM Integration von Mozilla, die für die meisten Mozilla-Produkte und von Mozilla abgeleiteten Produkte, einschließlich Firefox, verwendet wird.

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.

  1. Melden Sie sich als Root an.
  2. Wechseln Sie in das Plug-in-Verzeichnis für Mozilla (dieses Verzeichnis kann bei einigen Linux-Varianten anders lauten).
  3. Erstellen Sie einen symbolischen Link zum Plug-in.
     ln -s /opt/ibm/java-i386-60/jre/plugin/<Architektur>/ns7/libjavaplugin_oji.so .
    Dabei stellt <Architektur> die Architektur Ihres Systems dar.

Wählen Sie in Mozilla Help -> About Plug-ins aus, um zu prüfen, ob das Java Plug-in verfügbar und aktiviert ist.

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

Einschränkung: Das Verzeichnis /usr/local/mozilla/plugins/ darf nur eine gemeinsam genutzte Java Plug-in-Bibliothek enthalten. Mozilla versucht, alle Elemente dieses Verzeichnisses (oder des zugehörigen Unterverzeichnisses) als Plug-in zu laden. Wenn jedoch zwei Versionen des Java Plug-ins geladen werden, kann es zu unvorhersehbaren Ergebnissen kommen.

Firefox

Durch diese Schritte wird das Java Plug-in für alle Benutzer verfügbar:

  1. Melden Sie sich als Root an.
  2. Wechseln Sie in das Plug-in-Verzeichnis für Firefox (dieses Verzeichnis kann bei einigen Linux-Varianten anders lauten).
    cd /usr/local/mozilla-firefox/plugins/
  3. Erstellen Sie einen symbolischen Link zum Plug-in.
     ln -s /opt/ibm/java-i386-60/jre/plugin/<Architektur>/ns7/libjavaplugin_oji.so .
    Dabei stellt <Architektur> die Architektur Ihres Systems dar.

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.

Einer der folgenden Fehler wird 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 Ihr HTML-Dokument an, indem Sie den Tag <META> im Abschnitt <HEAD> wie folgt verwenden:

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

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

Mit dem folgenden Befehl führen Sie ein Applet mit Applet Viewer aus.

Geben Sie Folgendes an einer Shelleingabeaufforderung ein:

   appletviewer <Name>

Dabei steht <Name> für Folgendes:

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

Dabei gilt Folgendes: <Dateiname> ist der Name der HTML-Datei.

Geben Sie zum Aufrufen von Applet Viewer auf einer 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 der 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.

Beispiel:

cd demo/applets/TicTacToe
../../../bin/appletviewer -debug example1.html

Dokumentation zum Debugging von Applets mit Applet Viewer finden Sie auf der Website von Sun unter: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.

(Nur Linux IA 32 Bit, PPC32 und PPC64) Verwenden von Web Start

Java Web Start wird für die Implementierung von Java-Anwendungen verwendet.

Web Start bietet Ihnen die Möglichkeit, Anwendungen direkt über das Internet aufzurufen und zu verwalten. Die Anwendungen sind in einem Cache gespeichert, um die Installationszeit zu verringern. Für die Anwendungen werden automatisch Upgrades durchgeführt, sobald neue Versionen verfügbar sind.

Web Start unterstützt die folgenden JVM-Attribute (java-vm-args), die unter http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources dokumentiert sind:

IBM Web Start unterstützt auch -Xgcpolicy, um die Garbage-Collection-Richtlinie festzulegen.

Weitere Informationen zu Browsern, die Web Start unterstützen, finden Sie inUnterstützte Browser.

Weitere Informationen zu Web Start finden Sie unter:

Weitere Informationen zur Implementierung von Anwendungen finden Sie unter

Ausführen von Java Web Start

Web Start kann in einer Webseite oder in der Befehlszeile ausgeführt werden. Web Start-Anwendungen werden im Java-Anwendungscache gespeichert.

Java Web Start Version 6 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 verschiedene Arten aufrufen.

(Nur Linux IA 32 Bit) Sichere statische Versionssteuerung für WebStart

Die statische Versionssteuerung ermöglicht es Web Start-Anwendungen, eine bestimmte JVM-Version anzufordern, um unter dieser Version ausgeführt zu werden. Da Anwendungen auf Grund dieser Funktionalität auch alte Sicherheitslücken auf Systemen ausnutzen können, für die ein Upgrade auf eine neue JVM ausgeführt wurde, wird die sichere statische Versionssteuerung (SSV - Secure Static Versioning) nun standardmäßig verwendet.

Durch SSV erhält der Benutzer eine Warnung, bevor er eine nicht signierte Web Start-Anwendung ausführt, die die Verwendung einer bestimmten JVM erfordert. Signierte Anwendungen und Anwendungen, die die neueste Version von JVM erfordern, werden wie üblich ausgeführt.

Sie können die SSV inaktivieren, indem Sie für das Merkmal deployment.javaws.ssv.enabled in der Datei deployment.properties den Wert 'false' festlegen.

Ausliefern von Java-Anwendungen

Java-Anwendungen bestehen normalerweise aus Klassen-, Ressourcen- und Datendateien.

Bei der Auslieferung einer Java-Anwendung kann im Softwarepaket beispielsweise Folgendes enthalten sein:

Zum Ausführen der Anwendung benötigt der Benutzer Runtime Environment for 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

Die gemeinsame Nutzung von Klassendaten ermöglicht es mehreren JVMs, einen einzigen Speicherbereich im Hauptspeicher gemeinsam zu nutzen.

Java Virtual Machine (JVM) ermöglicht Ihnen die gemeinsame Nutzung von Klassendaten auf verschiedenen JVMs, indem die Daten in eine im Speicher abgelegte Cachedatei auf Platte gestellt werden. Durch die gemeinsame Nutzung verringert sich die gesamte virtuelle Speicherbelegung, wenn mehrere JVMs einen Cache gemeinsam nutzen. Außerdem verkürzt sich durch die gemeinsame Nutzung der Systemstart von JVM, nachdem der Cache erstellt wurde. Der Cache für gemeinsam genutzte Klassen ist unabhängig von aktiven JVMs und besteht, bis er gelöscht wird.

Ein gemeinsam genutzter Cache kann Folgendes enthalten:

Übersicht über die gemeinsame Nutzung von Klassendaten

Die gemeinsame Nutzung von Klassendaten stellt eine transparente Methode zur Verringerung des Speicherbedarfs und zur Verbesserung der JVM-Startzeit bereit. |Java 6 |stellt neue und verbesserte Features bei Cacheverwaltung, -isolation und -leistung bereit.

Aktivieren der gemeinsamen Nutzung von Klassendaten

Sie können die gemeinsame Nutzung von Klassendaten mit Hilfe der Option -Xshareclasses beim Starten von JVM aktivieren. JVM stellt eine Verbindung zu einem vorhandenen Cache her oder erstellt einen neuen Cache, wenn keiner vorhanden ist.

Alle über JVM geladenen Boot- und Anwendungsklassen werden standardmäßig gemeinsam genutzt. Benutzerdefinierte Klassenladeprogramme nutzen Klassen automatisch gemeinsam, wenn sie das Klassenladeprogramm der Anwendung erweitern; andernfalls müssen sie die zusammen mit JVM verfügbare Java Helper API verwenden, um auf den Cache zugreifen zu können. (Siehe hierzu die Informationen in Anpassen benutzerdefinierter Klassenladeprogramme an gemeinsam genutzte Klassen.)

|Von JVM kann auch vorkompilierter Code (AOT-Code) für bestimmte Methoden im Cache gespeichert werden, um die Startzeit nachfolgender JVMs zu verbessern. Der vorkompilierte Code wird nicht tatsächlich von den JVMs gemeinsam genutzt, sondern zwischengespeichert, um die Kompilierzeit beim Start von JVM zu verringern. Die Menge des im Cache gespeicherten AOT-Codes wird heuristisch ermittelt. Sie können nicht steuern, welche Methoden im Cache gespeichert werden, Sie können jedoch die Unter- und Obergrenzen des für AOT-Code verwendeten Cachespeicherplatzes festlegen oder das Caching von AOT-Code gänzlich inaktivieren. |Weitere Informationen hierzu finden Sie unter Aktivieren und Konfigurieren der gemeinsamen Nutzung von Klassendaten.

Cachezugriff

|JVM kann auf einen Cache entweder mit Lese- und Schreibzugriff oder nur mit Lesezugriff zugreifen. Jede JVM, die mit einem Cache verbunden ist, auf den Lese- und Schreibzugriff besteht, kann den Cache aktualisieren. Es können beliebig viele JVMs gleichzeitig aus dem Cache lesen, auch während eine andere JVM in den Cache schreibt.

Bei der Bearbeitung von Laufzeitbytecodes müssen Sie sorgfältig vorgehen. Weitere Informationen hierzu finden Sie in Änderungen bei Laufzeitbytecodes.

Dynamisches Aktualisieren des Caches

Da der Cache für gemeinsam genutzte Klassen über die Laufzeit von JVMs 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.

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 Klassendaten registriert ist, kann den Cache für gemeinsam genutzte Klassen aktualisieren.

|Der Cache wird vor versehentlicher oder absichtlicher Beschädigung durch den Speicherseitenschutz geschützt. Dies ist kein absoluter Schutz vor einer Beschädigung, weil der Schutz von Seiten durch JVM aufgehoben werden muss, damit in diese geschrieben werden kann. Die einzige Möglichkeit, sicherzustellen, dass ein Cache nicht geändert werden kann, besteht darin, ihn schreibgeschützt zu öffnen.

Wenn ein Java-SecurityManager 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 SharedClassPermission-Zeilen hinzugefügt werden. (Siehe hierzu die Informationen in Verwenden von 'SharedClassPermissions'.) Die RuntimePermission "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. JVM kann zur selben Zeit nur mit jeweils einem Cache verbunden werden.

Die Standardcachegröße kann beim Systemstart über den Befehl -Xscmx<n><Größe> überschrieben werden. Diese 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 die Cachedatei manuell gelöscht wird.

Cache-Dienstprogramme

Alle Cache-Dienstprogramme sind Unteroptionen des Befehls -Xshareclasses. Lesen Sie Aktivieren und Konfigurieren der gemeinsamen Nutzung von Klassendaten oder verwenden Sie -Xshareclasses:help, um eine Liste der verfügbaren Unteroptionen anzuzeigen.

Aktivieren und Konfigurieren der gemeinsamen Nutzung von Klassendaten

Die Dienstprogramme zur gemeinsamen Nutzung von Klassendaten und zur Cacheverwaltung werden mit Hilfe von Befehlszeilenoptionen des Startprogramms java gesteuert.

In Optionen, die einen 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 nachstellen.

-Xscmaxaot<Größe>
Legt die maximale Anzahl von Byte im Cache fest, die für AOT-Daten verwendet werden können. Verwenden Sie diese Option, um sicherzustellen, dass eine bestimmte Menge an Cachespeicherbereich für Nicht-AOT-Daten zur Verfügung steht. Der Maximalwert für AOT-Daten ist standardmäßig die Menge des freien Speicherbereichs im Cache. Der Wert für diese Option sollte nicht kleiner als der Wert für -Xscminaot und nicht größer als der Wert für -Xscmx sein.
-Xscminaot<Größe>
Legt die minimale Anzahl von Byte im Cache fest, die für AOT-Daten reserviert werden soll. Für AOT-Daten wird standardmäßig kein Speicherbereich reserviert, obwohl AOT-Daten in den Cache geschrieben werden, bis der Cache voll oder der Grenzwert -Xscmaxaot erreicht ist. Der Wert für diese Option sollte nicht den Wert für -Xscmx oder -Xscmaxaot überschreiten. Der Wert für -Xscminaot sollte immer deutlich unter der Gesamtcachegröße liegen, weil AOT-Daten nur für zwischengespeicherte Klassen erstellt werden können. Falls der Wert für -Xscminaot gleich dem Wert für -Xscmx ist, werden keine Klassen- oder AOT-Daten gespeichert, weil AOT-Daten einer Klasse im Cache zugeordnet sein müssen.
-Xscmx<Größe>
Gibt die Cachegröße an. Diese Option wird nur angewendet, wenn ein Cache erstellt wird und 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 in Grenzwerte für die Cachegröße.)
-Xshareclasses:<Unteroption>[,<Unteroption>...]
Aktiviert die gemeinsame Nutzung von Klassendaten. 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. Wenn Cache-Dienstprogramme ausgeführt werden, wird die Nachricht erwartet, dass die virtuelle Maschine nicht erstellt werden konnte ("Could not create the Java virtual machine"). Cache-Dienstprogramme erstellen nicht die virtuelle Maschine.

Manche Cache-Dienstprogramme arbeiten mit Caches von vorherigen Java-Versionen bzw. Caches zusammen, die von JVMs mit unterschiedlichen Bitbreiten erstellt wurden. Diese Caches werden als "inkompatible" Caches bezeichnet.

Zusammen mit der Option -Xshareclasses können Sie folgende Unteroptionen verwenden:

help
Listet alle Befehlszeilenunteroptionen auf.
name=<Name>
Stellt die Verbindung zu einem Cache mit einem bestimmten Namen her und erstellt den Cache, falls er nicht bereits vorhanden ist. Wird auch verwendet, um den Cache anzugeben, der durch Cache-Dienstprogramme wie z. B. "destroy" geändert werden soll. Mit dem Dienstprogramm listAllCaches kann angezeigt werden, welche benannten Caches derzeit verfügbar sind. Wenn Sie keinen Namen angeben, wird als Cachename der Standardname "sharedcc_%u" verwendet. Durch '%u' im Cachenamen wird der Name des aktuellen Benutzers eingefügt. Sie können '%g' im Cachenamen angeben, um den Namen der aktuellen Gruppe einzufügen.
|cacheDir=<Verzeichnis>
|Legt das Verzeichnis fest, in dem Cachedaten gelesen und geschrieben werden. Standardmäßig ist <Verzeichnis> das Verzeichnis /tmp/javasharedresources. Der Benutzer benötigt ausreichende Berechtigungen im <Verzeichnis>. Standardmäßig schreibt JVM persistente Cachedateien direkt in das angegebene Verzeichnis. Persistente Cachedateien können im Dateisystem sicher verschoben und gelöscht werden. Nicht persistente Caches werden im gemeinsam genutzten Speicher gespeichert, wobei die Position des Speichers in Steuerdateien beschrieben wird. Steuerdateien werden im Unterverzeichnis javasharedresources des mit cacheDir angegebenen Verzeichnisses gespeichert. |Die Steuerdateien in diesem Verzeichnis dürfen nicht manuell verschoben oder gelöscht werden. Das Dienstprogramm listAllCaches, das Dienstprogramm destroyAll und die Unteroption expire funktionieren nur im Gültigkeitsbereich eines mit cacheDir angegebenen Verzeichnisses.
|readonly
|Öffnet einen vorhandenen Cache nur mit Leseberechtigung. Mit dieser Unteroption erstellt JVM keinen neuen Cache. Wird ein Cache nur mit Leseberechtigung geöffnet, wird verhindert, dass von JVM Aktualisierungen des Caches vorgenommen werden. Außerdem kann von JVM eine Verbindung zu Caches hergestellt werden, die von anderen Benutzern oder Gruppen erstellt wurden, ohne dass dazu Schreibzugriff erforderlich ist. Diese Unteroption ist standardmäßig nicht angegeben.
|nonpersistent
|Verwendet einen nicht persistenten Cache. Standardmäßig erstellt JVM eine Cachedatei auf Platte, die beim Neustart des Betriebssystems bestehen bleibt. Mit der Unteroption nonpersistent wird der Cache im gemeinsam genutzten Speicher erstellt, er bleibt aber nicht bestehen, wenn das Betriebssystem beendet wird. Nicht persistente und persistente Caches können den gleichen Namen haben. Die Unteroption nonpersistent muss immer verwendet werden, wenn Sie Dienstprogramme wie destroy für einen nicht persistenten Cache ausführen. Diese Unteroption ist standardmäßig nicht angegeben.
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
Aktiviert die ausführliche Ausgabe, mit der der Gesamtstatus des Caches für gemeinsam genutzte Klassen und ausführlichere Fehlernachrichten bereitgestellt werden.
|verboseAOT
|Aktiviert die ausführliche Ausgabe, wenn kompilierter AOT-Code im Cache gefunden oder gespeichert wird. AOT-Code wird heuristisch generiert. Bei einer weniger umfangreichen Anwendung sehen Sie möglicherweise gar keinen generierten AOT-Code. Das AOT-Caching kann mit der Unteroption noaot inaktiviert werden.
verboseIO
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.
verboseHelper
Aktiviert die ausführliche Ausgabe für die Java Helper-API. Diese Ausgabe zeigt Ihnen, wie die Helper-API von Ihrem Klassenladeprogramm verwendet wird.
silent
Inaktiviert alle Nachrichten der gemeinsam genutzten Klassen, einschließlich der Fehlernachrichten.
nonfatal
Ermöglicht das Starten von JVM, auch wenn die gemeinsame Nutzung von Klassendaten fehlschlägt. Das normale Verhalten von JVM wäre, bei Fehlschlagen der gemeinsamen Nutzung von Klassendaten nicht zu starten. Wenn diese Option ausgewählt ist, und die Initialisierung des Caches für gemeinsam genutzte Klassen fehlschlägt, versucht JVM, die Verbindung zum Cache im Nur-Lesen-Modus herzustellen. Schlägt dies fehl, startet JVM ohne gemeinsame Nutzung der Klassendaten.
none
Kann dem Ende einer Befehlszeile hinzugefügt werden, um die gemeinsame Nutzung von Klassendaten zu inaktivieren. Diese Unteroption überschreibt Argumente der gemeinsamen Nutzung von Klassen, die in einem früheren Stadium in der Befehlszeile enthalten waren.
modified=<Geänderter Kontext>
Wird verwendet, wenn ein JVMTI-Agent installiert wurde, der möglicherweise den Bytecode während der Laufzeit ändert. Wenn Sie diese Unteroption nicht angeben und ein Agent für Änderungen des Bytecodes installiert ist, werden Klassen sicher gemeinsam genutzt, doch dabei entsteht zusätzlicher Leistungsaufwand. Bei der Angabe <Geänderter Kontext> handelt es sich um einen vom Benutzer ausgewählten Deskriptor, wie z. B. "MeineÄnderungen1". Diese Option partitioniert den Cache, so 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. Weitere Informationen hierzu finden Sie in Änderungen bei Laufzeitbytecodes.
|reset
|Bewirkt, dass ein Cache gelöscht und beim Initialisieren von JVM erneut erstellt wird. Kann als -Xshareclasses:reset dem Ende einer Befehlszeile hinzugefügt werden.
destroy (Dienstprogrammoption)
Löscht einen durch die Unteroptionen name, cacheDir und nonpersistent angegebenen Cache. Ein Cache kann nur gelöscht werden, wenn alle JVMs, die diesen Cache verwenden, heruntergefahren wurden und der Benutzer über die erforderlichen Berechtigungen verfügt.
destroyAll (Dienstprogrammoption)
Versucht, mit Hilfe der angegebenen Unteroptionen cacheDir und nonpersistent alle verfügbaren Caches zu löschen. Ein Cache kann nur gelöscht werden, wenn alle JVMs, die diesen Cache verwenden, heruntergefahren wurden und der Benutzer über die erforderlichen Berechtigungen verfügt.
expire=<Zeit in Minuten>
Löscht vor dem Laden der gemeinsam genutzten Klassen alle Caches, die während der angegebenen Zeit nicht verwendet wurden. Dies ist keine Dienstprogrammoption, weil JVM dadurch nicht beendet wird.
listAllCaches (Dienstprogrammoption)
Listet alle kompatiblen und inkompatiblen Caches auf, die im angegebenen Cacheverzeichnis vorhanden sind. Wenn cacheDir nicht angegeben ist, wird das Standardverzeichnis verwendet. Es werden Übersichtsdaten wie Java-Version und aktuelle Nutzung für jeden Cache angezeigt.
printStats (Dienstprogrammoption)
Zeigt Übersichtsdaten für den mit den Unteroptionen name, cacheDir und nonpersistent angegebenen Cache an. Zu den nützlichsten Informationen gehören die Angaben zur Speicherbelegung im Cache und die Anzahl der darin enthaltenen Klassen. Bei "veralteten" Klassen handelt es sich um Klassen, die auf dem Dateisystem aktualisiert wurden und die der Cache daher mit "veraltet" gekennzeichnet hat. Veraltete Klassen werden nicht aus dem Cache gelöscht und können wiederverwendet werden. Weitere Informationen finden Sie im Handbuch Diagnostics Guide.
printAllStats (Dienstprogrammoption)

Zeigt ausführliche Informationen für den mit den Unteroptionen name, cacheDir und nonpersistent angegebenen Cache an. Alle Klassen werden in chronologischer Reihenfolge zusammen mit einem Verweis auf die Speicherposition aufgelistet, von der aus sie geladen wurden. Der AOT-Code für Klassenmethoden wird ebenfalls aufgelistet.

Weitere Informationen finden Sie im Handbuch

Diagnostics Guide.

|mprotect=[ all || default | none ]
|Standardmäßig sind die im Cache enthaltenen Speicherseiten immer geschützt, außer wenn eine bestimmte Seite aktualisiert wird. So kann der Cache vor versehentlicher oder absichtlicher Beschädigung geschützt werden. Der Cache-Header wird standardmäßig nicht geschützt, da damit ein geringer Leistungsaufwand verbunden ist. Durch Angabe von "all" wird sichergestellt, dass alle Cacheseiten, einschließlich Header, geschützt werden. Durch Angabe von "none" wird der Seitenschutz inaktiviert.
|noBootclasspath
|Verhindert die Speicherung von Klassen, die vom Klassenladeprogramm des Bootprogramms in den Cache für gemeinsam genutzte Klassen geladen wurden. Kann mit der Anwendungsprogrammierschnittstelle SharedClassURLFilter verwendet werden, um präzise zu steuern, welche Klassen zwischengespeichert werden. Weitere Informationen zum Filtern von gemeinsam genutzten Klassen finden Sie im Handbuch Diagnostics Guide.
|cacheRetransformed
|Inaktiviert das Caching von Klassen, die mit Hilfe der JVMTI-Funktion RetransformClasses umgesetzt wurden.
|noaot
|Inaktiviert das Caching und Laden von AOT-Code.

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

Eine Übersicht über den Lebenszyklus eines Caches mit gemeinsam genutzten Klassendaten, einschließlich Beispielen für die Dienstprogramme zur Cacheverwaltung.

Zum Aktivieren der gemeinsamen Nutzung von Klassendaten müssen Sie die Angabe -Xshareclasses[:name=<Name>] in der Befehlszeile Ihrer Anwendung hinzufügen.

JVM 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 JVMs 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-JVM oder in einem anderen Befehlsfenster ausgeführt werden.)

Verwenden Sie die Unteroption verbose, um mehr Rückmeldungen zur Cachebelegung zu erhalten, während JVM ausgeführt wird. Beispielsweise java -Xshareclasses:[name=<Name>],verbose.

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>],verboseIO hinzu.

Zum Löschen des zuvor erstellten Caches führen Sie den Befehl java -Xshareclasses:[name=<Name>],destroy 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 JVM 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 JVMs 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 JVMs angezeigt, die die Unteroption 'verbose' verwenden. Alle JVMs, die den vollen Cache gemeinsam nutzen, laden dann alle weiteren 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 Klassendaten empfiehlt sich insbesondere auf Systemen, auf denen mit mehreren JVMs 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 JVMs 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. Der JVM-Startvorgang für eine einzige JVM ist abhängig von der Anzahl der geladenen Klassen im Vergleich zu einem System, das nicht die gemeinsame Nutzung von Klassendaten verwendet, in der Regel zwischen 0 und 5 % länger. Die Zeiteinsparung beim JVM-Startvorgang mit einem gefüllten Cache ist abhängig vom Betriebssystem und der Anzahl der geladenen Klassen im Vergleich zu einem System, das nicht die gemeinsame Nutzung von Klassendaten verwendet, in der Regel 10 % bis 20 % kürzer. Bei mehreren gleichzeitig ablaufenden JVMs ergeben sich größere Verkürzungen bei der Startzeit.

Doppelte Klassen werden innerhalb des Caches für gemeinsam genutzte Klassen konsolidiert. Die aus MeineKlassen.jar geladene Klasse A z. B. und die aus MeineAnderenKlassen.jar geladene Klasse B (mit identischem Inhalt) wird im Cache nur einmal gespeichert. Das Dienstprogramm printAllStats zeigt für doppelte Klassen mehrere Einträge an, wobei jeder Eintrag auf dieselbe Klasse verweist.

Wenn bei der Ausführung Ihrer Anwendung die gemeinsame Nutzung von Klassendaten aktiviert ist, können Sie mit Hilfe von Betriebssystemtools die Verringerung der virtuellen Speicherbelegung anzeigen.

Besondere Aspekte und Einschränkungen bei der gemeinsamen Nutzung von Klassendaten

Faktoren, die beim Implementieren der gemeinsamen Nutzung von Klassendaten in einem Produkt und beim Verwenden von Klassendaten in einer Entwicklungsumgebung zu berücksichtigen sind.

Grenzwerte für die Cachegröße

Die maximale theoretische Cachegröße beträgt 2 GB. Die Cachegröße, die Sie angeben können, wird durch die Größe des auf dem System verfügbaren physischen Speichers und des Umlagerungspeichers begrenzt.

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

Da der virtuelle Adressraum eines Prozesses vom Cache für gemeinsam genutzte Klassen und dem Java-Freispeicher gemeinsam genutzt wird, kann sich bei Erhöhung der maximalen Größe des Java-Freispeichers die Größe des Caches für gemeinsam genutzte Klassen verringern, 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

Jede JVM, die einen JVMTI-Agenten (JVM Tool Interface) verwendet, der Bytecode ändern kann, sollte die Unteroption 'modified=<Geänderter Kontext>' verwenden, um die geänderten Klassen mit einer anderen JVM gemeinsam zu nutzen.

Bei dem geänderten Kontext handelt es sich um einen benutzerdefinierten Deskriptor, der die Art der durchgeführten Änderung beschreibt. Der geänderte Kontext partioniert den Cache, so dass alle im selben Kontext aktiven JVMs eine Partition gemeinsam nutzen.

Diese Partionierung ermöglicht JVMs, die keinen geänderten Bytecode verwenden, die sichere gemeinsame Nutzung eines Caches mit denjenigen, die geänderten Bytecode verwenden. Alle JVMs, 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 JVM geladen werden. Jede Änderung muss berechenbar sein, weil Klassen, die aus dem Cache für gemeinsam genutzte Klassen geladen wurden, nicht über den Agenten erneut geändert werden können.

Wenn ein JVMTI-Agent ohne einen Änderungskontext verwendet wird, werden die Klassen von JVM immer noch sicher gemeinsam genutzt, doch es ergeben sich geringe Auswirkungen auf die Leistung. Die Verwendung eines Änderungskontextes mit einem JVMTI-Agenten macht zusätzliche Überprüfungen überflüssig und hat daher keinen Einfluss auf die Leistung. Ein benutzerdefinierter ClassLoader, der java.net.URLClassLoader erweitert und während der Ladezeit Bytecode verändert, ohne die JVMTI zu verwenden, speichert den geänderten Bytecode automatisch im Cache, doch der Cache behandelt den Bytecode nicht als geänderten Bytecode. Jede andere virtuelle Maschine, die diesen Cache gemeinsam nutzt, lädt die geänderten Klassen. Die Unteroption 'modified=<Änderungskontext>' kann auf dieselbe Weise wie mit JVMTI-Agenten zur Partitionierung von geändertem Bytecode im Cache verwendet werden. Wenn ein benutzerdefinierter ClassLoader unvorhersehbare Änderungen an Klassen während der Ladezeit ausführen muss, darf dieser ClassLoader nicht versuchen, Klassendaten gemeinsam zu nutzen.

Weitere Informationen hierzu finden Sie im Handbuch Diagnostics Guide.

Betriebssystemeinschränkungen

Die gemeinsame Nutzung von Klassen ist zwischen 32- and 64-Bit-JVMs nicht möglich. Für die Cachedaten muss temporärer Plattenspeicherplatz verfügbar sein. Die Cacheberechtigungen werden vom Betriebssystem umgesetzt.

Bei Betriebssystemen, die sowohl 32-Bit-Anwendungen als auch 64-Bit-Anwendungen ausführen können, ist die gemeinsame Nutzung von Klassendaten zwischen JVMs mit 32 Bit und 64 Bit nicht zulässig. Die Unteroption listAllCaches listet je nach Adressmodus der verwendeten JVM 32-Bit- oder 64-Bit-Caches auf.

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 JVM die gemeinsam genutzten Klassen auf dem System nicht identifizieren und muss den Cache erneut erstellen. Mit dem Befehl ipcs können Sie die von JVM 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 'SharedClassPermissions'

Wenn ein SecurityManager mit der gemeinsamen Nutzung von Klassendaten 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 ClassLoader-Klassennamens (Platzhalterzeichen sind zulässig) und entweder "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 ClassLoader nicht die korrekten Berechtigungen hat, kann er keine Klassen gemeinsam nutzen. Sie können die Berechtigungen der Klassenladeprogramme für das Standardbootprogramm, für Anwendungen oder Erweiterungen nicht ändern.

Anpassen benutzerdefinierter Klassenladeprogramme an gemeinsam genutzte Klassen

Klassenladeprogramme, die eine Erweiterung von java.net.URLClassLoader darstellen, können Klassen ohne Änderung gemeinsam nutzen. Klassenladeprogramme, die keine Erweiterung von java.net.URLClassLoader darstellen, müssen für die gemeinsame Nutzung von Klassendaten angepasst werden.

Allen benutzerdefinierten Klassenladeprogrammen müssen Berechtigungen zur gemeinsamen Nutzung von Klassen erteilt werden, wenn ein SecurityManager verwendet wird. Weitere Informationen hierzu finden Sie in Verwenden von 'SharedClassPermissions'. 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 dem SDK in der Datei docs/content/apidoc.zip mitgeliefert.

Weitere Informationen zur Verwendung dieser Schnittstellen finden Sie im Handbuch Diagnostics Guide.

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.

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 6 unterstützt.

Bei Verwendung der Java Communications API haben Sie folgende Möglichkeiten:

Installieren der Java Communications API aus einer komprimierten Datei

Stellen Sie vor der Installation der Java Communications API sicher, dass 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. Informationen zur Installation der Java Communications API über ein RPM-Paket finden Sie in Installieren der Java Communications API über eine RPM-Datei.

Gehen Sie wie folgt vor, um Java Communications API aus einer komprimierten Datei zu installieren:

  1. Stellen Sie die komprimierte Datei der Java Communications API, ibm-java-javacomm-3.0-0.0-<Plattform>-<Architektur>.tar.gz, in das Verzeichnis, in dem SDK oder Runtime Environment installiert ist. Falls Sie bei der Installation das Standardverzeichnis verwendet haben, handelt es sich hierbei um /opt/ibm/java-i386-60/.
  2. Extrahieren Sie diese Datei über eine Shelleingabeaufforderung in dem Verzeichnis, in dem die komprimierte Datei enthalten ist:
    tar -xvzf ibm-java-javacomm-3.0-0.0-<Plattform>-<Architektur>.tar.gz

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

  3. |Kopieren Sie die javacomm-Dateien in die korrekten Verzeichnisse in Ihrem SDK. | |
      |
    1. Kopieren Sie lib/libLinuxSerialParallel.so in Ihr Verzeichnis jre/bin/.
    2. |
    3. Kopieren Sie jar/comm.jar in Ihr Verzeichnis |jre/lib/ext/.
    4. |
    5. Kopieren Sie lib/javax.comm.properties in Ihr Verzeichnis |jre/lib/.
    Das SDK ist standardmäßig im Verzeichnis /opt/ibm/java-i386-60/ installiert.

Installieren der Java Communications API über eine RPM-Datei

Stellen Sie vor der Installation der Java Communications API sicher, 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.

  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-javacomm-3.0-0.0.<Architektur>.rpm
    Die Java Communications API wird in der Verzeichnisstruktur /opt/ibm/java-i386-60/ installiert.
  3. |Kopieren Sie die javacomm-Dateien in die korrekten Verzeichnisse in Ihrem SDK. | |
      |
    1. Kopieren Sie lib/libLinuxSerialParallel.so in Ihr Verzeichnis jre/bin/.
    2. |
    3. Kopieren Sie jar/comm.jar in Ihr Verzeichnis |jre/lib/ext/.
    4. |
    5. Kopieren Sie lib/javax.comm.properties in Ihr Verzeichnis |jre/lib/.
    Das SDK ist standardmäßig im Verzeichnis /opt/ibm/java-i386-60/ installiert.

Speicherposition der Java Communications API-Dateien

Java Communications API-Dateien sind standardmäßig im Verzeichnis /opt/ibm/java-i386-60/ installiert. Die Dateien und ihre Struktur sind wie folgt:

Konfigurieren der Java Communications API

Sie müssen zur Verwendung der Java Communications API den Zugriffsmodus des seriellen Anschlusses und des Parallelanschlusses ändern und PATH setzen, wenn Sie dies nicht bereits bei der Installation von Java getan haben.

Siehe Festlegen des Pfads.

Ä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- und Lesezugriff auf die erforderlichen Einheiten einräumen. Melden Sie sich dazu als Root an, und verwenden Sie einen der folgenden Befehle:

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

Fügen Sie bestimmte Benutzer zu der Gruppe hinzu, in der sich die Einheiten befinden. Auf einem SUSE-System befinden sich die Einheiten z. B. in der Gruppe uucp. Auf diese Weise können der Gruppe uucp Benutzer hinzugefügt werden, um Zugriff auf die Einheiten zu erhalten.

Ä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 und 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 Ihr System 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)

Deinstallieren der Java Communications API mit Hilfe des RPM-Pakets.

  1. Verwenden Sie das Tool 'rpm' zum Deinstallieren des Pakets. Geben Sie den folgenden Befehl an einer Shelleingabeaufforderung ein:
    rpm -e ibm-javacomm-3.0-0.0
    Sie können auch ein grafisches Tool verwenden, wie beispielsweise kpackage oder yast2.
  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.
  3. |Falls Sie die javacomm-Bibliotheken in das SDK-Verzeichnis kopiert haben, löschen Sie folgende Dateien aus dem SDK-Verzeichnis. | |
      |
    • jre/bin/libLinuxSerialParallel.so
    • |
    • jre/lib/ext/comm.jar
    • |
    • jre/lib/javax.comm.properties
    Das SDK ist standardmäßig im Verzeichnis /opt/ibm/java-i386-60/ installiert.

Deinstallieren des komprimierten TAR-Pakets (Tape Archive)

Deinstallieren der Java Communications API, falls Sie das komprimierte TAR-Paket installiert haben.

Löschen Sie die folgenden Dateien aus dem Verzeichnis, in dem sie installiert wurden:

Dokumentation zur Java Communications API

Dokumentation zu APIs und Beispiele zur Java Communications API finden Sie auf der Sun-Website.

http://java.sun.com/products/javacomm/.

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

Kontaktpunkte für Service:

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.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 zu SDK und Runtime Environment wurden mit Sprachausgabeprogrammen getestet.

Verwenden Sie zum Ändern der Schriftgrößen in den Benutzerhandbüchern die Funktion, die in Ihrem Browser enthalten ist. Sie finden diese Funktion in der Regel im Menü Ansicht.

Benutzer, die über die Tastatur navigieren müssen, finden unter Swing Key Bindings (http://www.ibm.com/developerworks/java/jdk/additional/) eine Beschreibung von nützlichen Tastaturangaben für Swing-Anwendungen.

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 der JComboBox erst dann geändert werden, wenn ein Element ausgewählt wird. Mit diesem für dieses Release korrekten Verhalten verbessern sich Eingabehilfen und Benutzerfreundlichkeit, da sichergestellt wird, dass das Verschieben des Eingabefokus per Tastatur dem Verschieben des Eingabefokus per Maus entspricht.

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

In Java Web Start sind ab Version 5.0 die Eingabehilfen und die Benutzerfreundlichkeit verbessert worden. 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.

Kommentare zu diesem Handbuch

Wenn Sie Kommentare zu diesem Benutzerhandbuch abgeben möchten, kontaktieren Sie uns auf einem der folgenden Mitteilungswege. Beachten Sie, dass diese Mitteilungswege nicht eingerichtet wurden, um technische Fragen zu beantworten. Sie sind nur für Kommentare zur Dokumentation bestimmt.

Senden Sie Ihre Kommentare an folgende Adresse:

Das Kleingedruckte. Wenn Sie eine Nachricht an IBM senden, erklären Sie sich einverstanden, dass alle in Ihrer Nachricht enthaltenen Informationen, einschließlich der Rückmeldedaten, wie beispielsweise Fragen, Kommentare, Anregungen o. Ä., nicht vertraulich behandelt werden und dass IBM keinerlei Verpflichtungen in Bezug auf diese Informationen hat und diese uneingeschränkt abdrucken, verwenden, veröffentlichen und an andere weitergeben kann. Des Weiteren kann IBM in diesen Informationen enthaltene Ideen, Konzepte oder Angaben zu Know-how oder technischen Verfahren uneingeschränkt und für beliebige Zwecke verwenden, u. a. für die Entwicklung, die Produktion und das Marketing von Produkten, die diese Informationen enthalten.

Anhang A. 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 einen 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 nachstellen.

In Optionen, die einen Parameter <Prozentsatz> verwenden, sollten Sie eine Zahl von 0 bis 1 verwenden. Beispiel: '50 %' ist '0,5'.

-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 Runtime Environment-Binärcodelizenz verstößt. Standardmäßig wird in den internen VM-Verzeichnissen und JAR-Dateien nach Bootklassen und -ressourcen gesucht.
|-Xcheck:classpath
|Zeigt eine Warnung an, wenn im Klassenpfad ein Fehler aufgespürt wurde, z. B. ein fehlendes Verzeichnis oder eine fehlende JAR-Datei.
-Xcheck:gc[:<Suchoptionen >][:<Prüfoptionen >][:<Sonstige Optionen>]
Führt zusätzliche Prüfungen für die Garbage-Collection aus. Standardmäßig wird keine Prüfung ausgeführt. Weitere Informationen finden Sie in der Ausgabe von -Xcheck:gc:help.
-Xcheck:jni
Führt zusätzliche Prüfungen für JNI-Funktionen aus. Standardmäßig wird keine Prüfung ausgeführt.
|-Xcheck:memory[:<Option>]
Identifiziert Speicherverluste innerhalb von JVM mit Hilfe von genauen Prüfungen, die dazu führen, dass JVM mit einem Fehler beendet wird. Wenn keine Option angegeben wird, wird standardmäßig all verwendet. Weitere Informationen finden Sie in der Ausgabe von -Xcheck:memory:help oder im Handbuch Diagnostics Guide.
-Xcheck:nabounds
Führt zusätzliche Prüfungen für JNI-Funktionen aus. Standardmäßig wird keine Prüfung ausgeführt.
-Xclassgc
Aktiviert die Erfassung von Klassenobjekten bei jeder Garbage-Collection. Siehe auch -Xnoclassgc. Diese Option ist standardmäßig aktiviert.
-Xcodecache<Größe>
Legt die Größe der Einheit fest, bei der Hauptspeicherblocks zugeordnet werden, so dass sie nativen Code von kompilierten Java-Methoden speichern. Für die jeweils ausgeführte Anwendung kann eine entsprechende Größe ausgewählt werden. Dies ist standardmäßig intern ausgewählt, je nach der CPU-Architektur und der Funktionalität Ihres Systems.
-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
Führt eine Komprimierung für jede Garbage-Collection aus. 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<Anzahl>
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 (Large Object Area (LOA) oder Small Object Area (SOA)) die Belegung gemessen wird, und folglich, welche Zuordnungen während der gleichzeitigen Markierung belastet werden. Die Zuordnungsauslastung wird auf den ausgewählten Bereich angewendet. Wenn -Xconmeter:dynamic angegeben ist, legt der Collector den zu messenden Bereich dynamisch fest, basierend darauf, welcher Bereich 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. Weitere Informationen hierzu finden Sie in Debugging in Java-Anwendungen. Die Angabe eines Werts für -Xrunjdwp stellt dieselbe Unterstützung bereit.
-Xdebug
Startet JVM mit aktiviertem Debugger. Der Debugger ist standardmäßig inaktiviert.
-Xdisableexcessivegc
Inaktiviert die Auslösung der Ausnahmebedingung OutOfMemoryError, 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 OutOfMemoryError ausgelöst wird. Diese Aktion tritt nur auf, wenn der Freispeicher vollständig ausgelastet ist, und die Garbage-Collection 95 % der benötigten Zeit in Anspruch nimmt. Dies ist das Standardverhalten.
-Xenableexplicitgc
Signalisiert VM, dass Aufrufe an System.gc() eine Garbage-Collection auslösen sollen. Dies ist der Standardwert.
-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. Weitere Informationen hierzu finden Sie in Optionen der Garbage-Collection.
-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 dies 2 KB. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
|-Xjarversion
|Siehe |hierzu den Abschnitt Erhalten von Versionsinformationen.
-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
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<Prozentsatz>
<Prozentsatz> 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<Prozentsatz>
<Prozentsatz> 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 den Abschnitt 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<Prozentsatz>
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. 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 KB. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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 KB. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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 auf mindestens 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<Prozentsatz>
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. Standardmäßig lautet der Mindestwert 0,3 (30 %).
-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. Die Definition von -Xmn 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. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade 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. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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.
-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. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-Xmrx<Größe>
Definiert die gespeicherte maximale Größeneinstellung.
-Xms<Größe>
Definiert die Anfangsgröße des Java-Freispeichers. Sie können auch die Option -Xmo. verwenden. Der Standardwert wird intern entsprechend der Funktionalität Ihres Systems definiert. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-Xmso<Größe>
Definiert die C-Stackgröße für verzweigte Java-Threads. Die Standardeinstellung für diese Option lautet 32 KB auf 32-Bit-Plattformen und 256 KB auf 64-Bit-Plattformen. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-Xmx<Größe>
Definiert die Maximalgröße des Java-Freispeichers. Die Standardeinstellung für diese Option wird intern entsprechend der Funktionalität Ihres Systems definiert. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-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. Siehe auch -Xclassgc. Standardmäßig wird eine Garbage-Collection für Klassen ausgeführt.
-Xnocompactexplicitgc
Inaktiviert die Komprimierung beim Aufruf an System.gc(). Siehe auch -Xcompactexplicitgc. Die Komprimierung ist bei Aufrufen an System.gc() standardmäßig aktiviert.
-Xnocompactgc
Inaktiviert die Komprimierung für den Garbage-Collector. Siehe auch -Xcompactgc. Die Komprimierung ist 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
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.
-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. Diese Option ist standardmäßig nicht definiert, somit werden alle Komprimierungen vollständig ausgeführt. 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. Weitere Informationen hierzu finden Sie in -Xdbg.
-Xrunjnichk[:help] | [:<Option>=<Wert>, ...]
Veraltet; verwenden Sie -Xcheck:jni.
-Xscmx<Größe>
Weitere Informationen zu -Xscmx finden Sie in Aktivieren und Konfigurieren der gemeinsamen Nutzung von Klassendaten.
-Xshareclasses:<Optionen>
Weitere Informationen zu den -Xshareclasses-Optionen finden Sie in Aktivieren und Konfigurieren der gemeinsamen Nutzung von Klassendaten.
-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. Standardmäßig wird dieser Wert auf 256 KB gesetzt. Verwenden Sie die Option -verbose:sizes, um den Wert auszugeben, den VM gerade verwendet.
-Xthr:<Optionen>
Definiert die Threading-Optionen.
-Xverbosegclog:<Dateipfad>[X,Y]

Die Ausgabe der ausführlichen Garbage-Collection (GC) 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 Ausgabe der ausführlichen Garbage-Collection an X Dateien umgeleitet, von denen jede Y gc-Zyklen mit Ausgaben von ausführlichen Garbage-Collections enthält. Diese Dateien weisen folgendes Format auf: Dateiname1, Dateiname2 usw. Die Protokollierung der ausführlichen GC wird nicht standardmäßig durchgeführt.

Weitere Informationen zur Ausgabe der ausführlichen GC finden Sie im Handbuch Diagnostics Guide.

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

Anhang B. Bekannte Einschränkungen

Hier werden bekannte Einschränkungen für SDK und Runtime Environment for Linux erläutert.

Weitere Hilfestellungen zur Problemdiagnose finden Sie im Diagnostics Guide unter http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.

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.

Indexzunge 'Local' des Überwachungstools JConsole

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. Außerdem wird die entsprechende Befehlszeilenoption pid nicht unterstützt. Verwenden Sie stattdessen die Indexzunge Remote in JConsole, um eine Verbindung zu der virtuellen Maschine herzustellen, die Sie überwachen wollen. Verwenden Sie alternativ dazu die Befehlszeilenoption connection, indem Sie einen Host von localhost und eine Portnummer angeben. Legen Sie beim Starten der zu überwachenden Anwendung die folgenden Befehlszeilenoptionen fest:

-Dcom.sun.management.jmxremote.port=<Wert>
Gibt den Port an, an dem der Managementagent empfangsbereit sein sollte.
-Dcom.sun.management.jmxremote.authenticate=false
Inaktiviert die Authentifizierung, sofern Sie keine Benutzernamendatei erstellt haben.
-Dcom.sun.management.jmxremote.ssl=false
Inaktiviert die SSL-Verschlüsselung.

Die JavaScript-Steuerkomponente Rhino ist nicht vorhanden

Auf Grund von Lizenzierungsproblemen umfasst IBM SDK for Java nicht die JavaScript-Steuerkomponente Mozilla Rhino. Laden Sie zum Verwenden der JavaScript-Steuerkomponente Rhino mit IBM SDK for Java die Steuerkomponente zur Scripterstellung jsr223 von https://scripting.dev.java.net/ und die JavaScript-Steuerkomponente Rhino von der Mozilla-Website http://www.mozilla.org/rhino/ herunter.

Erstellen von DSA-Schlüsselpaaren

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.

Erstellen von JVM mit Hilfe von JNI (Java Native Interface)

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:

Bei der erstellten VM handelt es sich um diejenige, die über die vorhandenen Java-Bibliotheken festgelegt wird (d. h. 1.2.2, 1.3.x, 1.4.x, 5.x, 6.x) 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.

Fenstermanager und Tastaturkurzbefehle

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

Dateideskriptoren von X Window System

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.

DBCS-Daten und die KDE-Zwischenablage

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.

Begrenzung für Threads, die die Bibliothek LinuxThreads verwenden

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

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

Begrenzung der Benutzer-CPU-Zeit für den Thread ThreadMXBean

Auf dieser Plattform gibt es keine Möglichkeit, zwischen Benutzer-CPU-Zeit und System-CPU-Zeit zu unterscheiden. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() und ThreadMXBean.getCurrentThreadCpuTime() geben alle die gesamte CPU-Zeit für den erforderlichen Thread zurück.

KeyEvents und Fenstermanager

Die Ergebnisse von KeyEvent mit der Taste Alt können bei Verwendung unterschiedlicher Fenstermanager unter Linux voneinander abweichen. Sie weichen auch von Ergebnissen anderer Betriebssysteme ab. Bei der Verwendung der Standardeinstellungen wird durch Strg+Alt+A im KWin-Fenstermanager ein KeyEvent erstellt, während durch Strg+Alt+A im Metacity-Fenstermanager keine Tastenkombination erstellt wird.

X Window System und die Taste 'Meta'

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"  

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

Signal SIGSEGV beim Erstellen von JVM mit Hilfe von JNI (Java Native Interface)

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.

Ressourcenmangel bei Anwendungen mit vielen Threads

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:

Versuchen Sie, Ihr System dahingehend zu optimieren, dass die entsprechenden Systemressourcen erhöht werden.

Probleme zwischen den Schriftarten auf dem X-Server und dem X-Client

Wenn Sie eine Java AWT- oder 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. Installieren Sie zur Vermeidung dieses Fehlers auf beiden Maschinen dieselben Schriftarten.

UTF-8-Verschlüsselung und die Ausnahmebedingungen 'MalformedInputException'

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 erhalten, ä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".

Probleme mit AMI und 'xcin' beim Exportieren von Anzeigen

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. Führen Sie ein Upgrade auf die neueste Version von AMI und 'xcin' durch, wenn dies der Fall ist.

RHEL4 und XIM

Nur für Benutzer der Version von RHEL4 in Chinesisch, Koreanisch und Japanisch.

Standardmäßig ist kein XIM-Server installiert. Installieren Sie zum Eingeben von Doppelbytezeichen in eine Java-Anwendung ein X-Server-Paket, wie z. B. 'iiimf-x' oder 'kinput2'.

RHEL4 und IIIMF

Nur für Benutzer der Version von RHEL4 in Chinesisch, Koreanisch und Japanisch.

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. Wenden Sie sich an Red Hat unter http://www.redhat.com, um Hilfe zu erhalten.

(Nur zSeries 64 Bit) Es können IIIMF-Fehler oder Startfehler auftreten. Führen Sie zur Behebung des Problems ein Upgrade auf die neuesten IIIMF-Pakete durch.

(Nur traditionelles Chinesisch auf PPC, s390 oder s390x) IIIMF funktioniert möglicherweise nicht. Verwenden Sie zur Behebung des Problems iiimf-le-xcin-0.1.7-13.EL4 oder neuer.

(Nur vereinfachtes Chinesisch auf PPC, s390 oder s390x) IIIMF funktioniert möglicherweise nicht ordnungsgemäß. Verwenden Sie zur Behebung des Problems die in RHEL4 Update 5 oder neuer enthaltenen Pakete.

RHEL4 und die Ländereinstellung 'zh_CN.GB18030'

Nur für Benutzer der Version von RHEL4 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.

Diese Einschränkung wird in RHEL4 U3 behoben.

RHEL4 und 'xcin'

Bei xcin unter RHEL4 treten möglicherweise Blockierungen auf. Setzen Sie zur Behebung des Problems ICCHECK_DISABLE in der Datei /etc/chinese/xcin/xcinrc auf 'YES'.

Nur 64-Bit-Umgebungen

Unter RHEL4 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. Führen Sie zur Behebung des Problems ein Upgrade auf das neueste xcin-Paket durch.

Probleme mit der Fokusänderung bei RHEL4 und IIIMF

Nur RHEL4.

Bei der Verwendung von IIIMF (Internet Intranet Input Method Framework) für die Eingabe von Doppelbytezeichen kommen möglicherweise Probleme mit der Fokusänderung vor. Das Problem tritt auf, wenn aktive Eingabekomponenten minimiert werden. Nach dem Wiederherstellen der Komponente wechselt die Eingabemethode zurück zu SBCS (SBCS - Single Byte Character Set, Einzelbytezeichensatz). DBCS (DBCS - Double Byte Character Set, Doppelbytezeichensatz) muss dann manuell reaktiviert werden.

Bei den folgenden Komponenten tritt dieses Problem mit der Fokusänderung auf:

XIM und das Java Plug-in

RHEL4 und SLES9

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 umgehen 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 Apply an.
  5. Starten Sie einen Browser.

Diese Einschränkung wird in RHEL4 U3 und SLES9 SP3 behoben.

Arabische Zeichen und Matrox-Videokarten

Nur Intel-32-Bit-Plattformen

(Für Benutzer von arabischem Text) Bei der Verwendung von Linux mit einer Matrox-Videokarte und aktivierter Beschleunigung werden Zeichen verzerrt angezeigt, 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.

Verwendung der NPTL unter SLES9 und der Parallelanschlusstreiber

Nur Intel-32-Bit-Plattformen

Bei Verwendung der NPTL unter SLES 9 verursacht der Parallelanschlusstreiber einen Kernelabsturz und stoppt einen Java-Thread. 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.

JNI-Aufrufe mit mindestens acht Parametern auf PPC-Plattformen

Nur PPC-Plattformen

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.

Parallelanschlussoperationen unter SLES9 vor SP2

Nur PPC-Plattformen

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.

Kompilieren von 'libFileStat.so' auf PPC-64-Bit-Plattformen

Nur PPC-64-Bit-Plattformen

Der systemübergreifende gcc-Standardcompiler (Version 3.2-49) verursacht verschiedene Fehler. Führen Sie zum Erstellen der gemeinsam genutzten Bibliothek libFileStat.so Folgendes aus:

/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<SDK_PATH>/include FileStat.c

Dabei gilt Folgendes: <SDK_PATH> ist der Pfad zum installierten SDK-Verzeichnis.

IP Version 6 auf zSeries-Plattformen

Nur zSeries-Plattformen

Obwohl der Linux-Kernel in den aktuellen Verteilungen Unterstützung für Internet Protocol Version 6 (IPv6) bietet, treten bei der Verwendung möglicherweise Probleme auf. In diesem Release ist die Unterstützung für IP Version 6 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 IPv6 vollständig unterstützt, benötigen Sie diese Option nicht.

'xcin' auf 64-Bit-zSeries-Plattformen

Nur zSeries-64-Bit-Plattformen

Der chinesische und taiwanesische Input Method Server ('xcin') wurde nicht getestet.

Java Desktop API

Die Java Desktop API funktioniert möglicherweise nicht, weil mindestens eine GNOME-Bibliothek nicht verfügbar ist.

NullPointerException bei GTK-Darstellung und -Funktionsweise

Nur DBCS-Umgebungen

Wenn bei Ihrer Anwendung bei Verwendung der GTK-Darstellung und -Funktionsweise der Fehler NullPointerException auftritt, inaktivieren Sie die Umgebungsvariable GNOME_DESKTOP_SESSION_ID.

Aliasname der Codepage in Unicode für 'Shift_JIS'

Nur für Benutzer der japanischen Version

Der Aliasname der Codepage in Unicode "\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe" für Shift_JIS wurde entfernt. Wenn Sie diese Codepage in Ihren Anwendungen verwenden, ersetzen Sie sie durch 'Shift_JIS'.

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 Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim zuständigen 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 andere Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Fremdprodukten, Fremdprogrammen und Fremdservices liegt beim Kunden.

Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Handbuchs ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf Englisch formuliert werden):

Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen oder in Technical News Letters (TNLs) bekannt gegeben. IBM kann ohne weitere Mitteilung jederzeit Verbesserungen und/oder Änderungen an den in dieser Veröffentlichung beschriebenen Produkten und/oder Programmen vornehmen.

Verweise in diesen Informationen auf Websites anderer Anbieter werden lediglich als Service für den Kunden bereitgestellt und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.

Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.

Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:

Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.

Die Lieferung des im Dokument aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt auf der Basis der IBM Rahmenvereinbarung bzw. der Allgemeinen Geschäftsbedingungen von IBM, der IBM Internationalen Nutzungsbedingungen für Programmpakete oder einer äquivalenten Vereinbarung.

Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer kontrollierten 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 davon abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.

Informationen über Produkte anderer Anbieter wurden von den jeweiligen Anbietern 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 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 Marken oder eingetragene Marken der International Business Machines Corporation in den USA und/oder anderen Ländern.

Intel ist eine Marke der Intel Corporation in den USA und/oder anderen Ländern.

Java und alle auf Java basierenden Marken und Logos sind Marken von Sun Microsystems, Inc. in den USA und/oder anderen Ländern.

Linux ist eine Marke von Linus Torvalds in den USA und/oder anderen Ländern.

Andere Namen von Unternehmen, Produkten oder Dienstleistungen können Marken oder Dienstleistungsmarken anderer Unternehmen sein.