Versionshinweise JavaTM 2 SDK, Standard Edition Version 1.3.1

Inhaltsverzeichnis

Überblick
Java Virtual Machine
Schriftarteneigenschaften
Xserver-Fehler unter Solaris
RMI
CORBA, RMI-IIOP und Java IDL
Java 2D^TM-Technologie
Ziehen und Ablegen
Eingabehilfe
AWT und Swing
JDBC
Sicherheit
Netzwerk
Java^TM Plug-in-Komponente
Lokalisierungshinweise
Dokumentation
Tools können unter Solaris 2.6 keine japanischen PCK-Strings konvertieren
Probleme mit der Schriftart für traditionelles Chinesisch
Unterstützung für Windows 2000
Installation unter Windows NT

Bei Java 2 SDK, Standard Edition 1.3.1 (J2SDK 1.3.1) handelt es sich um eine Wartungsversion mit Korrekturen von Fehlern, die in früheren Versionen entdeckt wurden. Ausführlichere Informationen zu diesen Fehlern finden Sie im Abschnitt

In dieser Version behobene Fehler

Darüber hinaus enthält J2SDK 1.3.1 die folgenden Verbesserungen:

• Verbesserungen des Java^TM Plug-ins
  Diese Version enthält ein optimiertes Java Plug-in mit zahlreichen neuen Funktionen, durch die es flexibler und einfacher in Handhabung und Konfiguration wird, und mit denen die neuen Open JVM Interface-Funktionen des Netscape 6-Browsers unterstützt werden können. Weitere Informationen finden Sie im Abschnitt Neue Java Plug-in-Funktionen. Diese Verbesserungen des Java Plug-ins waren erstmals in der Aktualisierungsversion J2SDK 1.3.0_01 enthalten.

• Fehlerbehandlungsfunktion der Java Virtual Machine
  In J2SDK 1.3.1 verfügen die Java Virtual Machines über einen Fehlerbehandlungsmechanismus, mit dem bei einem Absturz Informationen zur Fehlerkorrektur in nativem Code auf dem Bildschirm angezeigt werden. Weitere Informationen finden Sie im Abschnitt Fehlerbehandlung bei J2SDK 1.3.1.

• HTML-Konverter nun in Java 2 SDK enthalten
  Der HTML-Konverter ist nun als Teil von Java 2 SDK enthalten. In früheren Versionen, einschließlich der Betaversion von J2SDK 1.3.1, war der HTML-Konverter nur als separater Download erhältlich.

Eine Dokumentation des Java Plug-ins finden Sie auf der Java Plug-in-Website.

Eine vollständige Dokumentation von J2SDK 1.3.1 ist als Download erhältlich . Siehe auch das neue Online-Dokument Optimieren der Garbage Collection mit Hilfe der Java Virtual Machine von J2SDK 1.3.1.

Die im Folgenden aufgeführten, für Benutzer von J2SDK 1.3.1 möglicherweise relevanten Informationen enthalten Beschreibungen wichtiger Fehlerkorrekturen, bekannter Fehler und Ausweichlösungen sowie verschiedene Tipps und Vorschläge zur Verwendung dieser Version.

Die folgenden Hinweise beziehen sich auf die Java Virtual Machine.

• Unter Linux wird ein auf einen E/A-Vorgang wartender Thread nicht wieder aktiviert, wenn eine von dem E/A-Vorgang betroffene Datei geschlossen wird. Dieses Problem hat die Fehlernummer 4344135. Setzen Sie zum Vermeiden dieses Problems die Umgebungsvariable J2SE_PREEMPTCLOSE auf 1.

  J2SE_PREEMPTCLOSE=1 
  export J2SE_PREEMPTCLOSE
  

• Fehler 4323062: Beim Abmelden des Benutzers wird jeder Windows NT-Dienst mit integrierter Java VM beendet.

  Dieser Fehler wurde in J2SDK 1.3.1 behoben. Zur Aktivierung der Korrektur muss der JVM die Befehlszeilenoption -Xrs übergeben werden. Das zusätzliche Befehlszeilenargument ist erforderlich, weil durch die Korrektur notwendigerweise der J2SDK 1.3-Mechanismus zum Schließen von Hooks deaktiviert und die Verwendung der Klasse sun.misc.Signal ausgeschlossen wird. Weitere Hintergrundinformationen finden Sie u.a. in der Aufstellung bekannter Fehler im letzten Abschnitt.

  http://developer.java.sun.com/developer/bugParade/bugs/4323062.html

• Ein JNI-Fehler kann bei der Beendigung eines Programms zu einem Absturz der JVM führen, wobei eine Fehlermeldung etwa folgenden Inhalts angezeigt wird.

  Another exception has been detected while we were handling last error. 
  Dumping information about last error: ERROR REPORT FILE = (N/A) 
  PC                = 0x0x41621c7a 
  SIGNAL            = 11 
  FUNCTION NAME     = (N/A) 
  LIBRARY NAME      = (N/A) 
  Please check ERROR REPORT FILE for further information, if there is any. 
  Good bye.
  

  Dieses Problem kommt am häufigsten unter Linux Red Hat 7.1 SMP vor, doch könnte es theoretisch auch unter Microsoft Windows oder Solaris auftreten.

  Ausweichlösung - Fügen Sie am Ende der main-Methode der Anwendung einen expliziten Aufruf der exit-Funktion hinzu: Runtime.getRuntime().exit(0)

• Unter Red Hat 7.1 kann das Ausführen von Code auf Java-Plattformen mittels automatisch gemountetem NFS zu häufigen Abstürzen in dlopen() führen. Dieses Problem liegt anscheinend am Automount des NFS. Es wird beseitigt, wenn Sie das Verzeichnis explizit mit dem folgenden Befehl mounten: mount -t nfs.

In Bezug auf Schriftarteneigenschaften treten bei dieser Version die folgenden Fehler auf:

• Bei Verwendung anderer Linux Red Hat-Versionen als Version 6.1 zeigt die Datei font.properties möglicherweise in manchen AWT-Komponenten einige Symbol/Dingbats-Zeichen nicht richtig an. Verwenden Sie zur Behebung des Problems diese korrigierte Datei font.properties, die die ursprüngliche Datei im Verzeichnis <JAVA_HOME>/jre/lib/ ersetzt.

• Aufgrund des Fehlers 4419794 können Schriftarteneigenschaften unter Solaris 8 (Intel-Architektur) Warnmeldungen für UTF-8-Locales ausgeben. Wenn Sie UTF-8-Locales unter Solaris 8 auf Intel-Hardware verwenden müssen, rüsten Sie Ihr System auf Solaris 8, Aktualisierungsversion 4 auf, in der dieser Fehler behoben wurde.

Der Solaris-Xserver-Fehler kann das System zum Absturz bringen, wenn eine in Java geschriebene Anwendung auf Schriftarten zugreift. Dieses Problem wird im Fehlerbericht 4391019 beschrieben. Die folgenden Solaris-Korrekturversionen für Xserver werden ab Mitte Juni 2001 zur Verfügung stehen. Sie helfen möglicherweise dabei, das Auftreten dieses Problems zu verringern.

Für Solaris 2.6: 105633-55 (Sparc) 106248-41 (Intel)
Für Solaris 7: 108376-24 (Sparc) 108377-22 (Intel)
Für Solaris 8: 108652-31 (Sparc) 108653-26 (Intel)

Überprüfen Sie auf der SunSolve-Website die Verfügbarkeit dieser Korrekturversionen.

Im Folgenden werden wichtige in dieser Version umgesetzte Änderungen der Funktionsweise von RMI (Remote Method Invocation) genannt.

• "accept" java.net.SocketPermission zum Empfangen von Remote-Calls erforderlich
  Aufgrund eines Fehlers in früheren J2SDK-Implementierungen war es möglich, ein Remote-Objekt in einem bestimmten Zugangskontroll-Kontext zu exportieren und anschließend über eine vorgegebene Socketverbindung Remote-Calls für das Objekt zu empfangen, selbst wenn der Zugangskontroll-Kontext für die entfernte java.net.InetAddress und den Anschluss der Socketverbindung nicht über eine "accept" java.netSocketPermission verfügte.

  Dieser Fehler wurde behoben. Daher muss möglicherweise in einigen Fällen Code, der Remote-Objekte exportiert, weitergehende Berechtigungen zugewiesen werden als bei früheren Implementierungen, damit er ordnungsgemäß funktioniert.

  Im Folgenden wird an einem Beispiel erläutert, wie solche Berechtigungen unter Verwendung der Syntax für eine Standardsicherheitsrichtlinien-Datei erteilt werden. Die Berechtigung zur Annahme von Socketverbindungen von einem Host namens terrier.east.sun.com kann mit folgendem Berechtigungseintrag (im "grant"-Eintrag für die entsprechende Codequelle) formuliert werden:

  permission java.net.SocketPermission "terrier.east.sun.com", "accept";
  

  Wie in der Dokumentation zu java.netSocketPermission beschrieben, können Host-Spezifikationen mit einem Platzhalterzeichen "*" beginnen. Daher kann die Berechtigung zur Annahme von Socketverbindungen für jeden Host in einem "grant"-Eintrag mit folgendem Berechtigungs-Eintrag beschrieben werden:

  permission java.net.SocketPermission "*", "accept";
  

• Garbage Collection für nicht exportierte Remote-Objekte funktioniert nicht
  In vorherigen Implementierungen behielt die RMI-Runtime starke Referenzen auf ein Remote-Objekt, selbst nachdem dieses explizit de-exportiert wurde. Dieser Fehler wurde behoben, so dass die RMI-Runtime in keinem Fall Remote-Objekte referenziert, die explizit de-exportiert wurden.

• Leistung der ObjectOutputStream-Ersetzungstabelle
  In vorherigen Implementierungen hielt eine ObjectOutputStream -Instanz Informationen über ersetzte Objekte (d.h. Objekte, die von einem Aufruf von ObjectOutputStream.replaceObject oder von einer klassendefinierten writeReplace-Methode zurückgegeben wurden) so fest, dass eine lineare Suche erforderlich war, um festzustellen, ob ein Objekt ersetzt wurde. Daher wuchs bei einer großen Anzahl von Objekten, die in einem bestimmten Stream ersetzt wurden, der Aufwand für jedes neu eingeordnete Objekt in eine nicht vertretbare Höhe. Dieser Fehler wurde behoben, so dass die aktuelle Implementierung nun einen leistungsfähigeren Algorithmus zum Festhalten von Informationen über ersetzte Objekte verwendet. Diese Korrektur der Implementierung der Objekt-Serialisierung kommt auch der Skalierbarkeit der Objektersetzung beim Marshalling von RMI-Argumenten und -Rückgabewerten zugute.

Die folgenden Kommentare beziehen sich auf die CORBA-, RMI-IIOP- und Java IDL-Funktionalität in dieser Version.

• Die Kompatibilität des Sun ORB mit ORBs anderer Hersteller wurde nicht getestet, und es wird keine Gewährleistung dafür übernommen.

• Wenn ein J2SDK 1.3.1-Server zuerst mit einem J2SDK 1.3-Client verbunden wird, und anschließend ein J2SDK 1.3.1-Client eine Serializable-Instanz sendet, die in ihren writeObject- oder readObject-Methoden writeUTF bzw. readUTF verwendet, wird eine MARSHAL-Ausnahme ausgelöst. Ebenso wird eine MARSHAL-Ausnahme ausgelöst, wenn ein J2SDK 1.3.1-Server zuerst mit einem J2SDK 1.3.1-Client verbunden wird, und anschließend ein J2SDK 1.3-Client eine Instanz des gleichen Klassentyps zu senden versucht. Dieses Problem hat die Fehlernummer 4434140.

  Ausweichlösung - Ändern Sie die Serializable-Klasse so, dass sie anstelle von writeUTF bzw. readUTF die Methoden writeObject und readObject verwendet.

• Bei J2SDK 1.3 wurden writeUTF- und readUTF-Aufrufen CORBA-Strings anstatt wstrings zugeordnet. Folglich konnten diese Verfahren nicht zum Senden von Strings mit Zeichen verwendet werden, deren Werte größer als 8 Bit sind. Dieser Fehler wurde in J2SDK 1.3.1 behoben, aber die Kommunikation mit J2SDK 1.3 unterliegt der gleichen Einschränkung. Dieses Problem hat die Fehlernummer 4379597.

  Ausweichlösung - Verwenden Sie anstelle von writeUTF bzw. readUTF die Methoden writeObject und readObject. Sowohl JDK 1.3.1 als auch J2SDK 1.3 wandeln dies in CORBA-wstring-Aufrufe um, wenn die Methodenparameter Strings sind.

• Der im Lieferumfang von J2SDK 1.3.1 enthaltene Java ORB enthält Korrekturen, die evolutionäre Änderungen der Serializable-Klassen unterstützen, wie in der Java Serialization Specification angegeben.

  Aufgrund dieser Unterstützung können sowohl J2SDK 1.3.1 als auch zukünftige J2SDK-Versionen mit Klassenevolution umgehen. Wenn beispielsweise eine mit J2SDK 1.3.1 gelieferte Klasse V in einer zukünftigen J2SDK-Version weiterentwickelt wird, wird ein Anwendungsclient (Senden/Empfangen von Klasse V), der unter J2SDK ausgeführt wird, mit einem unter der zukünftigen J2SDK-Version ausgeführten Server (Empfangen/Senden der weiterentwickelten Klasse V) kompatibel sein und umgekehrt.

  Jedoch enthält die Vorversion J2SDK 1.3.0 Fehler, die Klassenevolution verhindern. (Vergleiche z.B. Fehlerbericht 4365188 auf der Java Developer Connection^SM-Website.) Daher kommt es beim Senden weiterentwickelter Klassen von J2SDK 1.3.1 nach J2SDK 1.3 zu Kompatibilitätsproblemen.

• Beim Programmieren in OMG IDL darf kein Schnittstellenname als Bezeichnung für ein Modul gewählt werden. Andernfalls können beim Kompilieren mit Tools von verschiedenen Anbietern Inkonsistenzen auftreten, was die Portabilität des Codes gefährden kann. Mit dem IDL-zu-Java-Compiler von Sun Microsystems könnte z.B. Code kompiliert werden, der dieselben Bezeichnungen enthält, und ein bestimmtes Ergebnis liefern. Wenn derselbe Code mit dem IDL-zu-Java-Compiler eines anderen Anbieters kompiliert wird, könnte ein abweichendes Ergebnis entstehen.

Fehler 4178909 in den Java 2D^TM -Bibliotheken führt gelegentlich dazu, dass Anwendungen im 8 Bit-Modus nicht richtig dargestellt werden können. Dieses Problem sollte nur auftreten, wenn eine Anwendung zum ersten Mal nach einem Neustart des Systems oder dem Umstellen des Anzeigemodus auf 8 Bit gestartet wird.

Es bestehen auch einige DirectDraw betreffende Fehler. Falls bei Ihnen Probleme mit DirectDraw auftreten, können Sie DirectDraw auch deaktivieren:

-Dsun.java2d.noddraw=true

Bei manchen Grafikkartentreibern können die auf dem Bildschirm dargestellten Bilder bzw. Fenster erscheinen, als würden sie neu synchronisiert oder springen, wenn auf DirectDraw zugegriffen wird. Wenn dieser Effekt bei Ihnen auftritt, sollten Sie versuchen, auf der Website des Herstellers einen aktuelleren Treiber zu finden, mit dem das Problem gelöst werden kann.

Die Java-Plattform unterstützt keine 16-Farben-Anzeige. Falls Probleme beim Zeichnen von Grafiken und GUI-Komponenten im 16-Farben-Modus auftreten, sollte die Farbtiefe auf 256 Farben oder mehr umgestellt werden.

Die folgenden Funktionen wurden implementiert und sind funktionstüchtig, sind jedoch nicht vollständig getestet und werden für diese Version nicht unterstützt.

• Übertragung per Ziehen und Ablegen ist möglich für:
  • Plattformspezifische oder benutzerdefinierte Datentypen
  • Instanzen von beliebigen Klassen, die von verschiedenen ClassLoader-Instanzen innerhalb derselben JVM* geladen wurden
  • Serialisierte Java-Objekte, zwischen JVMs (oder ClassLoadern)
• Verknüpfen von RMI java.rmi.Remote-Unterschnittstellen zwischen JVMs

AWT- und Swing-Komponenten verfügen über innere Klassen, über die die Java-Zugriffs-API implementiert wird und die für die Komponenten entsprechende Zugriffs-Unterstützung gewährleisten. Für die folgenden AWT-Klassen wurde in dieser Version die Zugriffs-Unterstützung jedoch nicht vollständig implementiert:

java.awt.TextComponent
java.awt.Menu
java.awt.MenuItem
java.awt.List

Vollständige Zugriffs-Unterstützung für alle Komponenten wird in einer der künftigen Versionen der Java 2-Plattform implementiert.

Die folgenden Kommentare beziehen sich auf die AWT- und Swing-Funktionalität in dieser Version.

• Ein Programm, das die statische Methode Toolkit.getDefaultToolkit aufruft, wird nicht beendet, so dass nicht zur Eingabeaufforderung zurückgekehrt wird. Dieses Problem ist in den Fehlerberichten 4030718 und 4403762 beschrieben und wird in J2SDK 1.4.0 Beta behoben sein.

  Auweichlösung - Rufen Sie bei Abschluss der Anwendung die Funktion System.exit() auf.

• Die neue Methode Component.getListeners() gibt keine PropertyChangeListeners zurück. Nach dem Hinzufügen eines Listeners mit addPropertyChangeListener()

  gibt myComponent.getListeners(PropertyChangeListener.class)
  

  ein leeres Array zurück.

• Fehler Nummer 4199374 betrifft ein Problem der Fokusverwaltung mit JWindow-Objekten. Insbesondere verhindert dieser Fehler, dass Component.requestFocus() den Fokus an Komponenten in einem JWindow abgeben kann. Dieser Fehler wurde in den Aktualisierungsversionen J2SDK 1.2.2_05 und J2SDK 1.3.0_02 behoben. Er ist unter J2SDK 1.3.1 allerdings nicht behoben.

Unter Windows NT unterstützt die JDBC 2.0-Bridge den Treibermanager und die Treiber von ODBC 2.x und ODBC 3.x. Die JDBC 2.0-Bridge wurde nur mit einem ODBC 3.x-Treibermanager und mit ODBC 2.x- und 3.x-Treibern getestet.

Merant empfiehlt, die JDBC 2.0-Bridge zusammen mit den DataDirect ODBC-Treibern von Merant, Version 3.5 oder höher, zu verwenden.

Die folgenden sicherheitsrelevanten Themen beziehen sich auf diese Version.

Das Dienstprogramm jarsigner kann Dateien prüfen, die von Netscape SignTool 1.3 signiert wurden, wenn die Zertifikate für das Signieren des Codes nicht eigensigniert sind. Hinweis: Offizielle Netscape-Zertifikate zum Signieren von Code können von VeriSign^TM bezogen werden. Diese Zertifikate werden von VeriSign herausgegeben. Sie sind nicht eigensigniert.

Das Netscape SignTool 1.3 fügt der Signaturdatei keine Zertifikate hinzu, wenn das Zertifikat zum Signieren von Code eigensigniert ist. Das Programm jarsigner kann eine signierte JAR-Datei nicht prüfen, wenn die Signaturdatei nicht das Zertifikat des Unterzeichners enthält. Hinweis: Das von SignTool 1.3 selbst erzeugte Zertifikat zum Signieren von Code ist nur für Testzwecke geeignet und ist eigensigniert. Es ist ein bekanntes Problem, dass jarsigner keine JAR-Dateien prüfen kann, die von Netscape SignTool 1.3 signiert wurden, wenn das Zertifikat zum Signieren von Code ein eigensigniertes Testzertifikat ist.

Im Java 2 SDK werden Anwendungsklassen durch eine ClassLoader-Instanz geladen. Dadurch können Anwendungsklassen installierte Erweiterungen nutzen. Außerdem wird dadurch der vom Benutzer angegebene Anwendungsklassenpfad vom Bootstrapklassenpfad getrennt, der fest vorgegeben ist und normalerweise nicht vom Benutzer geändert werden sollte. Bei Bedarf kann die Option -Xbootclasspath verwendet werden, um den Bootstrapklassenpfad zu überschreiben.

Das bedeutet jedoch, dass Anwendungsklassen im Java 2 SDK als Standard nicht mehr über alle Berechtigungen verfügen. Die Berechtigungen werden dann auf der Grundlage der für das System konfigurierten Sicherheitsrichtlinien vergeben. Das kann dazu führen, dass einige Anwendungen, die ihren eigenen Sicherheitscode auf der Grundlage des ursprünglichen 1.0/1.1-Sicherheitsmodells schreiben, eine Ausnahme ausgeben und nicht im Java 2 SDK gestartet werden. Dieses Problem kann umgangen werden, indem diese Anwendungen mit dem Anwendungsstartprogramm oldjava ausgeführt werden. Die zugehörige Dokumentation finden Sie auf der Referenzseite für das Java-Startprogramm.

In den folgenden Hinweisen werden die Probleme bezüglich Sicherheitsrichtlinien und Signieren zusammengefasst.

• Die von der Java 2-Plattform verwendete Implementierung der Standardsicherheitsrichtlinien ist in der Eigenschaft policy.provider in der Java-Sicherheitseigenschaftendatei jre/lib/security/java.security angegeben. Wenn Sie eine nicht dem Standard entsprechende Implementierung der Sicherheitsrichtlinien angeben, müssen Sie die neue, nicht dem Standard entsprechende Klassendatei für Sicherheitseigenschaften im Bootstrapklassenpfad einfügen. Dies können Sie über die Befehlszeilenoption -Xbootclasspath erreichen. Informationen über diese Option finden Sie auf der Referenzseite für das Java-Startprogramm. Dadurch wird die Richtliniendatei vom Bootstrapklassenlader geladen. Wenn die neue Standardrichtliniendatei an anderer Stelle abgelegt wird, z.B. im Klassenpfad oder einer Erweiterung, kann sie nicht gefunden werden und es werden stattdessen die Standardrichtlinien verwendet, die in sun.security.provider.PolicyFile abgelegt sind.

• Ab Version 1.2.2 wird im Java 2 SDK ein neuer Klassenlademechanismus verwendet. Für den neuen Klassenlader gilt: Wenn eine beliebige Datei signiert ist, die zu einem Paket in einer Jar-Datei gehört, müssen alle Klassen, die zu demselben Paket gehören, von demselben Unterzeichner signiert worden sein. Es ist nicht mehr möglich, eine Jar-Datei zu verwenden, in der einige Klassen eines Pakets signiert sind und andere nicht bzw. von einem anderen Unterzeichner signiert wurden. Jar-Dateien können weiterhin unsignierte Pakete enthalten. Wenn jedoch Pakete signierte Klassen enthalten, müssen alle Klassendateien dieses Pakets von demselben Unterzeichner signiert sein. Vorhandene Jar-Dateien, die dieses Kriterium nicht erfüllen, können mit dieser Version der Java 2-Plattform nicht verwendet werden.

Das Tool keytool kann zur Zeit ein Base64-codiertes Zertifikat nur importieren oder ausdrucken, wenn die Datei mit einer Leerzeile (Zeilenvorschub) abgeschlossen ist. Wenn am Ende der Zertifikatsdatei kein Zeilenvorschub vorhanden ist und Sie versuchen, das Zertifikat zu importieren oder zu drucken, wird eine CertificateException "Unsupported encoding" oder eine keytool-Fehlermeldung wie "Failed to parse input" oder "Input not an X.509 certificate." ausgegeben.

Wenn eine derartige Meldung oder Ausnahme ausgegeben wird, kann ein fehlender abschließender Zeilenvorschub die Ursache sein. Das kann unter anderem dann geschehen, wenn eine Zertifikatsantwort einer Zertifizierungsstelle (als Antwort auf eine Zertifikatssignierungsanforderung) keinen abschließenden Zeilenvorschub enthält.

Unter UNIX kann durch Ausführen des folgenden Befehls festgestellt werden, ob die Datei einen abschließenden Zeilenvorschub enthält:

    od -xc <Zertifikatsname>

wobei <Zertifikatsname> der Name der Datei ist, die das Zertifikat enthält. Wenn die Datei zum Beispiel den Namen meinzert trägt, würde der Befehl so aussehen:

    od -xc meinzert

Wenn die entsprechende Ausgabe ganz am Ende ein "\n" enthält (ohne die Anführungszeichen), ist bereits ein Zeilenvorschub am Ende vorhanden. Falls nicht, können Sie einen Zeilenvorschub hinzufügen.

Wenn Sie sich nicht sicher sind, ob die Zertifikatsdatei einen abschließenden Zeilenvorschub enthält, können Sie einen abschließenden Zeilenvorschub entsprechend dem folgenden Absatz hinzufügen (da zusätzliche Zeilenvorschübe keine Probleme verursachen) und den Befehl -import oder -printcert wiederholen. Wenn der Befehl jetzt funktioniert, war ein fehlender Zeilenvorschub die Ursache. Wenn immer noch eine Fehlermeldung ausgegeben wird, liegt ein anderes Problem mit dem Zertifikat vor.

Um am Ende einer Base64-codierten Zertifikatsdatei einen Zeilenvorschub hinzuzufügen, öffnen Sie die Datei in einem beliebigen Texteditor, setzen Sie den Cursor an das Ende der Datei, und fügen Sie einen Zeilenvorschub ein (bzw. Wagenrücklauf + Zeilenvorschub), z.B. durch einfaches Drücken der Eingabetaste auf der Tastatur.

Netzwerk

In dieser Version liegen in der Netzwerk-API die folgenden bekannten Fehler und Beschränkungen vor:

• Unter Windows 2000 können Datagramm-Anwendungen eine unerwartete SocketException empfangen, die angibt, dass der Socket geschlossen ist. Dies hängt mit dem neuen Verhalten unter Windows 2000 zusammen, wenn die Remote-Anwendung nicht verfügbar ist. Eine Umgehungsmöglichkeit besteht darin, den DatagramSocket zu schließen und erneut zu erstellen. Dieses Problem hat die Fehlernummer 4361783.

• In J2SDK 1.3.0 wurde erstmals eine HTTP/1.1 Client-Implementierung angeboten. Webserver wie z.B. Apache geben Antworten an HTTP 1.1-Clients mit Chunk Encoding zurück, aber unter J2SDK 1.3.0 und 1.3.1 wird die mit Chunk Encoding codierte Antwort nicht als Datenfluss vom Server weitergegeben. Dies bedeutet, dass Methoden wie java.net.URLConnection.getInputStream nicht zurückkehren, bevor die Antwort des Servers abgeschlossen ist. Dieses Problem wird unter Fehlernummer 4333920 beschrieben.
  Umgehen Sie das Problem folgendermaßen: Für Apache kann das Problem umgangen werden, indem in httpd.conf die folgende Zeile eingefügt wird.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

• Die HTML 4.0-Spezifikation empfiehlt, Nicht-ASCII-Zeichen in URIs (Uniform Resource Identifiers) in einem oder mehreren UTF-8-Bytes zu codieren. In vielen vorhandenen CGI-Skripts werden Nicht-ASCII-Zeichen verarbeitet, indem Bytes aus der Codierung verwendet werden, in der ein Dokument empfangen wird. Die Klassen URLEncoder und URLDecoder unterstützen jedoch keine dieser Methoden zur Verarbeitung von Nicht-ASCII-Zeichen in URIs. In diesen Klassen werden stattdessen entsprechend der Definition in der Standardcodierung der zugrundeliegenden Plattform ein oder mehrere Bytes für die Zeichen ersetzt. Dabei handelt es sich um den Fehler 4257115.

• Der Aufruf der Methode HttpURLConnection.getResponseCode auf dem Client kann zum Absturz der virtuellen Maschine führen, wenn das von einem Windows 98- oder Windows NT-Server gesendete HTTP-Headerfeld zusätzliche Wagenrückläufe (CRs) enthält. Dabei handelt es sich um den Fehler 4258697.
  Umgehen Sie das Problem folgendermaßen: Der Stapelüberlauf kann vermieden werden, indem der HTTP-Server zum Senden einer HTTP-1.0-Antwort konfiguriert wird. Für Apache wird dies erreicht, indem in httpd.conf die folgende Zeile eingefügt wird.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

Wenn Ihre Anwendung die Netzwerkklassen verwendet, kann es in Verbindung mit Winsock 1.1 zu Unzuverlässigkeiten kommen. Wenn Ihre Netzwerkanwendung Windows 95 unterstützen muss, in dessen Lieferumfang Winsock 1.1 enthalten ist, sollten die Benutzer Ihrer Anwendung Winsock 2.0 verwenden. (Windows NT 4.0, Windows 2000, Windows ME und Windows 98 enthalten Winsock 2.0.) Winsock 2.0 kann unter folgender Adresse heruntergeladen werden:

http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/

Informationen, wie festgestellt werden kann, ob die Winsock 2.0-Komponenten auf einer Windows 95-Plattform installiert sind, finden Sie unter folgender URL:

http://support.microsoft.com/support/kb/articles/Q177/7/19.asp

Ohne die Aktualisierung von Winsock kann InetAddress.getByName in kernel32.dll abstürzen, wenn die Zuordnung eines Namen fehlschlägt. Informationen über diesen Fehler finden Sie auf der Microsoft-Website.

http://support.microsoft.com/support/kb/articles/Q176/3/54.ASP

Java^TM Plug-in-Komponente

Die folgenden Hinweise beziehen sich auf die Java Plug-in-Komponente dieser Version.

• Unter Linux können von einem Webbrowser aus nicht mehrere Kopien eines Applets gedruckt werden. Der Browser muss vor jedem neuen Druckvorgang geschlossen und neu gestartet werden. Dieses Problem hat die Fehlernummer 4450194.

• Bei der Installation einer Erweiterung über die Java Plug-in-Komponente wird ein Dialogfeld eingeblendet, in dem der Benutzer auf das Problem hingewiesen wird. Wenn der Benutzer auf die Schaltfläche zum Ablehnen klickt, wird das Dialogfeld allerdings gelegentlich erneut eingeblendet, und der Benutzer wird erneut zum Zustimmen oder Ablehnen der Installation dieser Erweiterung aufgefordert. Dieser Fehler wird in einer künftigen Version behoben.

• In Version 1.3.0_01 wurde das Überprüfen von Signaturen dahingehend geändert, dass der Speicher für CA-Zertifikate der Sun Java-Laufzeitumgebung verwendet wird und nicht die Ablage von Microsoft Internet Explorer. Diese Änderung wurde vorgenommen, da der Zertifikatspeicher von Internet Explorer nicht für Applets unter Netscape Webbrowsern funktioniert. In Version 1.3.1 wurde zusätzlicher Programmcode zur Fehlerbehandlung eingeführt, der für nicht überprüfbare Signaturen bestimmt ist. Siehe Fehlerbericht 4424604.

Lokalisierungshinweise

Allgemeine Informationen über die Unterstützung von länderspezifischen Einstellungen in dieser Version finden Sie in den Lokalisierungshinweisen.

Dokumentation

Die folgenden Kommentare beziehen sich auf die Dokumentation dieser Version.

• Aufgrund von Fehler 4459595 enthält die Seite mit dem Serialisierungs-Formular in der API-Spezifikation zu dieser Version einige ungültige Verknüpfungen zu Dateien für private bzw. für Pakete private Klassen.

• Siehe das neue Online-Dokument Optimieren der Garbage Collection mit Hilfe der Java Virtual Machine von J2SDK 1.3.1.

Tools können unter Solaris 2.6 keine japanischen PCK-Strings konvertieren

Wenn unter Solaris 2.6 und bei Verwendung der Ländereinstellung ja_JP.PCK japanische Zeichenfolgen als Argumente des java-Befehls verwendet werden, tritt ein Fehler auf. Um dieses Problem zu vermeiden, ändern Sie Zeile 89 der Datei /usr/java/bin/.java_wrapper von

exec $DEBUG_PROG "$prog" $opts "$@"

zu

exec $DEBUG_PROG $prog $opts $@

Probleme mit der Schriftart für traditionelles Chinesisch

Die folgenden Probleme mit Schriftarten in traditionellem Chinesisch sind in dieser Version bekannt.

• Microsoft Windows 95 für traditionelles Chinesisch Version 2.0 enthält keine der in den Schriftenarteneigenschaftendateien des Java 2 SDK angegebenen Schriftarten für traditionelles Chinesisch. Die Verwendung von Java 2 SDK oder der Java 2-Laufzeitumgebung unter diesem Betriebssystem führt zu "font not found"-Meldungen, und der Text wird möglicherweise nicht richtig dargestellt. Dieses Problem wurde mit der aktuelleren Version Microsoft Windows 95 für traditionelles Chinesisch Version 2.0, zweite Ausgabe (vom Oktober 1996), beseitigt. Diese Version enthält die angegebenen Schriftarten.

• In der Umgebung für traditionelles Chinesisch unter Microsoft Windows 95 werden chinesische Zeichen bei Swing-Komponenten nicht ordnungsgemäß dargestellt. Weitere Details zu diesem Problem finden Sie in Fehlerbericht 4431319 auf der Website der Java Developer Connection ^SM.

Version 1.3.1 des Java 2 SDK wird unter den englischen Regionaleinstellungen von Windows 2000 Professional, Windows 2000 Server und Windows 2000 Advanced Server unterstützt. Die DataCenter Edition von Windows 2000 wird nicht unterstützt. Unter nicht englischsprachigen Regionaleinstellungen wird nur Windows 2000 Professional unterstützt. Bekannte Probleme mit Windows 2000:

• Windows 2000 und Unterstützung für mehrere Monitore - Auf der Windows 2000-Plattform ist die Unterstützung für mehrere Monitore noch nicht vollständig gewährleistet. Insbesondere wird der Farbmodus mit 256 Farben nur fehlerfrei ausgeführt, wenn alle Monitore auf 256 Farben eingestellt sind. Es wird dringend empfohlen, mindestens den 16 Bit-Modus zu verwenden.

• Wenn während der Installation von Windows 2000 die Meldung

     config.nt. The system file is not suitable for running MS-DOS
     and Microsoft Windows Applications.
  

  ausgegeben wird, deutet dies auf ein Problem mit der Datei %SystemRoot%\System32\COMMAND.COM hin, das bei einigen Installationen von Windows 2000 beobachtet wurde. Wenn diese Fehlermeldung beim Versuch auftritt, das Installationsprogramm zu starten, erhalten Sie Informationen über die Lösung dieses Problems auf der Microsoft-Website unter

  http://support.microsoft.com/support/kb/articles/Q142/2/71.asp

  .

• Nicht reagierende Prozesse - Eine Anwendung kann aufgrund eines Deadlocks in Ntdll unter den Betriebssystemen Microsoft Windows 2000 Professional, Server und Advanced Server nicht mehr reagieren. Dieses Problem kann zum Beispiel bei Anwendungen auftreten, die Eingabe- und Ausgabestreams von java.lang.Process -Objekten verwenden. Weitere Informationen und eine Möglichkeit zur Fehlerbehebung finden Sie auf der Microsoft Support Services-Website unter

  http://support.microsoft.com/support/kb/articles/Q271/1/82.ASP

Installation unter Windows NT

Nach der Installation der Java Runtime Environment 1.3.1 hat das ActiveX-Steuerelement C:\Winnt\Downloaded Program Files\Java Runtime Environment 1.3.1 den Status "Beschädigt". Dies ist kein wirkliches Problem, denn der Status "Beschädigt" hat in keiner Hinsicht nachteilige Auswirkungen.

Es gibt trotzdem eine Ausweichlösung, wenn aus bestimmten Gründen nicht der Status "Beschädigt" angezeigt werden soll. Klicken Sie im Startmenü auf "Ausführen", und geben Sie "regedit" ein. Suchen Sie im Fenster des Registrierungseditors den Registrierungsschlüssel "KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation" Doppelklicken Sie auf den String "INF", und löschen Sie die markierte Zeichenfolge unter "Wert". Das ActiveX-Steuerelement hat danach den Status "Installiert".

Copyright (c) 2001 Sun Microsystems, Inc. Alle Rechte vorbehalten.