Versionsinformation JavaTM 2 SDK, Standard Edition Version 1.3.1

Innehåll

Översikt
Java Virtual Machine
Egenskaper för teckensnitt
Xserver-fel på Solaris
RMI
CORBA, RMI-IIOP och Java IDL
Java 2D^TM-teknologi
Dra och släpp
Hjälpmedel
AWT och Swing
JDBC
Säkerhet
Nätverk
Komponenten Java^TM Plug-in
Information om lokalanpassning
Dokumentation
Verktyg kan inte konvertera japanska PCK-strängar på Solaris 2.6
Fel på teckensnitt för traditionell kinesiska
Stöd för Windows 2000
Installation på Windows NT

Java 2 SDK, Standard Edition, version 1.3.1 (J2SDK 1.3.1) är en underhållsversion med åtgärder för fel i den föregående versionen. Flera detaljer om rättelserna finns i avsnittet

Fel som rättats i denna version

Dessutom innehåller J2SDK 1.3.1 följande förbättringar.

• Förbättringar i Java^TM-Plug-in
  I denna version ingår en förbättrad version av Java Plug-in med många nya egenskaper, som gör den flexiblare, mera lättanvänd och lättare att konfigurera. Dessutom stödjer den det nya gränssnittet Open JVM i webbläsaren Netscape 6. Mer information finns i avsnittet Nya egenskaper i Java Plug-in. Förbättringarna i Java Plug-in introducerades i uppdateringsversionen J2SDK 1.3.0_01.

• Felhanteringen i Java Virtual Machine
  De virtuella Java-maskinerna i J2SDK 1.3.1 har fått en ny mekanism för felhantering som visar felsökningsinformation på skärmen om en krasch skulle uppstå i systemberoende kod. Mer information finns i avsnittet Felhantering i J2SDK 1.3.1.

• HTML-konverterare finns nu som en del av Java 2 SDK
  HTML-konverteraren medföljer nu som en del av Java 2 SDK. I tidigare versioner, bland dem J2SDK 1.3.1 Beta, fanns HTML-konverteraren bara att hämta separat.

Om du vill läsa dokumentation om Java Plug-in, besök Webbplatsen för Java Plug-in.

Fullständig dokumentation för J2SDK 1.3.1 finns tillgänglig för hämtning . Se även det nya online-dokumentet Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.

Texten nedan innehåller information som kan vara av intresse för användare av J2SDK 1.3.1, till exempel beskrivningar av viktigare programfix, kända fel och metoder att komma runt dem, samt diverse tips och förslag för användning av denna programversion.

Följande kommentarer gäller JVM (Java Virtual Machine).

• På Linux-plattformar vaknar inte tråd som väntar på en I/O-operation om en fil involverad i I/O-operationen är stängd. Det här felet har nummer 4344135. Undvik problemet genom att ställa miljövariabeln J2SE_PREEMPTCLOSE på 1.

  J2SE_PREEMPTCLOSE=1
  export J2SE_PREEMPTCLOSE
  

• Fel 4323062: Alla Windows NT-tjänster med en inbäddad Java VM kraschar när användaren loggar ut

  Felet är åtgärdat i J2SDK 1.3.1. För att korrigeringen ska aktiveras måste kommandoradstillägget -Xrs överföras till JVM. Detta extra argument på kommandoraden behövs på grund av att korrigeringen stänger av J2SDKs mekanism för avstängningskrokar och förbjuder användning av klassen sun.misc.Signal. Mer bakgrundsinformation finns i sista avsnittet av utvärderingen av "Bug Parade":

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

• Ett JNI-fel kan få JVM att krascha när ett program har avslutats med felmeddelande liknande följande.

  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.
  

  Det här problemet uppstår för det mesta på Linux Red Hat 7.1 SMP även om det teoretisk också kan uppstå på plattformarna Microsoft Windows och Solaris.

  Åtgärd - Lägg till ett explicit avslutningsanrop i slutet på programmets huvudmetod: Runtime.getRuntime().exit(0)

• Att köra kod på Java-plattformen över en automatiskt monterad NFS på Red Hat 7.1 kan medföra frekventa krascher i dlopen() på Red Hat. Det här problemet är uppenbarligen att hänföra till NFS automounter och problemet försvinner om du explicit bygger katalogen med mount -t nfs.

Denna version har följande problem med teckensnittens egenskaper.

• Om du använder Linux Red Hat av andra versioner än 6.1 kan filen font.properties misslyckas med att visa teckensnitten System/Dingbats korrekt i vissa delar av AWT. Du rättar felet genom att använda denna reviderade font.properties-fil som ersättning för den i <JAVA_HOME>/jre/lib/.

• På grund av fel 4419794 kan font properties-filen ge varningsmeddelanden för språkområde UTF-8 på Solaris 8 (Intel-arkitektur). Om du måste använda språk inom området UTF-8 på Solaris 8 med Intel-maskinvara, måste du uppdatera systemet till Solaris 8 Update Release 4 där felet är åtgärdat.

Ett Solaris Xserver-fel kan orsaka att systemet kraschar när ett program skrivet med Java refererar till teckensnitt. Det här felet beskrivs i felrapport nummer 4391019. Följande Solaris-programfixar till Xserver blir tillgängliga i mitten på juni 2001 och de kan kanske minska problemet.

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)

Kontrollera på webbplatsen SunSolve när detta programfix är tillgängligt.

Följande viktiga förändringar har gjorts i RMI (Remote Method Invocation) till denna version.

• "accept" java.net.SocketPermission krav för att fjärranrop ska tas emot
  På grund av ett fel i tidigare J2SDK-implementeringar gick det att exportera ett fjärrobjekt i en given åtkomstmiljö och ta emot ett fjärranrop till objektet över en given sockelanslutning även om åtkomstkontrollen inte "accepterade" java.netSocketPermission för java.net.InetAddress och porten till sockelanslutningen.

  Felet har åtgärdats, varför kod som exporterar fjärrobjekt i vissa fall måste ges större behörighet än i tidigare versioner för att kunna fungera korrekt.

  Ett exempel på hur man ger sådan behörighet med filsyntaxen i den befintliga säkerhetspolicyn, behörighet att ta emot socketanslutningar från en värd kallad terrier.east.sun.com kan utföras med följande behörighetssats (i grant-posten för avsedd kodkälla):

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

  Enligt dokumentationen för java.netSocketPermission får specifikationen av värddatorn börja med jokertecken "*". Därför kan behörigheten att ta emot socketanslutningar från valfri värd uttryckas som följande behörighetssats i avsedd grant-post.

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

• Icke-exporterade fjärrobjekt får inte sitt skräp insamlat
  I tidigare versioner kunde RMI-körtidsmodulen under vissa förhållanden referera starkt till ett fjärrobjekt även efter att det uttryckligen förklarats oexporterat. Felet är åtgärdat och RMI-körtidsmodulen refererar nu aldrig till ett fjärrobjekt som uttryckligen förklarats oexporterat.

• Prestandaproblem med ersättningstabellen för ObjectOutputStream
  I tidigare versioner mindes en ObjectOutputStream -instans ersatta objekt (dvs objekt som returnerats genom ett anrop till ObjectOutputStream.replaceObject eller med en klassdefinierad writeReplace-metod) på så sätt att linjär sökning användes för att ta reda på om ett objekt hade en ersättare eller inte. Om antalet objekt som ersattes i en given ström var stort, blev det administrativa sökarbetet oerhört tidskrävande för varje nytt element som skulle serialiseras. Felet har åtgärdats så att implementationen nu använder sig av en effektivare algoritm för att komma ihåg ersättningar för objekt. Korrigeringen av objektserialiseringen är också till nytta för skalbarheten vid ersättning av objekt vid ordnande av RMI-argument och -returvärden.

Följande kommentarer gäller funktionen hos CORBA, RMI-IIOP och Java IDL i denna version.

• Hur Suns ORB och ORB från andra tillverkare fungerar tillsammans har inte provats. Suns ORB garanteras inte fungera med ORB från andra tillverkare.

• Om en J2SDK 1.3.1-server först ansluter till en J2SDK 1.3-klient, och en J2SDK 1.3.1-klient därpå försöker sända en Serializable-instans som har writeUTF eller readUTF i metoderna writeObject respektive readObject kommer ett MARSHAL-undantag att inträffa. Samma sak händer om en J2SDK 1.3.1-server först ansluter till en J2SDK 1.3.1-klient, och en J2SDK 1.3-klient därefter försöker skicka en instans med samma sorts klass. Det här felet har nummer 4434140.

  Lösning - Ändra Serializable-klassen så att den använder writeObject och readObject istället för writeUTF och readUTF.

• J2SDK 1.3 använde writeUTF- och readUTF-anrop istället för wstrings, mot CORBA-strängar. Därför kunde man inte använda dessa metoder till att skicka strängar med tecken som hade värden större än 8 bitar. Felet är åtgärdat i J2SDK 1.3.1 men vid kommunikation med J2SDK 1.3 kvarstår begränsningen. Det här felet har nummer 4379597.

  Lösning - Använd writeObject och readObject istället för writeUTF och readUTF. I både JDK 1.3.1 och J2SDK 1.3 tilldelas dessa CORBA wstring-anrop när metodens parametrar är strängar.

• Den Java ORB som medföljer J2SDK 1.3.1 innehåller rättningar som ger stöd för utvecklingsändringar i de serialiserbara klasserna, så som anges i Java Serialialization Specification.

  Tack vare detta kan J2SDK 1.3.1 och framtida versioner av J2SDK hantera klassutveckling. Om till exempel klassen V som levereras med J2SDK 1.3.1 utvecklas i en framtida version av J2SDK kan en programklient (som sänder och tar emot klass V) som exekveras på J2SDK 1.3.1 fungera tillsammans med en server (som sänder och tar emot en utvecklad klass V) som körs på en framtida version av J2SDK, och tvärtom.

  Den tidigare versionen, J2SDK 1.3.0 har dock fel som omöjliggör klassutveckling. (Se till exempel felrapport 4365188 på webbplatsen Java Developer Connection ^SM.) Därför kan det uppstå samspelsproblem om J2SDK 1.3.1 försöker sända utvecklade klasser till J2SDK 1.3.

• När du skriver kod i OMG IDL ska du inte använda ett gränssnittsnamn som namnet på en modul. Om du gör det finns det risk att du får inkonsekventa resultat vid kompilering med verktyg från olika tillverkare, och på så sätt riskerar kodens bärbarhet. Kod som innehåller samma namn kan t.ex. kompileras med IDL till Java Compiler från Sun Microsystems och ge ett resultat. Samma kod som kompileras med en annan tillverkares IDL till Java Compiler kan ge ett annat resultat.

Fel nummer 4178909 i Java 2D^TM -biblioteken gör ibland att program inte visas korrekt i när de körs i 8-bitarsläge. Felet bör visa sig endast första gången programmet körs efter en omstart, eller när grafiken ställts om till 8-bitarsläge.

Det finns även några fel som relaterar till DirectDraw. Om du får fel som relaterar till DirectDraw kan du inaktivera DirectDraw:

-Dsun.java2d.noddraw=true

Några bildskärmsdrivrutiner gör att bildskärmen, inklusive fönster, verkar synkroniseras om eller hoppa när du använder DirectDraw. Om detta inträffar går du till tillverkarens webbplats och letar efter en senare drivrutin som kan åtgärda det här felet.

Operativsystemet Java stöder inte bildskärmsvisning av 16 färger. Om du upplever det här felet när du ritar grafik och GUI-komponenter på en bildskärm med 16 färger, försöker du ändra antalet färger till 256 färger eller fler.

Följande funktioner har implementerats och fungerar, men har inte testats fullständigt och stöds inte i den här versionen.

• Dra- och släppöverföringar av:
  • Java-utvecklade och/eller användardefinierade datatyper
  • Instanser av godtyckliga klasser som laddats av distinkta ClassLoader-instanser inom samma JVM*
  • Serialiserade Java-objekt mellan JVM-instanser (eller ClassLoader-instanser)
• Länkning av RMI java.rmi.Remote-delgränssnitt mellan JVM-instanser

AWT- och Swing-komponenter har inre klasser som implementerar Java Accessibility API och ger rätt hjälpmedelstöd för komponenterna. Hjälpmedelstöd för AWT-klasser har emellertid inte fullständigt implementerats i den här versionen:

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

Fullständigt hjälpmedelstöd för alla komponenter kommer att implementeras i framtida versioner av operativsystemet Java 2.

Följande kommentarer gäller funktionen hos AWT och Swing i denna version.

• Ett program som anropar den statiska metoden Toolkit.getDefaultToolkit kommer inte att avslutas och återgå till kommandoprompten. Det här felet har numren 4030718 och 4403762 och kommer att vara åtgärdat i J2SDK 1.4.0 Beta.

  Lösning - Anropa System.exit() när programmet är avslutat.

• Den nya metoden Component.getListeners() kan inte returnera PropertyChangeListeners. Om du har lagt till en lyssnare med addPropertyChangeListener(),

  myComponent.getListeners(PropertyChangeListener.class)
  

  returneras en tom matris.

• Fel 4199374 gäller ett problem med hantering av fokus för JWindow-objekt. Notera särskilt att felet förhindrar Component.requestFocus() att lämna över fokus till komponenterna i ett JWindow. Felet var åtgärdat i uppdateringsversionerna J2SDK 1.2.2_05 och J2SDK 1.3.0_02, men är inte åtgärdat i J2SDK 1.3.1.

På Windows NT stöder JDBC 2.0-bryggan drivrutinshanteraren och drivrutinerna till ODBC 2.x och ODBC 3.x. JDBC 2.0-bryggan har enbart testats med en ODBC 3.x-drivrutinshanterare och med både ODBC 2.x- och 3.x-drivrutiner.

Merant rekommenderar att JDBC 2.0-bryggan används med version 3.5 eller senare av Merants DataDirect ODBC-drivrutiner.

Följande säkerhetsrelaterade frågor gäller för den här versionen.

Verktyget jarsigner kan bekräfta filer som signerats av Netscape SignTool 1.3 om de kodsignerande certifikaten inte är självsignerade. Obs! Du kan få självsignerande certifikat från VeriSign^TM. De här certifikaten kommer från VeriSign. De är inte självsignerade.

Netscape SignTool 1.3 placerar inte certifikat i signaturfilen om det kodsignerande certifikatet inte är självsignerat och jarsigner inte kan bekräfta en signerad JAR-fil om signaturfilen inte innehåller signerarens certifikat. Obs! Det kodsignerande certifikatet som skapas av SignTool 1.3 själv är enbart för test, och är inte självsignerat. Det är ett känt fel att jarsigner inte kan bekräfta en JAR-fil som signerats av Netscape SignTool 1.3 om det kodsignerande certifikatet inte är ett självsignerat testcertifikat.

I Java 2 SDK laddas programklasser av en faktisk ClassLoader-instans. Detta gör det möjligt för programklasser att använda installerade filtillägg och separerar dessutom programklassens sökväg, som anges av användaren, från bootstrap-klassens sökväg, som är fast och normalt inte ska ändras av användaren. Alternativet -Xbootclasspath kan användas för att åsidosätta bootstrap-klassens sökväg om det behövs.

Det innebär emellertid att programklasser i Java 2 SDK inte längre har alla behörigheter som standard. I stället tilldelas de behörigheter baserat på systemets konfigurerade säkerhetspolicy. De kan få vissa program att skriva sin egen säkerhetskod baserat på den ursprungliga säkerhetsmodellen i 1.0/1.1 för att signalera ett undantag och inte starta i Java 2 SDK. Ett sätt att kringgå detta är att köra de här programmen med programstartaren oldjava vilket dokumenteras på referensidan för java-programstartaren.

I följande punkter summeras frågorna som relaterar till säkerhetspolicy och signering.

• Implementeringen av säkerhetspolicyn som är standard på Java 2-plattformen är specificerad av egenskapen policy.provider i Java-filen med säkerhetsegenskaper, jre/lib/security/java.security. Om du anger en implementation av säkerhetspolicyn som inte är standard, måste du lägga in din fil med nya säkerhetsegenskaps-klasser i bootclasspath. Det gör du med hjälp av kommandoradsparametern -Xbootclasspath. Mer information om detta kommandoradsargument finns på sidan Java application launcher reference page. Därigenom kommer policyfilen att laddas av den självstartande klassladdaren. Om den nya standardpolicyfilen placeras någon annanstans, t.ex. i klassökvägen eller i ett filtillägg, plockas den inte upp och standardpolicyn som anges i sun.security.provider.PolicyFile används i stället.

• Från och med version 1.2.2 använder Java 2 SDK en ny mekanism för klassladdning. Om en klassfil som tillhör ett paket i Java signeras, måste - under den nya klassladdaren - alla klassfiler som tillhör samma paket ha signerats av samma signerare. Det går inte längre att använda en Jar-fil där några klasser i ett paket har signerats och andra är osignerade eller har signerats av en annan signerare. Jar-filer kan fortfarande innehålla paket som är osignerade. Om några paket innehåller signerade klasser, måste emellertid alla klassfiler i det paketet ha signerats av samma signerare. Befintliga Jar-filer som inte svarar mot detta kriterium kan inte användas med den här versionen av operativsystemet Java 2.

Verktyget keytool kan för närvarande importera eller skriva ut ett Base64-kodad certifikat från en fil enbart om filen avslutas av en ny rad (radmatning). Om det inte finns en radmatning i slutet av certifikatfilen och du försöker importera eller skriva ut certifikatet, får du ett certifikatundantag eller ett keytool-felmeddelande om "Unsupported encoding", t.ex. "Failed to parse input" eller "Input not an X.509 certificate."

Om du får ett sådant felmeddelande eller undantag, kan felet vara att det saknas en avslutande radmatning. En orsak till att detta kan inträffa är att ibland innehåller inte ett certifikatsvar från en certifikatauktoritet (som svar på en begäran om certifikatsignering) en avslutande radmatning.

I UNIX kan du bestämma om en fil har en avslutande radmatning genom att köra följande kommando:

    od -xc <certifikatnamn>

där <certifikatnamn> är namnet på filen som innehåller certifikatet. Om en fil t.ex. har namnet mycert skulle kommandot bli

    od -xc mycert

Om den resulterande utskriften innehåller ett "\n" (utan citattecken) i slutet, finns det redan en radmatning i slutet. Om inte, kan du lägga till en radmatning.

Om du är osäker på om certifikatfilen innehåller en avslutande radmatning, kan du helt enkelt lägga till en efter det sista stycket (det skadar aldrig med en extra) och försöka kommandot -import eller -printcert igen. Om kommandot fungerar, var felet en saknad radmatning. Om du fortfarande får ett felmeddelande, är det något annat fel med certifikatet.

Om du vill lägga till en radmatning i slutet av en Base64-kodad certifikatfil, öppnar du filen i en textredigerare, placerar markören i slutet av filen och lägger till en radmatning (eller en hård radretur), genom att t.ex. trycka på Enter-tangenten på tangentbordet.

Nätverk

Den här versionen har följande kända fel och begränsningar i programmeringsgränssnittet (API) för nätverket:

• På Windows 2000 kan program som skickar datagram få en oväntad SocketException, som anger att socketen var stängd. Det beror på att Windows 2000 uppför sig på ett nytt sätt när det fjärranslutna programmet inte är tillgängligt. En tillfällig metod att gå runt problemet är att skapa om DatagramSocket. Det här felet har nummer 4361783.

• I J2SDK 1.3.0 introducerades en implementation av en HTTP/1.1-klienten. Webbservrar som Apache returnerar paket av kodade svar till HTTP 1.1-klienter, men hanteringen av kodade paket i J2SDK 1.3.0 och 1.3.1 kan inte strömma svarspaketen från servern. I praktiken betyder det att metoder som java.net.URLConnection.getInputStream inte ger någon retur förrän serverns svar är avslutat. Det här felet har nummer 4333920.
  Lösning: Lösningen för Apache är att lägga in följande rad i httpd.conf .

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

• HTML 4.0-specifikationen rekommenderar att icke ASCII-tecken i URI:er (Uniform Resource Identifier) ska kodas i ett eller flera UTF-8-byte. Flera befintliga CGI-skript hanterar icke ASCII-tecken genom att använda byte från kodningen som ett dokument tas emot i. Klasserna URLEncoder och URLDecoder stöder emellertid inte någon av de här metoderna att hantera icke ASCII-tecken i URI:er. I stället ersätter de här klasserna ett eller flera byte för tecknen enligt definitionen i det underliggande operativsystemets standardkodning. Det här är fel 4257115.

• Ett anrop till metoden HttpURLConnection.getResponseCode på klienten kan få den virtuella maskinen att krascha om det finns extra radmatningar i HTTP-huvudet som skickas av en Win98- eller WinNT-server. Det här är fel 4258697.
  Lösning: Du kan undvika spill i stacken genom att konfigurera http-servern till att skicka svar av typen HTTP 1.0. Lösningen för Apache är att lägga in följande rad i httpd.conf.

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

Om programmet använder nätverksklasserna, kan det inte köras helt pålitligt med Winsock 1.1. Om nätverksprogrammet måste stödja Windows 95, som innehåller Winsock 1.1, bör användarna av programmet ha Winsock 2.0. (Windows NT 4.0, Windows 2000, Windows ME och Windows 98 innehåller Winsock 2.0.) Du kan hämta Winsock 2.0 från den här adressen:

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

Följande Internet-adress innehåller information om hur du avgör om Winsock 2.0-komponeterna har installerats på Windows 95:

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

Utan uppgraderingen av Winsock kan InetAddress.getByName orsaka en krasch i kernel32.dll om en namnuppslagning skulle misslyckas. Mer information om detta fel finns på Microsofts webbplats.

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

Komponenten Java^TM Plug-in

Följande kommentarer gäller komponenten Java Plug-in i denna version.

• På Linux-plattformar kan inte flera kopior av ett miniprogram skrivas ut från webbläsaren. Läsaren måste stängas och startas om för varje utskrift efter den första. Det här felet har felnummer 4450194.

• När du installerar tillägg via komponenten Java Plug-in, kommer användaren att få en varningsruta om detta faktum. Om användaren klickar på knappen "Deny" (vägra) kan det hända att varningsrutan inte försvinner och användaren tvingas godkänna eller vägra installationen av samma tillägg om igen. Felet kommer att åtgärdas i en kommande version.

• I version 1.3.0_01 ändrades signaturverifieringen till att använda den 'cert CA store' som medföljer Sun Javas körtidsmiljö, istället för den store som medföljer Microsoft Internet Explorer. Ändringen gjordes eftersom den 'cert store' som finns i Internet Explorer inte fungerar för miniprogram som körs i webbläsare från Netscape. Ytterligare kod för felhantering har införts i version 1.3.1 för att ta hand om signaturer som inte kunnat verifieras. Detta fel har nummer 4424604.

Information om lokalanpassning

Allmän information om stödet för andra språk än engelska finns i avsnittet Localization Notes.

Dokumentation

Följande kommentarer gäller för dokumentationen till den här versionen.

• På grund av fel 4459595 innehåller sidan Serialiserad form i API-specifikationen till den här versionen en del brutna länkar till privata och paketprivata klasser.

• Se även det nya online-dokumentet Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.

Verktyg kan inte konvertera japanska PCK-strängar på Solaris 2.6

Ett fel inträffade vid användning av japanska strängar som argument i java-kommandot på Solaris 2.6 ja_JP.PCK. Åtgärda det här problemet genom att ändra rad 89 /usr/java/bin/.java_wrapper från

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

till

exec $DEBUG_PROG $prog $opts $@

Fel på text på traditionell kinesiska

I denna version finns följande kända problem med teckensnitt för traditionell kinesiska.

• Microsoft Windows 95 för traditionell kinesiska version 2.0 innehåller inte de teckensnitt för traditionell kinesiska som angivits i Java 2 SDK:s egenskaper för teckensnittsfiler. Om du använder Java 2 SDK eller Java 2 Runtime Environment i det operativsystemet, blir resultatet varningsmeddelanden om "teckensnitt hittas inte" och texten kanske inte visas rätt. Det här felet finns inte på nyare Microsoft Windows 95 för traditionell kinesiska version 2.0 andra utgåvan från oktober 1996, som innehåller de angivna teckensnitten.

• I miljön för traditionell kinesiska i Microsoft Windows 95 visas kinesiska tecken på ett felaktigt sätt i Swing-komponenter. Mer information om felet finns i felrapporten 4431319 på webbplatsen Java Developer Connection ^SM.

Version 1.3.1 av Java 2 SDK stöds på Windows 2000 Professional, Windows 2000 Server och på Windows 2000 Advanced Server inom det engelska språkområdet. DataCenter-utgåvan av Windows 2000 stöds inte. I språkområden andra än engelska stöds bara Windows 2000 Professional Edition. Följande fel är kända i Windows 2000:

• Windows 2000 och stöd för flera bildskärmar - Funktionen för flera bildskärmar fungerar ännu inte fullständigt på operativsystemet Windows 2000. I synnerhet fungerar endast 256 färger rätt om alla bildskärmar har ställts in till 256 färger. 16-bitar (eller högre) färger rekommenderas starkt.

• Om du ser följande felmeddelande i Windows 2000 under installationen

     config.nt. Systemfilen lämpar sig inte för att köra MS-DOS- 
     och Microsoft Windows-program.
  

  anger det att ett fel på filen %SystemRoot%\System32\COMMAND.COM har upptäckts vid vissa installationer av Windows 2000. Om du träffar på det här felmeddelandet när du försöker starta installationsprogrammet, kan du gå till Microsofts webbplats på

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

  för att få mer information om hur du ska lösa felet.

• En process hänger sig - Ett program kan hänga sig på grund av ett dödläge i Ntdll i operativsystemen Microsoft Windows 2000 Professional, Server och Advanced Server. Felet kan till exempel uppstå i program som använder sig av in- och ut-strömmar med java.lang.Process -objekt. Mer information finns på Microsofts webbplats Support Services, tillsammans med ett programfix:

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

Installation på Windows NT

När du installerar version 1.3.1 av Java Runtime Environment placerar du ActiveX-filen med kontroller i C:\Winnt\Downloaded Program Files\Java Runtime Environment 1.3.1 får status "Damaged" (Skadad). Det här är bara en kosmetisk fråga och status som "damaged" får inte någon skadlig effekt i någon situation.

Det finns i alla fall ett sätt att komma runt det här problemet om statusen inte får vara "Damaged". Gå till "Start -> Kör" och skriv "regedit". Navigera till registernyckeln "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code" i fönstret Registereditorn. Lagra Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation". Dubbelklicka på INF-strängen och ta bort den markerade strängen under "Data". Filen med ActiveX-kontroller får statusen "Installerad."

Copyright (c) 2001 Sun Microsystems, Inc. Med ensamrätt.