Vor Verwendung dieser Informationen und des darin beschriebenen Produkts sollten die Informationen unter Bemerkungen gelesen werden.
Diese Ausgabe des Benutzerhandbuchs bezieht sich auf IBM 64-bit SDK for Windows on AMD64/EM64T architecture, Java Technology Edition, Version 6 und auf alle nachfolgenden Releases, Änderungen und Serviceaktualisierungen bis zur Herausgabe neuer Dateiversionen.
(C) Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Alle Rechte vorbehalten.
In diesem Benutzerhandbuch erhalten Sie allgemeine Informationen zu IBM 64-bit SDK and Runtime Environment for Windows on AMD64/EM64T architecture, 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.
SDK and Runtime Environment werden unter folgenden Betriebssystemen 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).
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.
SDK umfasst Runtime Environment for Windows. Mit dieser Komponente können Sie nur Java-Anwendungen ausführen. Wenn Sie SDK installiert haben, ist auch Runtime Environment enthalten.
Runtime Environment enthält Java Virtual Machine sowie unterstützende Dateien, wie z. B. Klassendateien. Runtime Environment enthält nur eine Untergruppe der Klassen, die in SDK enthalten sind. Mit dieser Komponente können Sie ein Java-Programm während der Laufzeit verwenden; Sie haben jedoch nicht die Möglichkeit, Java-Programme zu kompilieren. Runtime Environment for Windows enthält kein Entwicklungstool, wie z. B. appletviewer.exe oder den Java-Compiler (javac.exe), bzw. keine Klassen, die nur für Entwicklungssysteme konzipiert sind.
Außerdem wird das Paket mit der Java Communications API zur Verwendung mit Runtime Environment for Windows bereitgestellt. Informationen hierzu finden Sie unter Verwenden der Java Communications API (JavaComm).
Normalerweise müssten alle Applets oder Anwendungen, die mit einer Vorversion von SDK ausgeführt wurden, zusammen mit IBM 64-bit SDK for Windows 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.
Ab Version 5.0 enthält IBM Runtime Environment for Windows 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:
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 Windows 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.
Eine Liste von Klassen und Tools, die Sie mit der Standardversion von Runtime Environment verwenden können.
Eine Liste von Tools und Referenzinformationen, die zum Lieferumfang der Standardversion des SDK gehört.
Die Lizenzdatei C:\Programme\IBM\Java60\docs\content\<Ländereinstellung>\LA_<Ländereinstellung> enthält die Lizenzvereinbarung für die SDK for Windows-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.
Verwenden Sie den Installationsassistenten oder die komprimierte Datei, um das SDK zu installieren. Konfigurieren Sie das SDK mit Hilfe der Umgebungsvariablen, der Befehlszeilenoptionen und der Merkmaldateien.
Laden Sie zum Installieren des SDK- oder Runtime Environment-Pakets das entsprechende Installationspaket herunter. Stellen Sie sicher, dass Sie beim Download alle Pakete in dasselbe Verzeichnis übertragen und dass in Ihrem temporären Verzeichnis ausreichend Speicherplatz vorhanden ist.
Die Pakete und die zugehörigen Dateinamen sind in Installieren der Pakete aufgelistet. Sie dürfen die Dateinamen der Pakete nicht ändern.
Stellen Sie vor dem Beginn der Installation sicher, dass im Verzeichnis C:\WINDOWS\TEMP genügend Speicherplatz für die Installation zur Verfügung steht. Während der Installation wird im Verzeichnis TEMP der folgende temporäre Speicherplatz benötigt:
Wenn nicht genügend temporärer Speicherplatz zur Verfügung steht, zeigt das Installationsprogramm einen Fehler an, und die Installation wird beendet. Wenn Ihr System über genügend temporären Speicherplatz verfügt, diese Nachricht jedoch weiterhin angezeigt wird, prüfen Sie, ob die Pakete, die Sie installieren wollen, vollständig heruntergeladen wurden. Dies ist durch Vergleichen der Dateigrößen Ihrer Pakete und der auf den Webseiten angezeigten Dateigrößen möglich, von denen Sie die Pakete heruntergeladen haben.
Das Produkt umfasst mehrere Pakete, die Sie separat installieren können, einschließlich SDK, Runtime Environment, Javacomm, Dokumentation und Demos.
Sie können die folgenden Pakete installieren:
Andere Pakete werden als komprimierte Pakete bereitgestellt:
Falls Sie das SDK oder Runtime Environment über das komprimierte Paket installieren, können Sie Web Start oder das Java Plug-in nicht verwenden, und in der Steuerkonsole wird eine Indexzunge Update angezeigt, die jedoch nicht funktioniert.
Verwenden Sie die beaufsichtigte Installation, um das SDK oder JRE auf einem einzelnen Client zu installieren.
Runtime Environment wird standardmäßig im Verzeichnis C:\Programme\IBM\Java60\jre installiert.
Falls Sie das installierbare SDK-Paket heruntergeladen haben, können Sie die zu installierenden Komponenten auswählen:
Im Installationsassistenten werden folgende Optionen angezeigt:
Unter Windows Vista kann nach Auswahl der Installationssprache eine Verzögerung auftreten.
Schlägt die Installation mit der Fehlernachricht "Error applying transform" fehl, wurden die Konfigurationsdaten von Windows Installer beschädigt. Verwenden Sie zum Beheben dieses Fehlers das Dienstprogramm Windows Installer Clean up unter http://support.microsoft.com/kb/290301, um die beschädigten Konfigurationsdaten von Windows Installer zu entfernen.
Wenn Sie Runtime Environment (entweder als Teil des installierbaren SDK-Pakets oder über das installierbare Runtime Environment-Paket) installieren, werden Sie gefragt, ob Sie Runtime Environment als Java Virtual Machine (JVM) des Systems installieren wollen. Installieren Sie Runtime Environment als System-JVM, kopiert das Installationsprogramm die Startprogramme java.exe, javacpl.cpl, javaws.exe und javaw.exe in das Windows-Systemverzeichnis.
Wenn im Windows-Systemverzeichnis derzeit bereits eine Version von java.exe oder javaw.exe enthalten ist, werden Sie aufgefordert, die vorhandene Version mit der aktuellen Version zu überschreiben. Durch das Installieren dieser Dateien in das Windows-Systemverzeichnis wird diese Runtime Environment die Standard-JVM für das System. Außerdem wird der Registrierungsschlüssel "Current Version" (aktuelle Version) so gesetzt, dass er dieser Installation entspricht.
Verwenden Sie die unbeaufsichtigte Installation, um das SDK oder JRE auf mehreren Clients zu installieren.
Zum Erstellen einer unbeaufsichtigten Installation müssen Sie zuerst eine beaufsichtigte Installation ausführen und eine Antwortdatei (setup.iss) erstellen, in der die Auswahlen aufgezeichnet werden, die Sie während der Installation treffen. Die Antwortdatei muss für die Computer, auf denen sie verwendet werden soll, ordnungsgemäß erstellt werden. Erstellen Sie gegebenenfalls mehrere Antwortdateien, die zum Installieren der Pakete auf Computern mit unterschiedlichen Konfigurationen verwendet werden können.
Wenn Sie während der Installation eine Antwortdatei erstellen wollen, geben Sie Folgendes an einer Eingabeaufforderung ein:
ibm-java-sdk-60-win-x86_64 /r
oder
ibm-java-jre-60-win-x86_64 /r
Abhängig von Ihrem Windows-Produkt wird eine Antwortdatei (setup.iss) im Verzeichnis C:\Windows oder C:\Winnt erstellt.
Während einer interaktiven Installation wird möglicherweise folgende Nachricht angezeigt:
Eine andere Version von Java Runtime Environment ist momentan als System-JVM installiert. Wollen Sie die vorige System-JVM mit dieser JRE-Version überschreiben?
Wenn diese Nachricht angezeigt wird, klicken Sie Nein an, und verlassen Sie die Installation. Wechseln Sie in das Windows-Systemverzeichnis und löschen Sie die folgenden zwei Dateien:
Nachdem Sie die Dateien gelöscht haben, starten Sie die interaktive Installation erneut mit dem oben aufgeführten Befehl.
Kopieren Sie auf dem System, auf dem Sie die unbeaufsichtigte Installation ausführen wollen, die Antwortdatei setup.iss in das Verzeichnis C:\Windows. Nachdem Sie die Datei kopiert haben, geben Sie Folgendes an einer Eingabeaufforderung ein:
ibm-java-sdk-60-win-x86_64 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java-jre-60-win-x86_64 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Wenn die Installation erfolgreich durchgeführt wurde, enthält die Protokolldatei die Zeichenfolge ResultCode=0. Wenn die Installation nicht erfolgreich durchgeführt wurde, enthält die Protokolldatei einen anderen Ergebniscode.
IBM Accessibility Bridge ist zwar installiert, standardmäßig aber deaktiviert. Entfernen Sie zum Aktivieren von IBM Accessibility Bridge das Kommentarzeichen für den Eintrag assistive_technologies in der Datei Accessibility.properties.
Die Datei Accessibility.properties befindet sich im Verzeichnis jre/lib. Löschen Sie das # am Anfang der folgenden Zeile:
#assistive_technologies=JawBridge
Die folgende Website enthält weitere Informationen zu den Accessibility Utilities:
http://java.sun.com/products/jfc/accessibility.html
Sie können die Java Accessibility-Unterstützung inaktivieren, um die JVM-Ladeleistung von Java-Anwendungen zu verbessern, die keine Unterstützung für die Java-Technologie für behindertengerechte Bedienung bereitstellen, insbesondere bei Netzwerk-Links. Setzen Sie zum Inaktivieren der Java Accessibility-Unterstützung die Umgebungsvariable JAVA_ASSISTIVE auf OFF.
Eine Technologie für behindertengerechte Bedienung wie z. B. JawBridge ist nicht verfügbar, wenn diese Umgebungsvariable auf OFF gesetzt ist. Dies gilt auch dann, wenn die Technologie in der Datei Accessibility.properties aktiviert ist.
In Windows hat ein Prozess zwei Codepages: die ANSI- bzw. Windows-Codepage und die OEM- bzw. DOS-Codepage. Der Befehl javaw verwendet immer die ANSI-Codepage, sofern nicht das Systemmerkmal console.encoding gesetzt ist.
Das Befehlsfenster verwendet normalerweise die OEM-Codepage. Die Java-Konsolausgabe verwendet die Codepage des Befehlsfensters, über das Java gestartet wird. Der Befehl javaw verwendet dagegen immer die ANSI-Codepage. Sie geben die für die Konsolausgabe zu verwendende Codepage mit der Option -Dconsole.encoding im Startprogramm java oder javaw an. Mit der Option -Dconsole.encoding=Cp1252 geben Sie zum Beispiel an, dass die gesamte Konsolausgabe in der Codepage Windows ANSI Latin1 (1252) erfolgen soll.
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 Windows 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:
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
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 Eingabeaufforderung 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 Eingabeaufforderung ausgeführt werden.
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.
Eine kurze Übersicht über die Befehle java und javaw.
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.
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 ... ]
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.
java -versionSie werden Informationen sehen wie etwa:
Java Version "1.6.0-internal" Java(TM) SE Runtime Environment (Build 20070405_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows Vista amd64-64 jvmwa6460-20070326_12091 (JIT enabled) J9VM - 20070326_12091_LEdSMr JIT - dev_20070326_1800 GC - 20070319_AA)Die präzisen Daten der Builds und der 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:
|... |C:\Programme\IBM\Java60\jre\lib\ext\ibmpkcs11impl.jar VERSION: 1.0 build_20070125 |C:\Programme\IBM\Java60\jre\lib\ext\dtfjview.jar |C:\Programme\IBM\Java60\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.
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:
java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MeineJavaKlasse
set 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.
Die Definitionen für die Standardoptionen.
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.
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.
Verwenden Sie zum Festlegen einer Java-Klasse oder jar-Datei für das automatische Starten über Windows Explorer die Option Extras -> Ordneroptionen -> Dateitypen im Windows Explorer.
Sie können auch Folgendes an einer Eingabeaufforderung eingeben:
assoc .class=javaclass ftype javaclass=C:\Programme\IBM\Java60\jre\bin\java.exe''%l''%*'
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.
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.
set JAVA_COMPILER=NONESie können JAVA_COMPILER auch permanent über die grafische Benutzerschnittstelle festlegen. Öffnen Sie Systemsteuerung, wählen Sie System aus, zeigen Sie die Indexzunge Erweitert an, und wählen Sie Umgebungsvariablen aus.
java -Djava.compiler=NONE <Klasse>
java -Xint <Klasse>
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.
set JAVA_COMPILER=jitcSie können JAVA_COMPILER auch permanent über die grafische Benutzerschnittstelle festlegen. Öffnen Sie Systemsteuerung, wählen Sie System aus, zeigen Sie die Indexzunge Erweitert an, und wählen Sie Umgebungsvariablen aus. Wenn die Umgebungsvariable JAVA_COMPILER eine leere Zeichenfolge ist, bleibt der JIT-Compiler inaktiviert. Geben Sie zum Inaktivieren der Umgebungsvariablen Folgendes an der Eingabeaufforderung ein:
set JAVA_COMPILER=
java -Djava.compiler=jitc <Klasse>
java -Xjit <Klasse>
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 Eingabeaufforderung ein:
java -version
Wenn der JIT-Compiler derzeit nicht verwendet wird, wird folgende Nachricht angezeigt:
(JIT disabled)
Wenn der JIT-Compiler verwendet wird, wird folgende Nachricht angezeigt:
(JIT enabled)
Weitere Informationen zum JIT-Compiler finden Sie im Handbuch Diagnostics Guide.
Der Garbage-Collector verwaltet den von Java und von den Anwendungen verwendeten Speicher, die mit 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.
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:
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.
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.
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.
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.
| | |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:
|java -Djava.ext.dirs=C:\Programme\IBM\Java60\jre\lib\ext;C:\Programme\IBM\Java60\jre\lib\im <Klasse>
|
Wenn SDK oder Runtime Environment in einem anderen Verzeichnis installiert sind, ersetzen Sie C:\Programme\IBM\Java60\ durch das Verzeichnis, in dem SDK oder Runtime Environment installiert sind.
Das SDK für Windows 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.
| | |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.
|IBM SDK for Java enthält die folgenden XML-Bibliotheken.
|XML4J ist ein Validierungsparser mit Unterstützung für die folgenden Standards: |
|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 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.
|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: |
|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: |
|Die folgenden Service-Provider steuern die XML verarbeitenden Bibliotheken, die von Java verwendet werden: |
|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:
|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 | |
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.
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.
Die folgenden optionalen StAX-Features werden von |XL XP-J nicht unterstützt: |
|Die folgenden Merkmale werden von der javax.xml.stream.XMLInputFactory-Implementierung unterstützt. Sie werden unter XMLInputFactory Javadoc beschrieben.
| |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.
|Die folgenden Merkmale werden von der javax.xml.stream.XMLStreamReader-Implementierung unterstützt. Sie werden unter XMLStreamReader Javadoc beschrieben.
| |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.
|Die folgenden Merkmale werden von der javax.xml.stream.XMLOutputFactory-Implementierung unterstützt. Sie werden unter XMLOutputFactory Javadoc beschrieben.
| |Merkmalname | |Unterstützt | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Ja | |
Die folgenden Merkmale werden von der javax.xml.stream.XMLStreamWriter-Implementierung unterstützt. Sie werden unter XMLStreamWriter Javadoc beschrieben.
| |Merkmalname | |Unterstützt | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Ja | |
Die Merkmale bei XMLStreamWriter-Objekten sind schreibgeschützt.
| | |XL TXE-J ist eine XSLT-Bibliothek, die den Interpreter XSLT4J 2.7.8 und einen XSLT-Compiler umfasst.
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 | |
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.
| |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: |
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
oder
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
oder
|set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
Zur Fehlerbehebung in Java-Programmen können Sie den Java-Debugger (JDB) oder andere Debugger verwenden, die über die JPDA (Java Platform Debugger Architecture) kommunizieren, die in SDK for Windows enthalten ist.
Weitere Informationen zur Problemdiagnose unter Verwendung von Java finden Sie im Handbuch Diagnostics Guide.
Der Java-Debugger (JDB) ist in SDK for Windows enthalten. Dieser Debugger wird über den Befehl jdb aufgerufen. Er wird JVM über die JPDA zugeordnet.
Gehen Sie zur Fehlerbehebung in Java-Anwendungen wie folgt vor:
java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<Port> <Klasse>Daraufhin startet JVM. Vor dem Starten der Java-Anwendung wird die Ausführung jedoch ausgesetzt.
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:
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.
java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<Port> <Klasse>Daraufhin startet JVM. Vor dem Starten der Java-Anwendung wird die Ausführung jedoch ausgesetzt.
jdb -connect com.sun.jdi.SocketAttach:hostname=<Host>,port=<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:
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");
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.
Für ein extern erstelltes Signal (z. B. durch Drücken der Tastenkombination Strg-Untbr) wird für die Signalroutine ein neuer Thread erstellt. In diesem Fall führt die JVM-Signalroutine die Verarbeitung aus, und die Anwendungsroutine für dieses Signal wird aufgerufen, wenn für dieses Signal eine Anwendungsroutine installiert ist und Sie die Befehlszeilenoption -Xnosigchain nicht angegeben haben.
JVM führt für Signale bei Ausnahmebedingungen und für Fehlersignale eine der folgenden Aktionen aus:
Bei Interruptsignalen beginnt JVM ebenfalls eine Sequenz für einen kontrollierten Systemabschluss, der jedoch in diesem Fall wie eine normale Beendigung behandelt wird. Hierbei führt JVM die folgenden Aktionen aus:
Der Systemabschluss entspricht dem Systemabschluss, der über einen Aufruf der Java-Methode System.exit() eingeleitet wurde.
Weitere von JVM verwendete Signale werden für die interne Steuerung verwendet und führen nicht zur Beendigung von JVM. Das einzige wichtige Steuerungssignal ist SIGBREAK, durch das ein Java-Speicherauszug generiert wird.
Die Signaltypen sind 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:
Signalname | Signaltyp | Beschreibung | Inaktiviert durch -Xrs |
---|---|---|---|
SIGINT (2) | Interrupt | Interaktiver Abruf (Strg-C). JVM wird normal beendet. | Ja |
SIGTERM (15) | Interrupt | Beendigungsanforderung. JVM wird normal beendet. | Ja |
SIGBREAK | Steuerzeichen | Ein Unterbrechungssignal von einem Terminal. Standardmäßig wird dadurch ein Java-Speicherauszug ausgelöst. | Ja |
IBM JVM verwendet die Anwendungsprogrammierschnittstellen AddVectoredExceptionHandler() und SetConsoleCtrlHandler(). Diese werden mit -Xrs inaktiviert. -Xnosigchain wird unter Windows ingoriert.
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 2 (SIGINT) und 15 (SIGTERM) für JVM-Threads führen zur Beendigung von JVM. Daher sollte eine Anwendungssignalroutine bei diesen Signalen keine Wiederherstellung versuchen, es sei denn, JVM wird nicht mehr benötigt.
Runtime Environment enthält eine Signalverkettungsfunktion. Die Signalverkettung ermöglicht eine effizientere Interaktion von JVM mit nativem Code, der eigene Signalroutinen installiert.
Mit der Signalverkettungsfunktion kann eine Anwendung mit der gemeinsam benutzten Bibliothek jsig.dll verbunden werden und diese vor msvcrt.dll laden. Mit Hilfe der Bibliothek 'jsig.dll' wird sichergestellt, dass signal()-Aufrufe abgefangen werden, so dass die JVM-Signalroutinen nicht durch die zugehörigen Routinen ersetzt werden. Stattdessen werden die neuen Signalroutinen durch diese Aufrufe gesichert oder nach den durch JVM installierten Signalroutinen hinzugefügt. Wenn diese Signale zu einem späteren Zeit gesendet werden und nicht an JVM gerichtet sind, werden die vorinstallierten Signalroutinen aufgerufen.
Die Bibliothek libjsig.dll 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.
Die Umgebungsvariable JAVA_HOME muss auf die Speicherposition des SDK gesetzt werden. Beispiel: C:\Programme\IBM\Java60\.
Wenn Sie jsig.dll verwenden möchten, stellen Sie eine Verbindung von jsig.dll zu der Anwendung her, die JVM erstellt oder integriert.
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).
Ü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.
Sie können die Unterstützung für große Seiten auf Systemen aktivieren, die dies unterstützen. Starten Sie dazu Java unter Angabe der Option -Xlp.
Große Seiten werden in erster Linie verwendet, um Leistungssteigerungen in Anwendungen zu erzielen, die große Speichermengen zuordnen und häufig auf diesen Speicher zugreifen. Die Leistungssteigerungen durch die Verwendung großer Seiten werden hauptsächlich durch die geringe Anzahl Fehlschläge im Translation Lookaside Buffer (TLB) erzielt. Der TLB ordnet einen größeren Bereich an virtuellem Speicher zu, und daraus ergeben sich die Leistungssteigerungen.
Damit JVM große Seiten verwendet, muss auf Ihrem System eine ausreichende Anzahl zusammenhängender großer Seiten verfügbar sein. Sollte es nicht möglich sein, große Seiten zuzuordnen, selbst wenn genügend Seiten verfügbar sind, hängen die großen Seiten möglicherweise nicht zusammen.
Die Zuordnung großer Seiten ist nur möglich, wenn die lokale Administrationsrichtlinie für den JVM-Benutzer so konfiguriert ist, dass "Lock pages in memory" (Seiten im Speicher sperren) zulässig ist.
Java 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.
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.
Wie von der OMG (Object Management Group) im Dokument ptc/01-03-04 beschrieben, unterstützt SDK portierbare Abfangprozesse. Sie können dieses Dokument unter der folgenden Adresse abrufen:
http://www.omg.org/cgi-bin/doc?ptc/01-03-04
Portierbare Abfangprozesse sind Hooks in den ORB (Object Request Broker), über die ORB-Services den normalen Ausführungsablauf des ORBs unterbrechen können.
Wie von der OMG im Dokument ptc/00-08-07 beschrieben, unterstützt SDK den Interoperable Naming Service. Sie können dieses Dokument unter der folgenden Adresse abrufen:
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
Der Standardport, der vom Transient Name Server (Befehl tnameserv) verwendet wird, wenn der Parameter ORBInitialPort nicht angegeben ist, wurde von 900 in 2809 geändert. Dies ist die Portnummer, die zusammen mit der IANA (Internet Assigned Number Authority) für einen CORBA Naming Service registriert wird. Programme, die von dieser Standardeinstellung abhängig sind, müssen möglicherweise aktualisiert werden, um mit dieser Version arbeiten zu können.
Der Ausgangskontext, der vom Transient Name Server zurückgegeben wird, lautet jetzt org.omg.CosNaming.NamingContextExt. Bereits vorhandene Programme, die den Verweis auf den Kontext org.omg.CosNaming.NamingContext eingrenzen, funktionieren weiterhin und müssen nicht erneut kompiliert werden.
Der ORB unterstützt die über die Interoperable Naming Service-Spezifikation definierten Parameter -ORBInitRef und -ORBDefaultInitRef, und die Operation ORB::string_to_object unterstützt jetzt die über die Interoperable Naming Service-Spezifikation definierten Formate für ObjectURL-Zeichenfolgen (corbaloc: und corbaname:).
Die OMG gibt die Methode ORB::register_initial_reference an, um einen Service mit dem Interoperable Naming Service zu registrieren. Diese Methode ist jedoch in der Sun Java-Core-API der Version 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.
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.
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>
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.
Der ORB kann optimiert werden, so dass er mit Ihrem spezifischen Netzwerk gut zusammenarbeitet. Die erforderlichen Merkmale für die Optimierung sind hier beschrieben.
Setzen Sie die Fragmentgröße auf 0 Byte, um die Fragmentierung zu inaktivieren:
java -Dcom.ibm.CORBA.FragmentSize=0 <MeineAnwendung>
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.
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 |
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.
Java Remote Method Invocation (RMI) bietet ein einfaches Verfahren für die verteilte Java-Programmierung. RMI-IIOP (RMI over IIOP) arbeitet auf der Grundlage des Standard-IIOP-Protokolls (IIOP - Internet Inter-ORB Protocol) der CORBA (Common Object Request Broker Architecture) und ermöglicht so Erweiterungen der Java-RMI bei Datenübertragungen. Dadurch sind direkte Interaktionen mit beliebigen anderen CORBA-Object-Request-Brokern (ORBs) möglich, unabhängig davon, ob diese in Java oder einer anderen Programmiersprache implementiert wurden.
Folgende Dokumentation steht zur Verfügung:
Thread-Pooling für Steuerroutinen von RMI-Verbindungen wird nicht standardmäßig aktiviert.
Wenn Sie das Verbindungspooling aktivieren wollen, das in der RMI-TCPTransport-Ebene implementiert ist, legen Sie die folgende Option fest:
-Dsun.rmi.transport.tcp.connectionPool=true
Diese Runtime Environment-Version verfügt über keine Einstellung, die Sie verwenden können, um die Anzahl Threads im Verbindungspool zu begrenzen.
Ü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.*;.
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.
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.
Mit dem folgenden Befehl führen Sie ein Applet mit Applet Viewer aus.
Geben Sie Folgendes an einer Eingabeaufforderung 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 Eingabeaufforderung Folgendes ein:
appletviewer <Demo>\GraphLayout\Beispiel1.html
Dabei gilt Folgendes: <Demo> wird durch den vollständigen Pfad des dekomprimierten Demopakets ersetzt.
Geben Sie zum Aufrufen von Applet Viewer auf einer Webseite an einer Eingabeaufforderung 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
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.
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 Windows. In SDK for Windows ist Runtime Environment enthalten. Sie können jedoch nicht davon ausgehen, dass SDK for Windows auf den Systemen aller Benutzer installiert ist.
Die Lizenz für SDK for Windows berechtigt nicht dazu, Dateien aus SDK zusammen mit der Anwendung weiter zu verteilen. Sie müssen sicherstellen, dass auf dem Zielsystem eine lizenzierte Version von SDK for Windows installiert ist.
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:
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.
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.
|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.
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.
Der Zugriff auf den Cache für gemeinsam genutzte Klassen wird durch Berechtigungen des Betriebssystems und Java-Sicherheitsberechtigungen begrenzt. Nur ein Klassenladeprogramm, in dem die gemeinsame Nutzung von 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.
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.
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.
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.
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:
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 HandbuchEine Ü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.
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 Cache 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 Cache 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.
Faktoren, die beim Implementieren der gemeinsamen Nutzung von Klassendaten in einem Produkt und beim Verwenden von Klassendaten in einer Entwicklungsumgebung zu berücksichtigen sind.
Die maximale theoretische Cachegröße beträgt 2 GB. Die Cachegröße, die Sie angeben können, wird durch die Größe des verfügbaren Plattenspeicherplatzes und des virtuellen Adressraums begrenzt.
Der Cache wird durch folgende Faktoren begrenzt:
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.
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 mit dem Benutzerprofil. 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.
Die Berechtigungen für den Zugriff auf einen Cache für gemeinsam genutzte Klassen werden vom Betriebssystem umgesetzt. Falls kein Cachename angegeben wird, wird der Benutzername an den Standardnamen angehängt, damit mehrere Benutzer auf demselben System standardmäßig eigene Caches erstellen.
Wenn ein 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.
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.
Das Paket mit der Java Communications API (JavaComm) ist ein optional erhältliches Paket, das zusammen mit Runtime Environment for Windows eingesetzt werden kann. JavaComm kann unabhängig von SDK oder Runtime Environment installiert werden.
Mit Hilfe der JavaComm API sind Java-Anwendungen in der Lage, Übertragungen über den seriellen Anschluss und den Parallelanschluss für Technologien, wie z. B. Voicemail, Fax und Smartcards, unabhängig von der jeweiligen Plattform durchzuführen.
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:
Stellen Sie vor der Installation der Java Communications API sicher, dass SDK oder Runtime Environment installiert ist.
Gehen Sie wie folgt vor, um Java Communications API aus einer komprimierten Datei zu installieren:
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.
Ü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.
Bei Druckvorgängen über die Java Communications API müssen Sie auf dem Drucker möglicherweise die Tasten für Seitenvorschub oder Weiter oder eine ähnliche Funktion drücken.
Löschen Sie zum Deinstallieren der Java Communications API die folgenden Dateien aus dem Verzeichnis, in dem Sie Runtime Environment installiert haben:
Runtime Environment ist standardmäßig im Verzeichnis C:\Programme\IBM\Java60\ installiert.
Dokumentation zu APIs und Beispiele zur Java Communications API finden Sie auf der Sun-Website.
http://java.sun.com/products/javacomm/.
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.
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.
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.
Uneingeschränkte JCE-Richtliniendateien finden Sie unter http://www.ibm.com/developerworks/java/jdk/security/index.html. Auf dieser Website finden Sie auch die Dokumentation zu den IBM Sicherheitspaketen JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS sowie zur Hardwareverschlüsselung.
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.
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'.
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.
Hier werden bekannte Einschränkungen für SDK und Runtime Environment for Windows erläutert.
Weitere Hilfestellungen zur Problemdiagnose finden Sie im Diagnostics Guide unter http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.
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.
IBM 64-bit SDK for Windows Version 6 unterstützt die folgenden Ländereinstellungen:
Die Schriftarten aus diesen Ländereinstellungen funktionieren jedoch möglicherweise nicht für AWT-Komponenten.
IBM 64-bit SDK for Windows Version 6 unterstützt Internet Protocol Version 6 (IPv6). Da jedoch die aktuelle IPv6-Unterstützung unter Windows nicht 'dual-stack' ist, emuliert SDK auf einem für IPv6 aktivierten System ein Dual-Stack-Verhalten. Ihre Java-Anwendung verwendet je nach Emulation möglicherweise bis zu doppelt so viele Sockets. Wenn Sie diese Emulation inaktivieren möchten, müssen Sie die IPv6-Unterstützung in SDK inaktivieren. Setzen Sie dazu das Systemmerkmal java.net.preferIPv4Stack auf true.
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:
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.
Wenn Sie mit einem Editor für Eingabemethoden (Input Method Editor, IME) arbeiten, sollten Sie die Zeichenzusammensetzung beendet und die Kandidaten ausgewählt haben, bevor Sie den Arbeitsbereich für weitere Verarbeitungen verwenden.
Wenn ein Benutzer bei der Verwendung eines Editors für Eingabemethoden (IME) Text in TextArea von AWT eingibt, und anschließend die Größe des Anwendungsfensters vor dem Festschreiben des Texts ändert, wird der Text automatisch festgeschrieben.
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.
Persönliche Firewalls können zu Fehlern im Windows NIO-Code führen, so dass bestimmte Operationen fehlschlagen. Der Methodenaufruf Selector.open() kann z. B. zu der Ausnahmebedingung "java.io.IOException: Unable to establish loopback connection" mit der Ursache "java.net.ConnectException: Connection refused: connect" führen. Die Ausnahmebedingung wird durch das Betriebssystem beim Herstellen der Verbindung zu einem Port verursacht, der von der Firewall blockiert wird. JVM versucht, die Verbindung erneut herzustellen, wobei das Betriebssystem eine andere Portnummer verwenden soll. Wenn auch nach einigen erneuten Versuchen keine Verbindung hergestellt werden kann, wird eine Ausnahmebedingung ConnectException ausgelöst.
Wenn diese Ausnahmebedingung angezeigt wird, können Sie durch Festlegen des Systemmerkmals java.nio.debug=pipe anzeigen, welche Portnummern blockiert werden.
Unter Windows XP ist der Standardwert für die Anzahl der Dateien, die Sie gleichzeitig geöffnet haben können, zu niedrig und wird zu Problemen bei Anwendungen führen, die E/A-intensiv sind. Zur Korrektur dieser Einschränkung editieren Sie die Datei <Windows>\system32\CONFIG.NT und legen die folgenden Werte fest:
files=200 buffers=60
Dabei gilt Folgendes: <Windows> ist das Verzeichnis, in dem Windows installiert ist.
Wenn Sie Doppelbytezeichen in JTextArea, JTextField oder JFileChooser eingeben, kann das Wechseln von einigen chinesischen IMEs (besonders Chinese Internal Code und Zhengma) zu Intelligent ABC IME dazu führen, dass ein Kernspeicherauszug erzeugt wird.
Für Benutzer der tschechischen Version wird in der Anzeige zur Sprachauswahl des Installationsprogramms ein übersetzter Eintrag in einer Installation angezeigt, die ansonsten nicht übersetzt ist. Diese Einschränkung wird vom Installationsprogramm verursacht. Diese Zeichenfolge wird aus dem Betriebssystem basierend auf der Codepage übernommen. Da sowohl Polnisch (in diese Sprache wurde die Installation übersetzt) als auch Tschechisch die Codepage 1250 haben, versucht das Installationsprogramm, eine Sprachenliste für beide Sprachen aus dem System abzurufen. Dies führt zu dieser Zeichenfolge in der Sprachenliste.
Wenn Sie traditionelles Chinesisch verwenden, leiten Sie die Ausgabe Ihrer Java-Anwendung nicht direkt in den Befehl more um. Leiten Sie die Ausgabe stattdessen in eine temporäre Datei, und zeigen Sie die Datei separat an.
Wenn Sie den japanischen MS-IME unter Windows XP Professional x64 Edition verwenden, kann SDK (64 Bit) Fehler mit Windows XP-Desktopdesigns verursachen. Legen Sie die Umgebungsvariable IBMJAVA_USE_WINDOWS_CLASSIC_THEME so fest, dass Java-GUI-Fenster mit dem klassischen Windows-Design angezeigt werden, oder ändern Sie Ihr Systemdesign in das klassische Windows-Design, um diese Fehler zu vermeiden. Weitere Informationen zu dieser Einschränkung, die nur in der japanischen Version auftritt, finden Sie im Microsoft Knowledge Base-Artikel 905843.
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.
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'.
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.
Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.
IBM ist eine Marke der International Business Machines Corporation in den USA und/oder anderen Ländern.
Java und alle Java-basierten Marken und Logos sind in gewissen Ländern Marken oder eingetragene Marken von Sun Microsystems, Inc.
Microsoft, Windows und das Windows-Logo sind in gewissen Ländern Marken der Microsoft Corporation.
Andere Namen von Unternehmen, Produkten oder Dienstleistungen können Marken oder Dienstleistungsmarken anderer Unternehmen sein.