Note di rilascio JavaTM 2 SDK Standard Edition Versione 1.3.1

Sommario

Introduzione
Macchina virtuale Java
Proprietà dei caratteri
Problema di Xserver su Solaris
RMI
CORBA, RMI-IIOP e Java IDL
Tecnologia Java 2D^TM
Trascinare e rilasciare
Accessibilità
AWT e Swing
JDBC
Sicurezza
Networking
Componente Java^TM Plug-in
Note di localizzazione
Documentazione
Non è possibile convertire stringhe PCK giapponesi con Solaris 2.6
Problemi relativi ai caratteri del cinese tradizionale
Supporto per Windows 2000
Installazione su Windows NT

Java 2 SDK Standard Edition versione 1.3.1 (J2SDK 1.3.1) è una release di manutenzione contenente alcune correzioni per i problemi identificati nelle versioni precedenti. Per ulteriori dettagli su tali correzioni, vedere

Problemi corretti in questa release

Inoltre J2SDK 1.3.1 contiene i seguenti miglioramenti:

• Miglioramenti a Java^TM Plug-in
  Questa release include il prodotto Java Plug-in migliorato con una serie di nuove funzioni che lo rendono più flessibile e semplice da utilizzare e configurare, oltre a consentire il supporto delle nuove funzioni Open JVM Interface del browser Netscape 6. Per ulteriori informazioni, vedere Nuove funzionalità di Java Plug-in (informazioni in inglese). Questi miglioramenti del prodotto Java Plug-in sono stati introdotti nella release di aggiornamento J2SDK 1.3.0_01.

• Funzione di gestione degli errori nella macchina virtuale Java
  Le macchine virtuali Java in J2SDK 1.3.1 dispongono di un nuovo meccanismo di gestione degli errori che stampa le informazioni di debug visualizzate quando si verifica un crash nel codice nativo. Per ulteriori informazioni, vedere Gestione degli errori in J2SDK 1.3.1 (informazioni in inglese).

• HTML Converter ora contenuto in Java 2 SDK
  HTML Converter è ora contenuto in Java 2 SDK, mentre nelle release precedenti, compresa la versione Beta J2SDK 1.3.1, era disponibile solo come download separato.

Per una documentazione sul prodotto Java Plug-in, visitare il sito Web Java Plug-in (informazioni in inglese).

Una documentazione completa per J2SDK 1.3.1 è disponibile per il download. Vedere anche il nuovo documento in linea Tuning Garbage Collection with the 1.3.1 Java Virtual Machine (informazioni in inglese).

Le note riportate di seguito contengono informazioni che possono rivelarsi utili per gli utenti di J2SDK 1.3.1, tra cui la descrizione delle correzioni degli errori più significativi, dei problemi noti e delle relative soluzioni, nonché altri suggerimenti e consigli vari per l'utilizzo di questa release.

Le note seguenti si riferiscono alla macchina virtuale Java.

• Sulle piattaforme Linux, un processo in attesa di I/O non viene riattivato se un file coinvolto nell'operazione di I/O è chiuso. Questo problema è identificato dal numero 4344135. Per evitare questo problema, impostare la variabile di ambiente J2SE_PREEMPTCLOSE a 1.

  J2SE_PREEMPTCLOSE=1
  export J2SE_PREEMPTCLOSE
  

• Problema 4323062: i servizi Windows NT che incorporano la macchina virtuale Java vengono interrotti in maniera anomala quando l'utente si disconnette.

  Questo problema è stato risolto in J2SDK 1.3.1. Per abilitare la correzione, è necessario passare alla macchina virtuale Java l'opzione della riga di comando -Xrs. Questo argomento aggiuntivo della riga di comando è necessario in quanto la correzione disabilita il meccanismo degli hook di arresto di J2SDK 1.3 e impedisce l'utilizzo della classe sun.misc.Signal. Per ulteriori informazioni, vedere almeno l'ultima sezione dedicata alla valutazione in Bug Parade (informazioni in inglese):

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

• Un problema alla JNI può comportare un arresto anomalo della macchina virtuale Java al termine dell'attività di un programma, con un messaggio di errore simile a quello illustrato di seguito.

  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.
  

  Si tratta di un problema che si verifica con maggior frequenza su Linux Red Hat 7.1 SMP, ma in teoria potrebbe verificarsi anche su piattaforme Microsoft Windows e Solaris.

  Soluzione - Aggiungere una chiamata di uscita esplicita al termine del metodo main dell'applicazione: Runtime.getRuntime().exit(0)

• L'esecuzione di codice nella piattaforma Java su file system di rete (NFS) automontati su Red Hat 7.1 può comportare frequenti arresti anomali del sistema in dlopen() su Red Hat. Questo problema è probabilmente causato dall'applicazione di automontaggio del file system di rete NFS e può essere eliminato se la directory viene montata esplicitamente utilizzando mount -t nfs.

Questa release presenta i seguenti problemi relativi alle proprietà dei caratteri.

• Quando si utilizza una versione di RedHat Linux diversa dalla 6.1, il file font.properties può non riuscire a visualizzare correttamente alcuni caratteri Symbol/Dingbat in alcuni componenti AWT. Per correggere il problema, sostituire la versione presente nella directory <JAVA_HOME>/jre/lib/ con versione rivista del file font.properties contenuta in questa release.

• A causa del problema 4419794, le proprietà dei caratteri possono generare messaggi di avviso per le impostazioni internazionali UTF-8 su Solaris 8 (architettura Intel). Se è necessario utilizzare le impostazioni internazionali UTF-8 su Solaris 8 in un'architettura Intel, aggiornare il sistema a Solaris 8 Update Release 4, in cui questo problema è stato risolto.

Un problema di Xserver su Solaris può causare il blocco del sistema quando un'applicazione scritta utilizzando il linguaggio di programmazione Java fa riferimento a dei caratteri. Questo problema è identificato dal numero 4391019. Le seguenti patch di Solaris per Xserver saranno disponibili entro la metà di giugno 2001 e consentiranno di limitare questo problema.

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

Controllare il sito Web SunSolve (informazioni in inglese) per la disponibilità di queste patch.

Di seguito sono descritte le modifiche più importanti apportate alla funzionalità RMI (Remote Method Invocation) in questa release.

• Requisito "accept" java.net.SocketPermission per ricevere le chiamate remote
  A causa di un problema, nelle precedenti implementazioni J2SDK era possibile esportare un oggetto remoto in un determinato contesto di controllo dell'accesso, quindi ricevere una chiamata remota a tale oggetto tramite una connessione socket, anche se il contesto di controllo dell'accesso non disponeva dell'autorizzazione "accept" java.netSocketPermission per il java.net.InetAddress remoto e per la porta della connessione socket.

  Questo problema è stato risolto, e pertanto in alcuni casi potrebbe essere necessario che il codice che esporta gli oggetti remoti disponga di ulteriori autorizzazioni rispetto a quelle richieste nelle precedenti implementazioni per il suo corretto funzionamento.

  Come esempio di concessione di queste autorizzazioni utilizzando la sintassi del file delle policy di sicurezza predefinite, l'autorizzazione per accettare connessioni socket da un host denominato terrier.east.sun.com può essere espressa dalla seguente voce di autorizzazione (nella voce di concessione permessi per il codice sorgente appropriato):

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

  Come descritto nella documentazione per java.netSocketPermission, la specifica dell'host può iniziare con un carattere jolly "*"; pertanto l'autorizzazione ad accettare connessioni socket per qualsiasi host può essere espressa dalla seguente voce di autorizzazione contenuta in una data voce di concessione permessi:

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

• Oggetti remoti esportati e deallocati ma non raccolti dal processo di recupero spazio
  Nelle precedenti implementazioni, in certi casi il runtime RMI (Remote Method Invocation) faceva riferimento a un oggetto remoto anche dopo l'esplicita deallocazione di tale oggetto. Questo problema è stato corretto in modo che il runtime RMI non possa fare riferimento a un oggetto remoto che è stato esplicitamente deallocato.

• Prestazioni della tabella di sostituzione ObjectOutputStream
  Nelle precedenti implementazioni un'istanza ObjectOutputStream memorizzava gli oggetti sostituiti (gli oggetti restituiti da una chiamata a ObjectOutputStream.replaceObject o da un metodo writeReplace definito da una classe) in modo da utilizzare una ricerca lineare per determinare se un oggetto presentava o meno un sostituto. Pertanto, in presenza di un elevato numero di oggetti sostituiti in un dato stream, l'overhead della ricerca diventava estremamente elevato per ciascun nuovo oggetto serializzato. Questo errore è stato corretto in modo da utilizzare un algoritmo più efficiente per memorizzare le sostituzioni degli oggetti. Questa correzione all'implementazione della serializzazione degli oggetti migliora anche la scalabilità della sostituzione degli oggetti durante il marshalling degli argomenti RMI e dei valori restituiti.

I commenti riportati di seguito si riferiscono alle funzionalità CORBA, RMI-IIOP e Java IDL in questa release.

• L'ORB Sun non è stato sottoposto a verifiche di interoperabilità con gli ORB di altri fornitori, pertanto non se ne garantisce tale tipo di funzionamento.

• Se un server J2SDK 1.3.1 si connette inizialmente a un client J2SDK 1.3 e quindi un client J2SDK 1.3.1 tenta di inviare un'istanza Serializable che utilizza writeUTF o readUTF nei propri metodi writeObject o readObject, si verificherà un'eccezione di MARSHAL. Allo stesso modo, se un server J2SDK 1.3.1 si connette con un client J2SDK 1.3.1 e quindi un client J2SDK 1.3 tenta di inviare un'istanza dello stesso tipo di classe, si verificherà un'eccezione di MARSHAL. Questo problema è identificato dal numero 4434140.

  Soluzione - Modificare la classe Serializable affinché utilizzi writeObject e readObject anziché writeUTF e readUTF.

• J2SDK 1.3 associava le chiamate writeUTF e readUTF a stringhe CORBA anziché a wstring. Pertanto era impossibile utilizzare questi metodi per l'invio di stringhe con caratteri i cui valori erano superiori a 8 bit. Il problema è stato risolto in J2SDK 1.3.1, ma continua a presentarsi durante la comunicazione con J2SDK 1.3. Questo problema è identificato dal numero 4379597.

  Soluzione - Utilizzare writeObject e readObject anziché writeUTF e readUTF. Sia JDK 1.3.1 che J2SDK 1.3 associano questi metodi alle chiamate wstring di CORBA quando i parametri del metodo sono stringhe.

• L'ORB Java fornito con J2SDK 1.3.1 contiene le correzioni per supportare le modifiche evolutive alle classi serializzabili come specificato in Java Serialialization Specification (informazioni in inglese).

  Grazie a questo supporto, J2SDK 1.3.1 e le future release J2SDK saranno in grado di gestire l'evoluzione delle classi. Se ad esempio una classe V fornita in J2SDK 1.3.1 subirà un'evoluzione in una futura release J2SDK, un'applicazione client (che invia o riceve la classe V evoluta) in esecuzione su J2SDK 1.3.1 sarà in grado di interagire con il server (che riceve o invia la classe V evoluta) in esecuzione sulla release J2SDK futura e viceversa.

  Tuttavia, la precedente release J2SDK 1.3.0 presenta dei problemi che impediscono l'evoluzione delle classi (vedere in proposito il rapporto relativo al problema 4365188 sul sito Web Java Developer Connection ^SM). Si verificheranno pertanto problemi di interoperabilità qualora J2SDK 1.3.1 tenti di inviare qualsiasi classe evoluta a J2SDK 1.3.

• Durante la scrittura del codice in OMG IDL, non usare il nome di un'interfaccia come nome di modulo; in tal caso è possibile che si ottengano risultati incoerenti durante la compilazione con strumenti di altri fornitori, compromettendo così la portabilità del codice. Ad esempio, codice contenente gli stessi nomi può essere compilato con il compilatore IDL to Java di Sun Microsystems e dare un risultato; lo stesso codice, compilato con il compilatore IDL to Java di un altro fornitore, può produrre un risultato diverso.

Il problema 4178909 delle librerie Java 2D ^TM impedisce talvolta alle applicazioni di essere visualizzate correttamente se eseguite in modalità a 8 bit. Questo problema dovrebbe verificarsi solo la prima volta che si esegue un'applicazione dopo il riavvio o dopo l'impostazione della modalità di visualizzazione a 8 bit.

Esistono anche alcuni problemi relativi a DirectDraw. In caso si verifichi un problema di questo genere, è possibile considerare la disattivazione di DirectDraw:

-Dsun.java2d.noddraw=true

Alcuni driver video possono causare un'apparente risincronizzazione o salto delle immagini del monitor, incluse le finestre, quando si accede a DirectDraw. Se ciò si verifica, consultare il sito Web del produttore del video per una versione più aggiornata del driver in grado di risolvere il problema.

La piattaforma Java non supporta la visualizzazione a 16 colori. Se si riscontrano problemi in fase di disegno degli elementi grafici e dei componenti della GUI con uno schermo a 16 colori, provare a modificare l'intensità del colore scegliendo la modalità a 256 colori o superiore.

Le seguenti funzionalità sono implementate e operative, ma non sono state completamente testate e non sono supportate da questa release.

• Trascinamento e rilascio di:
  • tipi di dati nativi della piattaforma e/o definiti dall'utente
  • istanze di classi arbitrarie, caricate da istanze ClassLoader distinte all'interno della stessa JVM*
  • Oggetti Java serializzati tra JVM (o ClassLoader) diversi
• Collegamento di sotto-interfacce java.rmi.Remote RMI tra JVM diverse

I componenti Swing e AWT dispongono di classi interne che implementano le API Java Accessibility e forniscono un supporto di accessibilità appropriato per i componenti. Tuttavia, tale supporto per le seguenti classi AWT non è completamente implementato in questa release:

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

Il supporto di accessibilità completo per tutti i componenti sarà implementato in una successiva release della piattaforma Java 2.

Quanto riportato di seguito si riferisce alle funzionalità AWT e Swing di questa release.

• Un programma che chiama il metodo statico Toolkit.getDefaultToolkit non viene terminato e ritorna al prompt dei comandi. Questo problema è identificato dai numeri 4030718 e 4403762 e verrà corretto nella versione J2SDK 1.4.0 Beta.

  Soluzione: chiamare System.exit() una volta terminata l'applicazione.

• Il nuovo metodo Component.getListeners() non è in grado di restituire PropertyChangeListeners. Se è stato aggiunto un ascoltatore con addPropertyChangeListener() ,

  myComponent.getListeners(PropertyChangeListener.class)
  

  restituirà un array vuoto.

• Il problema 4199374 riguarda un problema di gestione dello stato attivo con gli oggetti JWindow. In particolare, questo problema impedisce a Component.requestFocus() di assegnare lo stato attivo ai componenti in un oggetto JWindow. Questo problema è stato corretto nelle release di aggiornamento J2SDK 1.2.2_05 e J2SDK 1.3.0_02, mentre non è stato risolto nella release J2SDK 1.3.1.

Su Windows NT, il bridge JDBC 2.0 supporta il gestore dei driver e i driver ODBC 2.x e ODBC 3.x. Il bridge JDBC 2.0 è stato testato solo con il gestore dei driver ODBC 3.x e con i driver di ODBC 2.x e 3.x.

Merant consiglia di utilizzare il bridge JDBC 2.0 con la versione 3.5 o superiore dei driver ODBC DataDirect di Merant.

Le seguenti problematiche relative alla sicurezza fanno riferimento a questa release.

L'utilità jarsigner può verificare i file firmati da Netscape SignTool 1.3, se i certificati di firma codice non sono autofirmati. Nota: è possibile ottenere i certificati ufficiali di firma codice di Netscape da VeriSign^TM; tali certificati sono emessi da VeriSign e non sono autofirmati.

Netscape SignTool 1.3 non colloca i certificati nel file di firma se il certificato di firma codice è autofirmato e jarsigner non è in grado di verificare un file JAR firmato se il file di firma non contiene il certificato del firmatario. Nota: il certificato di firma codice generato dallo stesso SignTool 1.3 è a titolo di prova ed è autofirmato. È risaputo che jarsigner non può verificare un file JAR firmato da Netscape SignTool 1.3 se il certificato di firma codice è autofirmato.

In Java 2 SDK, le classi delle applicazioni sono caricate da un'istanza ClassLoader, che consente alle classi di utilizzare le estensioni installate e che inoltre separa il percorso delle classi stesse, specificato dall'utente, dal percorso delle classi di bootstrap, normalmente fisso e non modificabile dall'utente. Se necessario, è possibile utilizzare l'opzione Xbootclasspath per ignorare il percorso delle classi di bootstrap.

Tuttavia, ciò significa che in Java 2 SDK le classi delle applicazioni non dispongono più per default di tutti i permessi, ma tali permessi vengono accordati in base alla policy di sicurezza configurata nel sistema. Come conseguenza, alcune applicazioni che scrivono il proprio codice di sicurezza in base al modello di sicurezza originale di 1.0/1.1 potrebbero lanciare un'eccezione e non avviarsi in Java 2 SDK. Una soluzione è avviare tali applicazioni con l'utilità di avvio applicazioni oldjava , documentata alla pagina di riferimento per l'utilità di avvio applicazioni di java.

Le seguenti note forniscono un sommario delle questioni legate alle policy di sicurezza e alla firma.

• L'implementazione delle policy di protezione predefinite utilizzate dalla piattaforma Java 2 viene specificata dalla proprietà policy.provider nel file delle proprietà di protezione Java jre/lib/security/java.security. Se viene specificata un'implementazione delle policy di protezione non predefinita, sarà necessario spostare il nuovo file non predefinito delle classi di proprietà di protezione nel percorso bootclasspath. utilizzando l'opzione della riga di comando -Xbootclasspath. Ulteriori informazioni su questa opzione sono disponibili alla pagina di riferimento per l'utilità di avvio applicazioni di Java. In questo modo il file della policy verrà caricato dal caricatore delle classi di bootstrap. Se si trova altrove, ad esempio nel percorso delle classi o in un'estensione, il file della nuova policy predefinita non verrà caricato e al suo posto verrà utilizzata la policy predefinita fornita da sun.security.provider.PolicyFile .

• A partire dalla versione 1.2.2, Java 2 SDK utilizza un nuovo meccanismo di caricamento delle classi. Con il nuovo caricatore delle classi, se uno dei file di classe appartenente a un package di un file Jar è firmato, tutti i file di classe dello stesso package dovranno avere la stessa firma. Non è più possibile utilizzare un file Jar in cui alcune classi di un package sono firmate e altre no, oppure presentano firme diverse. I file Jar possono ancora contenere package senza firma: tuttavia, se un package contiene classi firmate, tutti i file di classe di quel package devono presentare la stessa firma. I file Jar esistenti che non soddisfano questo requisito non potranno essere utilizzati in questa versione della piattaforma Java 2.

Lo strumento keytool può attualmente importare o stampare un certificato codificato Base64 da un file solo se questo file termina con un ritorno a capo (linefeed). In caso contrario, se si tenta di importare o stampare il certificato, si otterrà la CertificateException "Unsupported encoding" (codifica non supportata) o un messaggio di errore di keytool come "Failed to parse input" (Impossibile analizzare l'input) o "Input not an X.509 certificate" (È stato immesso un certificato non X.509).

In questi casi, il problema consiste probabilmente nella mancanza del ritorno a capo finale; uno dei motivi per cui ciò potrebbe verificarsi è che, a volte, il certificato ottenuto da un'autorità di certificazione (in risposta a una richiesta di firma certificato - Certificate Signing Request) non contiene un ritorno a capo finale.

In UNIX è possibile determinare se un file termina con un ritorno a capo eseguendo il seguente comando:

    od -xc <nome_certificato>

dove <nome_certificato> è il nome del file contenente il certificato. Ad esempio, se il nome del file fosse certif il comando sarebbe

    od -xc certif

Se l'output ottenuto contiene un "\n" (senza virgolette) alla fine, significa che il file termina con un ritorno a capo; in caso contrario, sarà possibile aggiungerlo.

Se non si è certi dell'esistenza di un ritorno a capo finale nel file del certificato, è possibile aggiungerne uno al paragrafo successivo (eventuali duplicati non causano alcun problema) ed eseguire nuovamente il comando -import o -printcert. Se il comando funziona, il problema era generato dalla mancanza del ritorno a capo; se si ottiene ancora un errore, significa che il certificato presenta un problema diverso.

Per aggiungere un ritorno a capo finale a un file di certificato con codifica Base64, aprire il file con un qualsiasi editor di testi, posizionare il cursore alla fine del file e aggiungere semplicemente un ritorno a capo premendo Invio sulla tastiera.

Networking

Questa release presenta i seguenti problemi e limiti delle API di networking:

• In Windows 2000 le applicazioni dei datagrammi possono ricevere un'eccezione SocketException imprevista che indica che il socket è chiuso: ciò dipende dal nuovo comportamento di Windows 2000 quando l'applicazione remota non è disponibile. Una potenziale soluzione consiste nel chiudere e ricreare DatagramSocket. Questo problema è identificato dal numero 4361783.

• J2SDK 1.3.0 ha introdotto un'implementazione client HTTP/1.1. I server Web come Apache restituiscono risposte con codifica chunked ai client HTTP 1.1, ma la gestione della codifica chunked di J2SDK 1.3.0 e 1.3.1 non trasmette la risposta chunked dal server. In pratica questo significa che i metodi come java.net.URLConnection.getInputStream non restituiscono alcun valore finché la risposta del server non è terminata. Questo problema è identificato dal numero 4333920.
  Soluzione: per Apache la soluzione consiste nell'inserire il codice seguente in httpd.conf.

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

• La specifica HTML 4.0 consiglia di codificare i caratteri non ASCII negli URI (Uniform Resource Identifiers) in uno o più byte UTF-8. Molti script CGI esistenti gestiscono i caratteri non ASCII utilizzando i byte nella codifica in cui è ricevuto il documento; tuttavia le classi URLEncoder e URLDecoder non supportano nessuno di questi metodi di gestione dei caratteri non ASCII negli URI, ma sostituiscono ai caratteri uno o più byte, come definito nella codifica predefinita della piattaforma sottostante. Questo problema è identificato dal numero 4257115.

• La chiamata al metodo HttpURLConnection.getResponseCode effettuata sul client può causare il crash della macchina virtuale quando ci sono troppi CR nel campo intestazione HTTP inviato da un server su Windows 98 o Windows NT. Questo problema è identificato dal numero 4258697.
  Soluzione: l'overflow dello stack può essere evitato configurando il server HTTP in modo da inviare una risposta HTTP 1.0. Per Apache ciò può essere fatto inserendo il codice seguente in httpd.conf.

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

Se l'applicazione utilizza le classi di networking, potrebbe essere eseguita in maniera non affidabile su Winsock 1.1. Se tale applicazione deve supportare Windows 95, che comprende Winsock 1.1, è necessario che gli utenti dell'applicazione dispongano di Winsock 2.0 (Windows NT 4.0, Windows 2000, Windows ME e Windows 98 includono Winsock 2.0). È possibile scaricare Winsock 2.0 al seguente indirizzo:

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

Il seguente URL contiene informazioni su come determinare se i componenti Winsock 2.0 sono installati sulla piattaforma Windows 95:

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

Senza l'aggiornamento a Winsock è possibile che, se una ricerca di nomi ha esito negativo, si verifichi il crash di InetAddress.getByName in kernel32.dll. Per informazioni su questo problema, visitare il sito Web di Microsoft.

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

Componente Java^TM Plug-in

Le note riportate di seguito si riferiscono al componente Java Plug-in contenuto in questa release.

• Sulle piattaforme Linux le copie multiple di un applet non possono essere stampate utilizzando il browser Web. È necessario chiudere il browser e riavviarlo per tutte le stampe successive alla prima. Questo problema è identificato dal numero 4450194.

• Quando si installa un'estensione tramite il componente Java Plug-in, viene visualizzata una finestra di dialogo che avvisa l'utente di tale operazione. Se in tale finestra si fa clic sul pulsante "Nega", la finestra può venire visualizzata più volte, chiedendo ripetutamente all'utente di accettare o annullare l'installazione della stessa estensione. Questo problema verrà risolto in una release futura.

• Nella versione 1.3.0_01, la verifica della firma è stata modificata in modo da utilizzare l'archivio delle autorità di certificazione fornito con Sun Java Runtime Environment anziché l'archivio fornito con Microsoft Internet Explorer. Tale modifica è stata apportata in quanto l'archivio di Internet Explorer non funziona per le applet che vengono eseguite nei browser Web di Netscape. Ulteriore codice di gestione degli errori è stato introdotto nella versione 1.3.1 per gestire le firme non verificabili. A tale proposito vedere il problema 4424604.

Note di localizzazione

Per informazioni generali sul supporto per le impostazioni internazionali contenuto in questa release, vedere Note di localizzazione.

Documentazione

Le note che seguono si riferiscono alla documentazione per questa release.

• La pagina Serialized Form (informazioni in inglese) nelle specifiche API per questa versione, a causa del problema 4459595, contiene alcuni collegamenti interrotti a file di classi private e di classi relative a specifici pacchetti.

• Vedere anche il nuovo documento in linea Tuning Garbage Collection with the 1.3.1 Java Virtual Machine (informazioni in inglese).

Non è possibile convertire stringhe PCK giapponesi con Solaris 2.6

Si è verificato un errore durante l'utilizzo di stringhe giapponesi come argomenti del comando java sulla versione localizzata di ja_JP.PCK di Solaris 2.6. Per risolvere questo problema, modificare la riga 89 /usr/java/bin/.java_wrapper da

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

a

exec $DEBUG_PROG $prog $opts $@

Problemi relativi ai caratteri del cinese tradizionale

I problemi descritti di seguito relativi ai caratteri del cinese tradizionale si riferiscono a questa release.

• La versione 2.0 di Microsoft Windows 95 per il cinese tradizionale non contiene i caratteri per il cinese tradizionale specificati nei file delle proprietà dei caratteri di Java 2 SDK. Utilizzando Java 2 SDK o Java 2 Runtime Environment su tale sistema operativo, appariranno dei messaggi di "font not found" (carattere non trovato) e di conseguenza il testo potrebbe non essere visualizzato correttamente. Tale problema non si presenta nella seconda release della versione 2.0 di Microsoft Windows 95 per il cinese tradizionale, che contiene i caratteri specificati.

• Nell'ambiente Cinese tradizionale di Microsoft Windows 95, i caratteri del cinese non vengono visualizzati correttamente nei componenti Swing. Per ulteriori dettagli, vedere il problema 4431319 sul sito Web Java Developer Connection ^SM.

Nella versione locale per l'inglese, la versione 1.3.1 di Java 2 SDK è supportata in Windows 2000 Professional, Windows 2000 Server, Windows 2000 Advanced Server, mentre non è supportata nell'edizione DataCenter di Windows 2000. Nelle versioni locali diverse dall'inglese, è supportata solo nell'edizione Professional di Windows 2000. Di seguito sono descritti i problemi noti relativi a Windows 2000:

• Windows 2000 e il supporto di schermi multipli - Gli schermi multipli non sono ancora pienamente operativi in Windows 2000; in particolare, la modalità a 256 colori funziona correttamente solo se tutti gli schermi sono impostati sulla modalità a 256 colori. Si raccomanda vivamente l'utilizzo della modalità a colori a 16 bit (o superiore).

• Se viene visualizzato il seguente messaggio di errore durante l'installazione di Windows 2000:

     config.nt. Il file di sistema non è adatto all'esecuzione di applicazioni DOS 
     e Microsoft Windows.
  

  significa che esiste un problema con il file %SystemRoot%\System32\COMMAND.COM in alcune installazioni di Windows 2000. Se questo messaggio di errore viene visualizzato mentre si tenta di lanciare il programma di installazione, visitare il sito Web di Microsoft all'indirizzo

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

  per informazioni su come risolvere il problema.

• Il processo si interrompe - Un'applicazione può interrompersi in maniera anomala a causa di uno stallo di Ntdll nei sistemi operativi Microsoft Windows 2000 Professional, Server e Advanced Server. Questo problema può verificarsi ad esempio in applicazioni che utilizzano stream di input e output di oggetti java.lang.Process . Per ulteriori informazioni ed eventuali soluzioni, visitare il sito Web del Servizio Supporto Tecnico di Microsoft:

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

Installazione su Windows NT

Quando si installa la versione 1.3.1 di Java Runtime Environment, il file del controllo ActiveX presente in C:\Winnt\Downloaded Program Files\Java Runtime Environment 1.3.1 avrà lo stato di "Danneggiato". Si tratta semplicemente di un problema "cosmetico": infatti lo stato di "Danneggiato" non dovrebbe causare problemi in nessuna situazione.

Se, tuttavia, si preferisce evitare di avere un file che presenta lo stato di "Danneggiato", eseguire le seguenti operazioni: Fare clic su "Start -> Esegui" e digitare "regedit"; nella finestra dell'Editor del Registro di configurazione, spostarsi alla chiave di registro "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation". Fare doppio clic sulla stringa INF ed eliminare la stringa evidenziata in "Valore": il file di controllo ActiveX avrà lo stato di "Installato".

Copyright (c) 2001 Sun Microsystems, Inc. Tutti i diritti riservati.