Nota: Prima di usare questo prodotto e le relative informazioni, leggere le informazioni contenute nella sezione Informazioni particolari.
Questa edizione della Guida per l'utente fa riferimento a IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0, e a tutti i successivi rilasci, modifiche e aggiornamenti di servizio se non diversamente indicato nelle nuove edizioni.
(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Tutti i diritti riservati.
(c) Copyright International Business Machines Corporation, 1999, 2005. Tutti i diritti riservati.
Limitazioni per gli utenti degli Stati Uniti d'America. L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con l'IBM Corporation.
La Guida per l'utente fornisce informazioni generali su IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) 2 Technology Edition, Version 5.0 e informazioni specifiche sulle differenze dell'implementazione IBM confrontata con quella della Sun. Consultare questa Guida utente e l'altra documentazione dal sito Web di Sun: http://java.sun.com.
SDK e Runtime Environment sono supportati sui seguenti prodotti:
Notare che IPv6 è supportato solo su Windows XP e Windows Server 2003.
Il manuale IBM JVM Diagnostics Guide fornisce informazioni più dettagliate su Virtual Machine for Java IBM.
Le modifiche tecniche effettuate per questa Guida per Versione 5.0 diverse da quelle ovvie o di minor importanza, come l'aggiornamento da "1.4.2" a "5.0", sono indicate in rosso durante la visualizzazione nella copia HTML o nella stampa a colori e da barre verticali nella parte sinistra delle modifiche.
I termini "Runtime Environment" e "Java Virtual Machine" sono utilizzati scambievolmente in questa Guida per l'utente.
IBM SDK per Linux è un ambiente di sviluppo per la scrittura e l'esecuzione di applet e applicazioni conformi a IBM Java 5.0 Core Application Program Interface (API).
SDK comprende Runtime Environment per Windows, che abilita ad eseguire solo applicazioni Java. Se è installato SDK, è incluso Runtime Environment.
Runtime Environment contiene Java Virtual Machine e il supporto file tra cui i file class. Runtime Environment contiene solo un insieme secondario delle classi trovate in SDK e consente di supportare il programma Java all'avvio ma non consente di compilare programmi Java. Runtime Environment per Windows non include alcun tool di sviluppo, del tipo appletviewer.exe o Java compiler (javac.exe) o le classi che sono solo per i sistemi di sviluppo.
Inoltre, viene fornito il pacchetto API (application programming interface) di Java Communications per essere utilizzato con il Runtime Environment per Windows. Per informazioni, consultare la sezione Uso di Java Communications API (JavaComm).
In genere, qualsiasi applet o applicazione eseguibile con una versione precedente di SDK dovrebbe funzionare correttamente con IBM 32-bit SDK for Windows, v5.0. Non viene fornita alcuna garanzia che le classi compilate con questo rilascio funzionino con i rilasci precedenti.
|IBM 32-bit SDK per Windows, V5.0, |viene generato con Microsoft Visual Studio .NET 2003.
Per leggere la documentazione della Sun relativa alla compatibilità, consultare il sito web della Sun Web su http://java.sun.com.
Se si sta effettuando un aggiornamento di SDK da un rilascio precedente, effettuare il backup di tutti i file di configurazione e dei file dei criteri di protezione prima di proseguire con l'aggiornamento.
Dopo l'aggiornamento, potrebbe essere necessario ripristinare o riconfigurare questi file perché potrebbero essere stati sovrascritti durante il processo di aggiornamento. Verificare la sintassi dei nuovi file prima di ripristinare queli originali perché il formato o le opzioni dei file sono state modificate.
Alla Versione 5.0, IBM Runtime Environment per Windows contiene nuove versioni di IBM Java Virtual Machine e del compilatore Just-In-Time (JIT). Se si sta eseguendo la migrazione da una versione più vecchia di IBM Runtime Environment, notare che:
SDK contiene diversi tool di sviluppo e un JRE (Java Runtime Environment). Questa sezione descrive i contenuti dei tool SDK e di Runtime Environment.
Le applicazioni scritte interamente in Java non devono avere dipendenze sulla struttura della directory di SDK IBM (o sui file in quelle directory). Qualunque dipendenza sulla struttura della directory SDK (o sui file in quelle directory) potrebbe comportare problemi di trasportabilità dell'applicazione. Le applicazioni JNI (Java Native Interface) avranno dipendenze minori.
Nota: la Guida per l'utente, Javadoc, e la licenza che la accompagna , i file di copyright e la directory della demo sono l'unica documentazione inclusa in questo SDK per Windows. È possibile visualizzare o scaricare la documentazione del software di Sun dal sito Web di Sun: http://java.sun.com.
per installare SDK oppure il pacchetto Runtime Environment, scaricare il relativo pacchetto di installazione. Assicurarsi di scaricare tutti i pacchetti nella stessa directory. I pacchetti ed i relativi nomi file sono elencati in Installazione presidiata (interattiva); non modificare i nomi file dei pacchetti.
Prima di avviare l'installazione, accertarsi che ci sia spazio sufficiente nella directory C:\WINDOWS\TEMP da utilizzare durante l'installazione. La quantità di spazio temporaneo richiesta nella directory TEMP durante l'installazione è la seguente:
Se lo spazio temporaneo disponibile non è sufficiente, il programma di installazione genera un errore e interrompe le operazioni. Se si dispone di spazio temporaneo sufficiente, ma il messaggio viene visualizzato ugualmente, verificare che i pacchetti che si desidera installare siano stati scaricati completamente. Confrontare, quindi, le dimensioni dei pacchetti con quelle visualizzate nelle pagine Web da cui sono stati scaricati.
I pacchetti che possono essere installati sono:
Altri pacchetti forniti come file zip sono:
Viene installato Runtime Environment per impostazione predefinita nella directory C:\Program Files\IBM\Java50\jre.
Se si è scaricato il pacchetto installabile SDK, è possibile selezionare se installare:
È possibile installare individualmente i componenti o in combinazione.
Per la procedura di installazione, vengono visualizzate le seguenti opzioni:
Se si installa Runtime Environment (sia come parte del pacchetto installabile SDK che dal pacchetto installabile Runtime Environment), viene richiesto se si desidera installare Runtime Environment come sistema JVM (Java Virtual Machine). Se lo si installa come JVM di sistema, il programma di installazione copia i file java.exe e javaw.exe nella directory di sistema di Windows. Se nella directory di sistema di Windows già esiste una versione di java.exe o javaw.exe, viene richiesto di sostituire le versioni esistenti con quella corrente. Se si installano questi file nella directory di sistema di Windows, Runtime Environment diventa la JVM predefinita per il sistema. Inoltre, la chiave di registro "Current Version" viene impostata per associare tale installazione.
Per creare un'installazione non presidiata, è necessario completare un'istallazione presidiata, quindi creare un file delle risposte (setup.iss) in cui vengono memorizzate le scelte effettuate durante l'installazione. Il file delle risposte creato dovrà essere valido sulle macchine che si desidera utilizzare. Se necessario, create vari file di risposta da utilizzare per installare i pacchetti su computer con differenti configurazioni.
Per creare un file di risposte durante l'installazione, in una richiesta comandi, digitare:
ibm-java2-sdk-50-win-i386 /r
oppure
ibm-java2-jre-50-win-i386 /r
A seconda del prodotto Windows, viene creato un file di risposte (setup.iss) nella directory C:\Windows oppure in C:\Winnt dove C: è l'unità di avviamento.
Durante un'installazione interattiva può essere visualizzato il seguente messaggio:
Un altro Java Runtime Environment è stato installato come JVM. Selezionare Sì per sovrascrivere questa versione oppure No per uscire dall'installazione.
Se si verifica questo errore, selezionare No ed uscire dall'installazione. Nella directory di sistema di Windows cancellare i seguenti due file:
Una volta cancellati i file, riavviare l'installazione interattiva utilizzando il comando riportato all'inizio di questa sezione.
Nel sistema in cui verrà eseguita l'installazione non presidiata, copiare il file di risposte setup.iss nella directory C:\Windows. Dopo aver copiato il file, immettere quanto segue da una richiesta comandi:
ibm-java2-sdk-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java2-jre-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Se l'installazione viene completata con esito positivo, il file di registrazione conterrà la stringa ResultCode=0.
IBM Accessibility Bridge, per impostazione predefinita, è installato ma non è abilitato. Per abilitare IBM Accessibility Bridge, eliminare il simbolo numerico dall'inizio della riga di seguito riportata nel file Accessibility.properties nella directory jre/lib:
#assistive_technologies=JawBridge
Questo sito Web fornisce ulteriori informazioni sulle Accessibility Utilities:
http://java.sun.com/products/jfc/accessibility.html
È possibile disabilitare del supporto Java Accessibility per aumentare le prestazioni di caricamento JVM di applicazioni Java che non forniscono supporto alla tecnologia Java.
Per disabilitare il supporto Java Accessibility, impostare la variabile di ambiente JAVA_ASSISTIVE su OFF. Una tecnologia di assistenza, quale JawBridge, non è disponibile se questa variabile d'ambiente è impostata su OFF, anche se la tecnologia è abilitata nel file Accessibility.properties.
In ambiente Windows, un processo ha due codepage: quella ANSI (oppure Windows) e quella OEM (oppure DOS).
La finestra comandi di solito utilizza la codepage OEM. L'output della console Java utilizza la codepage della finestra comandi da cui si avvia Java. Tuttavia, il comando javaw utilizza sempre la codepage ANSI. E' possibile specificare la codepage da utilizzare per l'output della console con l'opzione -D console.encoding del comando java. Ad esempio, digitando -D console.encoding=Cp1252 tutti gli output della console saranno nella codepage Windows ANSI Latin1 (1252).
Notare che, se si altera la variabile di ambiente PATH come descritto di seguito, verrà ricoperto qualunque eseguibile Java esistente nel proprio percorso.
Dopo aver installato SDK, è possibile eseguire un tool immettendo il suo nome nel prompt della shell con un nome file come argomento.
E' possibile specificare il percorso immettendolo ogni volta prima del nome del tool. Ad esempio, se è installato SDK per Windows in C:\Program Files\IBM\Java50\bin, si può compilae un file cui è stato assegnato il nome myfile.java immettendo quanto segue ad una richiesta comandi:
"C:\Program Files\IBM\Java50\bin\javac" myfile.java
Per evitare di digitare ogni volta il percorso completo:
Se si è installato SDK o Runtime Environment in una directory differente, sostituire C:\Program Files\IBM\Java50\ con la directory in cui è stato installato il SDK o Runtime Environment
javac myfile.java
La variabile d'ambiente PATH abilita Windows a trovare i file eseguibili, come javac, java e javadoc, dalla directory corrente. Per visualizzare il valore corrente del proprio PATH, immettere quanto segue alla richiesta comandi:
echo %PATH%
CLASSPATH dice ai tool del SDK, come java, javac e javadoc dove trovare le librerie della classe Java.
E' necessario impostare esplicitamente CLASSPATH solo se si applica una delle seguenti possiilità:
Per visualizzare il valore corrente del proprio CLASSPATH, immettere quanto segue alla richiesta comandi:
echo %CLASSPATH%
Se si pianifica di sviluppare ed eseguire applicazioni che usano differenti ambienti runtime, comprese altre versioni installate separatamente, bisogna impostare esplicitamente CLASSPATH (e PATH) per ciascuna applicazione. Se si pianifica di eseguire applicazioni multiple simultaneamente e si usano differenti ambienti runtime, ciascuna applicazione deve eseguire la sua propria finestra comandi.
Se si vuole eseguire solo una versione di Java alla volta, è possibile usare lo script batch per passare tra i diversi ambienti runtime.
Per disinstallare SDK, sia che sia stata eseguita l'installazione presidiata che non presidiata, procedere come segue:
Questa procedura rimuove tutti i pacchetti installati con l'Installer. Non elimina il pacchetto delle API di Java Communications (consultare Java Communications API) o eventuali file aggiuntivi che sono stati estratti dai pacchetti in formato zip.
Quando si gestiscono installazioni multiple tra IBM 32-bit SDK for Windows, v5.0, e le versioni a livello V1.3.1 o precedenti, se si disinstalla la versione precedente mentre è ancora installata una versione V5.0 il programma di disinstallazione di V1.3.1 rimuove le seguenti chiavi di registro e le sottochiavi richieste dalla versione V5.0,causando malfunzionamenti all'installazione di V5.0:
Pertanto, reinstallare V5.0 dopo aver disisnstallato la versione V1.3.1. Questa restrizione è stata corretta con la versione V1.4.0 e con i rilasci successivi.
Lo strumento java avvia un'applicazione Java avviando Java Runtime Environment e caricando una classe specificata.
JVM ricerca la classe di avvio (e le altre classi utilizzate) in tre serie di ubicazioni: il percorso classe di bootstrap, le estensioni installate e il percorso di classe utente. Gli argomenti specificati dopo il nome classe o il nome file JAR vengono passati alla funzione principale.
Il comando javaw è identico a java, tranne javaw che non ha alcuna finestra di console associata. Usare javaw quando non si desidera che venga visualizzata una finestra di richiesta comandi. Il programma di avvio javaw visualizza una casella di dialogo con le informazioni sugli errore nel caso in cui l'avvio abbia esito negativo.
I comandi java e javaw hanno la seguente sintassi:
java [ opzioni ] classe [ argomenti ... ] java [ opzioni ] -jar file.jar [ argomenti ... ] javaw [ opzioni ] classe [ argomenti ... ] javaw [ opzioni ] -jar file.jar [ argomenti ... ]
Le voci tra parentesi sono facoltative.
Se si specifica l'opzione -jar, il file JAR denominato contiene i file di risorsa e classe per l'applicazione, insieme alla classe di startup specificata nell'intestazione manifest Main-Class.
Il programma di avvio ha una serie di opzioni standard supportate nell'ambiente di runtime corrente e che saranno supportate dai release successivi. Vi sono inoltre, una serie di opzioni non standard. Le opzioni predefinite sono state scelte per garantire le prestazioni migliori per gli utilizzi più comuni. Ponderare attentamente eventuali modifiche.
È possibile specificare le opzioni Java e le proprietà di sistema in tre modi diversi. In ordine di precedenza, tali modi sono:
Le opzioni più a destra sulla riga comandi hanno la precedenza su quelle più a sinistra; ad esempio se si specifica -Xint -Xjit myClass, -Xjit ha la precedenza.
Le opzioni -X sotto elencate sono non standard e soggette a modifica senza preavviso.
Per opzioni che assumono il parametro <dimensione>, occorre aggiungere come suffisso il numero "k" o "K" per indicare i kilobyte, "m" o "M" per indicare i megabyte e "g" o "G" per indicare i gigabyte.
Per ottenere il numero di build IBM e la versione, ad una richiesta comandi command immettere:
java -version
Il comando java e altri comandi di java (ad esempiojavaw) consentono di specificare un nome classe con un qualsiasi carattere del set di caratteri della locale corrente.
È possibile anche specificare un qualsiasi carattere Unicode nel nome classe e gli argomenti utilizzando le sequenze di escape java. Per eseguire tale operazione, occorre specificare -Xargencoding. Per specificare un carattere Unicode, utilizzare sequenze di escape nel formato \u####, dove # è una cifra esadecimale (da 0 a 9, dalla A alla F).
In alternativa, per specificare che il nome classe e gli argomenti comando sono con codifica UTF8, utilizzare -Xargencoding:utf8 oppure con codifica ISO8859_1 utilizzando -Xargencoding:latin.
Ad esempio, per specificare una classe denominata "HelloWorld" utilizzando la codifica Unicode a lettere maiuscole, si utilizzerà questo comando:
java -Xargencoding '\u0048ello\u0057orld'
I comandi java e javaw forniscono messaggi di output tradotti. Tali messaggi differiscono in base alla lingua in cui Java è in esecuzione. Le descrizione di errore dettagliate e le altre informazioni di debug restituite da java sono in Inglese.
Per impostare un file jar o una classe java in modo che vengano eseguiti automaticamente da file, utilizzare l'opzione Strumenti->Opzioni cartella->Tipo file di Windows Explorer. Oppure, da una richiesta comandi, immettere:
assoc .class=javaclass ftype javaclass=C:\Program Files\IBM\Java50\jre\bin\java.exe %l %*
Sun fornisce Java Access Bridge per dare alle tecnologie di assistenza Windows native, come ad esempio lo screen reader, l'accesso al supporto Java Accessibility support nelle applicazioni Java. Tali tecnologie devono supportare le chiamate a Java Access Bridge.
Java Access Bridge, reso disponibile dalla Sun, include un programma di installazione, che colloca cinque file nelle directory corrette: access-bridge.jar, jaccess.jar, accessibility.properties, JavaAccessBridge.dll e WindowsAccessBridge.dll. IBM invia una copia di jaccess.jar nella directory appropriato per utilizzarlo con JawBridge.
Se è già stato installato IBM Accessibility Bridge (JawBridge), che consente a Windows 2000 Magnifier di funzionare con applicazioni Swing, e si desidera abilitare JawBridge contemporaneamente a Java Access Bridge, modificare la riga nel file accessibility.properties nel seguente modo:
assistive_technologies=com.sun.java.accessibility.AccessBridge, JawBridge
Disattivare la riga immettendo il carattere # al suo inizio per disattivare entrambi i bridge. Sul sito Web si trovano le informazioni su come scaricare Java Access Bridge:
http://java.sun.com/products/jfc/accessibility.html
Il compilatore IBM JIT (Just-In-Time) genera dinamicamente il codice macchina per le sequenze di bytecode usate frequentemente nelle applicazioni Java e nelle applet mentre sono in esecuzione.|Il compilatore JIT V5.0 fornisce nuove ottimizzazioni risultati dalla ricerca del compilatore, migliora le ottimizzazioni implementate nelle precedenti versioni del JIT e fornisce un migliore utilizzo dell'hardware.
IBM SDK e Runtime Environment includono JIT, abilitato per impostazione predefinita nelle applicazioni utente e nei tool SDK. Di norma, non è necessario richiamare esplicitamente JIT; la compilazione del bytecode Java in codice macchina avviene in maniera trasparente. Tuttavia, se si incontra un problema con Runtime Environment mentre si esegue un'applicazione o un'applet Java, è possibile disabilitare JIT per facilitare l'isolamento del problema. La disabilitazione di JIT deve essere una soluzione solo temporanea; per prestazioni soddisfacenti è richiesto JIT.
Esistono tre modi per disabilitare JIT:
Alla richiesta comandi immettere:
set JAVA_COMPILER=NONE
È possibile impostare in modo permanente JAVA_COMPILER utilizzando la GUI. Aprire il Pannello di controllo, selezionare Sistema e sulla scheda Avanzate, selezionare Variabili d'ambiente.
java -Djava.compiler=NONE MyApp
java -Xint MyApp
Entrambe le opzioni di riga comandi sovrascrivomno la variabile d'ambiente JAVA_COMPILER.
Per abilitare JIT esplicitamente, impostare la variabile d'ambiente JAVA_COMPILER su "jitc", oppure utilizzare l'opzione -D per impostare la proprietà java.compiler su "jitc". In alternativa, utilizzare l'opzione -Xjit (e omettere l'opzione -Xint) sulla riga comandi JVM per attivare JIT.
Se la variabile d'ambiente JAVA_COMPILER o la proprietà java.compiler sono impostate su "" (stringa vuota), JIT resta disabilitato. Per annullare l'impostazione della variabile d'ambiente, immettere set JAVA_COMPILER= alla richiesta comandi.
Per verificare se JIT è abilitato, immettere quanto segue da una richiesta comandi:
java -version
Se JIT non è in uso, viene visualizzato un messaggio che comprende quanto segue:
(JIT disabilitato)
Se JIT è in uso, viene visualizzato un messaggio che comprende quanto segue:
(JIT abilitato)
Per ulteriori informazioni su JIT, consultare Diagnostics Guide.
La raccolta dei dati obsoleti gestisce la memoria usata da Java e dalle applicazioni in esecuzione all'interno del VM.
Quando Recupera spazio riceve una richiesta per la memorizzazione, la memoria heap non usata viene impostata a parte - "assegnazione". La raccolta dei dati obsoleti controlla inoltre le aree di memoria cui non si fa più riferimento e le rilascia per il riutilizzo - "raccolta".
La fase di raccolta può scattare in seguito ad un errore di allocazione della memoria, il che si verifica quando non viene lasciato spazio per la richiesta di memoria o da una chiamata System.gc() esplicita.
La raccolta dei dati obsoleti può influire significativamente sulla prestazione dell'applicazione, per cui IBM virtual machine fornisce vari metodi per ottimizzare il modo in cui i dati obsoleti vengono eliminati, riducendo così l'effetto sulle applicazioni.
Per ulteriori informazioni, consultare Diagnostics Guide.
L'opzione -Xgcpolicy specifica la politica di raccolta dati obsoleti.
-Xgcpolicy prende i valori optthruput (valore predefinito e consigliato), optavgpause oppure gencon. Questa opzione controlla il comportamento del programma di raccolta dei dati obsoleti, bilanciando la velocità effettiva dell'applicazione e del sistema in generale e le pause determinate dalla raccolta dei dati obsoleti.
Il formato dell'opzione ed i suoi valori sono:
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
Quando il tentativo di un'applicazione di creare un oggetto non può essere immediatamente soddisfatto a causa dello spazio disponibile nella memoria riservata, il programma di raccolta dei dati obsoleti è responsabile dell'identificazione degli oggetti cui non si fa riferimento (obsoleti), della loro cancellazione e della reimpostazione della memoria riservata su uno stato in cui le immediate e successive richieste di allocazione possono essere soddisfatte rapidamente. Questi cicli di raccolta dei dati obsoleti causano delle pause occasionali ed impreviste nell'esecuzione del codice dell'applicazione. Quando la dimensione e la complessità delle applicazioni crescono, e le memorie riservate diventano di conseguenza più grandi, questa pausa per la raccolta dei dati obsoleti tende a crescere. L'impostazione predefinita per la raccolta dei dati obsoleti, -Xgcpolicy:optthruput, consente alle applicazioni una velocità di trasmissione molto alta, tuttavia possono verificarsi delle pause occasionali, il che può variare da alcuni millisecondi a svariati secondi, in base alla dimensione della memoria e alla quantità di dati obsoleti.
JVM utilizza due tecniche per ridurre i tempi di pausa:
L'opzione della riga comandi -Xgcpolicy:optavgpause richiede l'utilizzo della raccolta dati obsoleti simultanea per ridurre in modo significativo il tempo utilizzato nelle pause della raccolta dei dati obsoleti. La raccolta dati obsoleti simultanea riduce il tempo di pausa eseguendo alcune attività di raccolta dei dati obsoleti contemporaneamente all'esecuzione normale del programma per ridurre le interruzioni causate dalla raccolta della memoria riservata. L'opzione -Xgcpolicy:optavgpause limita inoltre l'effetto dell'incremento della dimensione della memoria riservata nella lunghezza della pausa della raccolta dei dati obsoleti. L'opzione -Xgcpolicy:optavgpause è molto utile per configurazioni che hanno grandi memorie riservate. Con il tempo di pausa ridotto, è possibile che si verifichi una riduzione nella capacità di elaborazione delle applicazioni.
Durante la raccolta dei dati obsoleti simultanea, viene sprecato molto tempo per identificare gli oggetti di durata relativamente lunga che non possono essere raccolti. Se la raccolta dei dati obsoleti si concentra solo su tali oggetti, che sono di solito riciclabili, è possibile ridurre ulteriormente i tempi di pausa per alcune applicazioni. La raccolta dati obsoleti generazionale ottiene questo risultato dividendo la memoria riservata in due "generazioni", le aree "asilo" e "possesso". Gli oggetti sono ubicati in una di queste aree a seconda della loro età. L'asilo è il più piccolo del due e contiene oggetti più giovani; il possesso è più grande e contiene oggetti più vecchi. Gli oggetti vengono prima assegnati all'asilo; se essi sopravvivono abbastanza a lungo, vengono eventualmente promossi nell'area di possesso.
La raccolta dati obsoleti generazionale si basa su una maggioranza di oggetti che non durano a lungo. La raccolta dati obsoleti generazionale, riduce i tempi di pausa concentrandosi sul reclamo memoria nell'asilo in quanto questa area, dispone di più spazio riciclabile. Invece di utilizzare tempi di pausa lunghi per la raccolta dell'intera memoria riservata, i dati nell'asilo vengono raccolti più spesso e, se l'asilo è sufficientemente piccolo, i tempi di pausa sono conseguentemente brevi. Il lato negativo della raccolta dati generazionale consiste nel fatto che, nel tempo, l'area di possesso potrebbe diventare piena se molti oggetti durano troppo a lungo. Per ridurre il tempo di pausa quando si verifica tale situazione, utilizzare una combinazione di raccolte dati obsoleti generazionali e simultanee. L'opzione -Xgcpolicy:gencon richiede l'uso combinato della raccolta dati simultanea e generazionale per ridurre il tempo impiegato nella pausa della raccolta dei dati obsoleti.
Quando una memoria riservata Java è quasi piena ed i dati obsoleti da eliminare sono pochi, è possibile che le richieste per nuovi oggetti non possano essere soddisfatte rapidamente poiché non c'è spazio immediatamente disponibile. Se la memoria riservata viene utilizzata quando è quasi piena, è possibile che le prestazioni delle applicazioni subiscano una riduzione, indipendentemente da quale delle opzioni sopra indicate viene utilizzata: e, se si continua ad inoltrare richieste per ulteriore spazio della memoria riservata, l'applicazione riceve un'eccezione OutofMemory, che determina la chiusura del JVM se l'eccezione non viene rilevata e risolta. A questo punto, JVM produce un file di diagnostici denominato "javadump". In queste situazioni, si consiglia di aumentare la dimensione della memoria riservata utilizzando l'opzione e -Xmx oppure di ridurre il numero di oggetti di applicazione in uso. Per ulteriori informazioni, consultare il manuale Diagnostics Guide.
Quando viene generato un segnale che possa essere di interesse per JVM, viene richiamato un programma di gestione segnali. Questo, determina se è stato invocato per un thread Java oppure per un non-Java.
Se il segnale è per un thread Java, JVM prende il controllo della gestione del segnale. Se è installato un gestore applicazioni per questo segnale e non è stata specificata l'opzione riga comandi -Xnosigchain, quando JVM termina l'elaborazione, viene richiamato il gestore applicazioni per questo segnale.
Se il segnale è per un thread non-Java, e l'applicazione che installava JVM aveva precedentemente installato il proprio gestore segnali, il controllo viene passato a tale gestore. In caso contrario, se il segnale viene richiesto da JVM o dall'applicazione JAVA, il segnale viene ignorato oppure viene eseguita l'azione predefinita.
L'eccezione a questa regole è in Windows, dove per un segnale generato esternamente (ad esempio immettendo CTRL-BREAK) viene creato un nuovo thread per eseguire il gestore segnali. In questo caso, il gestore segnali JVM esegue le elaborazioni e, se è installato un gestore applicazioni per questo segnale e non è stata specificata l'opzione riga comandi -Xnosigchain, viene richiamato il gestore applicazioni per questo segnale.
Per i segnali di errore e eccezione, JVM esegue quanto segue:
Per segnali di interruzione, JVM immette inoltre una sequenza di chiusura controllata, ma questa volta viene trattata come una normale chiusura che:
La chiusura è identica a quella iniziata da una chiamata al metodo Java System.exit().
Altri segnali usati da JVM servono per controlli interni e non causano la chiusura. L'unico segnale di controllo di interesse è SIGBREAK, che genera un Javadump.
Tabella 1 di seguito vengono illustrati i segnali usati da JVM. I segnali sono raggruppati in una tabella per tipo o uso, nel seguente modo:
| Nome segnale | Tipo segnale | Descrizione | Disabilitato da -Xrs |
|---|---|---|---|
| SIGINT | Interrotto | Attenzione interattiva (CTRL-C). JVM esce normalmente. | Sì |
| SIGTERM | Interrotto | Richiesta termine. JVM uscirà normalmente. | Sì |
| SIGBREAK | Controllo | Segnale di interruzione per un terminale. Usato da JVM per effettuare dei Javadump. | Sì |
Usare l'opzione -Xrs (riduce uso segnale) per evitare che JVM gestisca la maggior parte dei segnali. Per ulteriori informazioni, consultare la pagina di avvio dell'applicazione Java della Sun all'indirizzo http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.
I segnali 2 (SIGINT) e 15 (SIGTERM) sui thread JVM causano l'arresto della JVM; pertanto un gestore di segnali dell'applicazione non deve tentare il ripristino da questi segnali se richiede ancora la JVM.
Runtime Environment contiene il concatenamento dei segnali. Questa funzione consente a JVM di operare in modo più efficiente con il code nativo che installa i propri gestori di segnale.
Il concatenamento dei segnali consente ad un'applicazione di collegare e caricare la libreria condivisa jsig.dll prima di msvcrt.dll. La libreria jsig.dll assicura che le chiamate a signal() vengano intercettate in modo che i relativi gestori non sostituiscano i gestori di segnale della JVM. Al contrario, tali chiamate salvano i nuovi gestori di segnale o li concatenano ai gestori installati dalla JVM. Successivamente, quando uno di tali segnali viene attivato e viene rilevato come non destinato alla JVM, vengono richiamati i gestori pre-installati.
Per utilizzare jsig.dll, eseguire il collegamento all'applicazione che crea oppure inserisce una JVM.
L'IBM SDK contiene il processore XSLT4J e il parser XML4J che sono conformi alla specifica JAXP 1.3. Tali strumenti consentono di analizzare e trasformare documenti XML indipendentemente da qualsiasi implementazione di elaborazione XML fornita. Utilizzando "Factory Finders" per individuare le implementazioni SAXParserFactory, DocumentBuilderFactory e TransformerFactory, l'applicazione può passare tra differenti implementazioni senza dover cambiare alcun codice.
|La tecnologia XML inclusa con IBM SDK è simile a |Apache Xerces Java e Apache Xalan Java. Per ulteriori informazioni, visitare i siti http://xml.apache.org/xerces2-j/ ehttp://xml.apache.org/xalan-j/.
Il processore XSLT4J consente di scegliere tra il processore XSLT Interpretive originale oppure e il nuovo processore XSLT Compiling. Il processore Interpretive è progettato per ambienti di debug e supporto e supporta le funzioni di estensione XSLT che non sono supportate dal processore XSLT Compiling. Il processore XSLT Compiling viene progettato per ambienti di esecuzione ad alte prestazioni; genera un motore di trasformazione oppure translet, da un foglio di stile. Questo approccio separa l'interpretazione delle istruzioni dei fogli di stile dalla relativa applicazione di runtime a dati XML.
Il processore XSLT Interpretive è quello predefinito. Per selezionare il processore XSLT Compiling è possibile:
Per implementare le proprietà nel file jaxp.properties, copiare jaxp.properties.sample in jaxp.properties nella C:\Program Files\IBM\Java50\. Questo file contiene anche dettagli completi sulla procedura utilizzata per determinare quali implementazioni utilizzare per TransformerFactory, SAXParserFactory e DocumentBuilderFactory.
Per migliorare le prestazioni quando si trasforma un oggetto StreamSource con il processore XSLT Compiling, specificare la classe com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager come provider del servizio org.apache.xalan.xsltc.dom.XSLTCDTMManager. Per determinare il service provider, provare ogni operazioni finché non si individua org.apache.xalan.xsltc.dom.XSLTCDTMManager:
Il processore XSLT Compiling rileva il service provider per il servizio org.apache.xalan.xsltc.dom.XSLTCDTMManager quando viene creato un oggetto javax.xml.transform.TransformerFactory. Qualsiasi oggetto javax.xml.transform.Transformer oppure javax.xml.transform.sax.TransformerHandler creato utilizzando l'oggetto TransformerFactory, utilizzerà lo stesso service provider. È possibile modificare i service provider modificando una delle impostazioni descritte e quindi creando un nuovo oggetto TransformerFactory.
Se si sta usando una versione meno recente di Tomcat, potrebbe applicarsi questa limitazione.
Se si sta usando una versione più vecchia di Xerces (antecedente a 2.0) o Xalan (antecedente a 2.3), si potrebbe ricevere un'eccezione di puntatore nullo quando si lancia l'applicazione. Questa eccezione si verifica perché le versioni più vecchie non gestiscono correttamente il file jaxp.properties.
Per evitare questa situazione, usare una delle seguenti soluzioni alternative:
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory= org.apache.xerces.jaxp.SAXParserFactoryImploppure
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory= org.apache.xerces.jaxp.DocumentBuilderFactoryImploppure
set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory= org.apache.xalan.processor.TransformerFactoryImpl
Le seguenti sezioni forniscono informazioni sull'utilizzo di SDK per Windows per sviluppare applicazioni Java. Consultare Tool SDK per informazioni dettagliate sugli strumenti disponibili.
Per eseguire il debug dei programmi Java, è possibile usare l'applicazione JDB (Java Debugger) o altri programmi di debug che comunicano tramite l'uso di JPDA (Java Platform Debugger Architecture) fornito da SDK per Windows.
JDB (Java Debugger) è incluso nel SDK per Windows. Il programma di debug è richiamato dal comando jdb; questo si "collega" a JVM che usa usando JPDA. Per eseguire il debug di un'applicazione Java:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<porta>
MyApp <arg MyApp>jdb -attach <numero porta>Il programma di debug si collega a JVM ed è ora possibile emettere una gamma di comandi per esaminare e controllare le applicazioni Java; ad esempio, immettere run per consentire l'esecuzione di applicazioni Java.
Per ulteriori informazioni sulle opzioni JDB, immettere:
jdb -help
Per ulteriori informazioni sui comandi JDB:
È inoltre possibile usare JDB per effettuare il debug delle applicazioni Java eseguite su macchine remote:
jdb -attach <nome macchina o indirizzo ip>:<numero porta>
Quando si lancia una sessione di debug usando il trasporto dt_socket, accertarsi che le porte specificate siano libere.
|JVMDI (Java Virtual Machine Debugging Interface) non è supportata in questo rilascio. È stata sostituita da JVMTI (Java Virtual Machine Tool Interface).
Per ulteriori informazioni su JDB e JPDA e sul loro uso, consultare questi siti web:
Con alcune applicazioni Java deve essere possibile determinare se viene eseguita una JVM a 32 o 64 bit. Ad esempio,se l'applicazione dispone di una libreria di codice nativo, tale libreria deve essere compilata separatamente in moduli a 32 e 64 bit per le piattaforme che supportano entrambe le modalità di funzionamento (a 32 e 64 bit). In questo caso, l'applicazione deve caricare la libreria corretta al runtime, perché non è possibile mischiare il codice a 32 bit con quello a 64 bit.
La proprietà di sistema com.ibm.vm.bitmode consente alle applicazioni di determinare il modo in cui è in esecuzione il JVM di cui si dispone. Vengono restituiti i seguenti valori:
È possibile esaminare com.ibm.vm.bitmode dal codice dell'applicazione utilizzando la chiamata:
System.getProperty("com.ibm.vm.bitmode");
I numeri di versione JNI validi che i programmi nativi possono specificare sulla chiamata JNI_CreateJavaVM() API sono:
Questo numero di versione determina solo il livello dell'interfaccia nativa JNI da utilizzare. Il livello attuale di JVM creato viene specificato dalle librerie J2SE (cioè v5.0). L'API interfaccia JNI non influisce sulla specifica del lingua implementata da JVM, le API delle librerie delle classi oppure qualsiasi altra area di azione di JVM. Per ulteriori informazioni, visitare il sito http://java.sun.com/j2se/1.5.0/docs/guide/jni.
Se per l'applicazione occorrono due librerie JNI, una creata per 31-bit e una per 64 -bit, utilizzare la proprietà di sistema com.ibm.vm.bitmode per determinare se si sta eseguendo con un JVM a 31 oppure a 64 bit e selezionare la libreria appropriata.
Con Applet Viewer, è possibile eseguire una o più applet chiamate come riferimento in una pagina web (file HTML) usando le tag APPLET. Applet Viewer individua le tag APPLET nel file HTML ed esegue le applet, in finestre separate, come specificato dalle tag.
Poiché l'Applet Viewer è solo per le applet di visualizzazione, non può visualizzare un'intera pagina web contenente molte tag HTML. Analizza solo le tag APPLET e nessun altro HTML nella pagina web.
Per eseguire un'applet con il suo visualizzatore, immettere in una shell di richiesta comando:
appletviewer name
dove name è uno dei seguenti:
Ad esempi, per richiamare un'Applet Viewer su un file HTML che chiama un'applet, immettere su una shell :
appletviewer <demo>\GraphLayout\example1.html
dove <demo> viene sostituito dal percorso completo in cui è stato spacchettato il pacchetto della demo.
Ad esempio, http://java.sun.com/applets/NervousText/example1.html è l'URL della pagina Web che richiama l'applet. Per richiamare Applet Viewer su questa pagina web, immettere su una shell di comandi:
appletviewer http://java.sun.com/applets/NervousText/example1.html
L'Applet Viewer non riconosce l'opzione charset della tag <META>. Se il file caricato da appletviewer non è codificato come predefinito del sistema, potrebbe verificarsi un'eccezione I/O. Per evitarla, usare l'opzione -encoding quando si esegue appletviewer. Ad esempio:
appletviewer -encoding JISAutoDetect sample.html
Si può eseguire il debug delle applet usando l'opzione -debug di Applet Viewer. Quando si esegue il debug delle applet, viene consigliato di richiamare Applet Viewer dalla directory che contiene il file HTML che chiama l'applet. Ad esempio:
cd <demo>\TicTacToe appletviewer -debug example1.html
Dove <demo> viene sostituito dal percorso completo in cui è stato spacchettato il pacchetto della demo.
La documentazione su come eseguire il debug delle applet usando Applet Viewer si trova sul sito web della Sun: http://java.sun.com.
| | |È possibile abilitare il supporto a pagine grandi, su sistemi che lo supportano, avviando Java con l'opzione -Xlp.
|L'utilizzo di pagine grandi serve principalmente a fornire dei miglioramenti delle prestazioni alle applicazioni che allocano molta memoria e che accedono ad essa frequentemente. |I miglioramenti delle prestazioni delle pagine grandi sono principalmente causati dal numero ridotto di mancati riscontri nel TLB (Translation Lookaside Buffer). TLB mappa un intervallo più ampio di memoria virtuale e così effettua questo miglioramento.
|Affinché JVM utilizzi pagine grandi, il sistema deve avere un numero adeguato di pagine grandi contigue disponibili. |Se le pagine grandi non possono essere allocate, anche quando sono disponibili sufficienti pagine, è possibile che le pagine grandi non siano contigue.
|Le allocazioni di pagine grandi avranno esito positivo se il criterio amministrativo locale per l'utente della JVM è configurato per consentire il blocco delle pagine in memoria.
Java 2 Platform, Standard Edition (J2SE) supporta, almeno, le specifiche definite nelle Official Specifications for CORBA support in J2SE (V1.5). In alcuni casi, IBM J2SE ORB supporta le versioni più recenti delle specifiche.
Questo SDK supporta tutte le versioni di GIOP, come definito nei capitoli 13 e 15 delle specifiche CORBA 2.3.1, documento OMG formal/99-10-07, recuperabile su:
http://www.omg.org/cgi-bin/doc?formal/99-10-07
GIOP bidirezionale non è supportato.
Questo SDK supporta Portable Interceptors, come definito da OMG nel documento ptc/01-03-04, che è possibile ottenere da:
http://www.omg.org/cgi-bin/doc?ptc/01-03-04
Portable Interceptors sono ganci posti in ORB attraverso cui i servizi ORB possono intercettare il normale flusso esecutivo di ORB.
SDK supporta Interoperable Naming Service, come definito da OMG nel documento ptc/00-08-07, che è possibile ottenere da:
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
La porta predefinita usata da Transient Name Server (il comando tnameserv), quando non viene dato il parametro ORBInitialPort, cambia da 900 a 2809, che è il numero della porta registrata con IANA (Internet Assigned Number Authority) per il servizio di assegnazione nomi CORBA. I programmi dipendenti da questo valori predefiniti, per lavorare con questa versione, potrebbero aver bisogno di essere aggiornati.
Il contesto iniziale che viene restituito dal Transient Name Server è ora un org.omg.CosNaming.NamingContextExt. I programmi esistenti che riducono il riferimento ad un contesto org.omg.CosNaming.NamingContext funzionano comunque e non hanno bisogno di essere ricompilati.
ORB supporta i parametri -ORBInitRef e -ORBDefaultInitRef definiti dalla specifica di Interoperable Naming Service, e l'operazione ORB::string_to_object supporta ora i formati di stringa ObjectURL (corbaloc: e corbaname:) definiti dalla specifica di Interoperable Naming Service.
OMG specifica un metodo ORB::register_initial_reference per registrare un servizio con Interoperable Naming Service. Tuttavia, questo metodo non è disponibile in Sun Java Core API alla Versione 5.0. I programmi che hanno bisogno di registrare un servizio nella versione corrente devono richiamare questo metodo nella classe di implementazione ORB interna IBM. Ad esempio, per registrare un servizio "MyService":
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MyService",
serviceRef);
dove orb è un'istanza di org.omg.CORBA.ORB, che viene restituita da ORB.init(), e serviceRef e un Oggetto ORBA, che è connesso a ORB. Questo meccanismo è temporaneo e non è compatibile con le future versioni o portatili ORB non-IBM.
Una funzione di debug al momento dell'esecuzione fornisce funzionalità potenziate. Potrebbe risultare utile per la diagnosi dei problemi o potrebbe essere richiesta dal personale di assistenza IBM. La funzione di traccia è controllata da tre proprietà di sistema.
Ad esempio, per tracciare gli eventi e i messaggi formattati GIOP, immettere:
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true myapp
Non attivare la traccia per le normali operazioni in quanto ciò potrebbe comportare un peggioramento delle prestazioni. Anche se la traccia è stata disattivata, FFDC (First Failure Data Capture) funziona comunque, per cui vengono riportati solo gli errori gravi. se viene generato un file di output del debug, esaminarlo per verificare il problema. Ad esempio, il server potrebbe essersi interrotto senza eseguire un ORB.shutdown().
Il contenuto e il formato dell'output di traccia potrebbero variare da versione a versione.
Le seguenti proprietà agevolano l'ottimizzazione di ORB:
Ad esempio, per impostare la dimensione del frammento su 4096 byte:
java -Dcom.ibm.CORBA.FragmentSize=4096 myapp
La dimensione predefinita del frammento è 1024 byte. E possibile disattivare la frammentazione impostando la dimensione del frammento su 0.
java -Dcom.ibm.CORBA.RequestTimeout=30
-Dcom.ibm.CORBA.LocateRequestTimeout=30 myapp
Come impostazione predefinita, ORB attende una risposta indefinitamente. Non impostare il timeout su un valore troppo basso, altrimenti le connessioni potrebbero terminare inutilmente.
Ad esempio, per far in modo che ORB usi la porta 1050, immettere:
java -Dcom.ibm.CORBA.ListenerPort=1050 myapp
Se viene impostata questa proprietà, ORB si mette in ascolto appena viene inizializzato. Altrimenti, inizia solo quando viene richiesto.
Quando si utilizza Java 2 SecurityManager, il richiamo di alcuni metodi nelle classi API di CORBA potrebbe comportare l'esecuzione di controlli sulle autorizzazioni, il che potrebbe comportare una SecurityException. I metodi interessati comprendono quanto segue:
| Classe/Interfaccia | Metodo | Autorizzazione richiesta |
|---|---|---|
|
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 (Stringa, booleano) |
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 |
Se i programmi di cui si dispone usano alcuni di questi metodi, assicurarsi che siano garantite le autorizzazioni necessarie.
Le classi di implementazione ORB in questo rilascio sono:
Questi sono i valori predefiniti, e viene posta all'attenzione l'avvertenza di non impostare queste proprietà o di fare riferimento direttamente alle classi di implementazione. Per la portabilità, fare riferimento alle classi API di CORBA API e non all'implementazione. Questi valori potrebbero essere modificati nei prossimi rilasci.
RMI (Remote Method Invocation) Java fornisce un semplice meccanismo per effettuare programmazione distribuita Java. RMI su IIOP (RMI-IIOP) utilizza il protocollo IIOP (Internet Inter-ORB Protocol) standard dell'archietttura CORBA (Common Object Request Broker Architecture) per estendere RMI Java di base ed effettuare comunicazioni. In tal modo, si consente la diretta interazione con qualsiasi altro ORB (CORBA Object Request Brokers), sia che sia implementato in Java che in qualsiasi altro linguaggio.
È disponibile la seguente documentazione:
Per impostazione predefinita, il pooling dei thread per i gestori di connessioni RMI non è abilitato.
Per abilitare il pooling delle connessioni implementato a livello del trasporto TCP RMI, impostare l'opzione
-Dsun.rmi.transport.tcp.connectionPool=true (o un qualsiasi valore non nullo)
Questa versione di Runtime Environment non ha alcuna impostazione che è possibile utilizzare per limitare il numero di thread nel pool delle connessioni.
Per ulteriori informazioni, consultare il sito Java della Sun: http://java.sun.com.
IBM SDK comprende il supporto bidirezionale avanzato. Per ulteriori informazioni, consultare http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html . Il Javadoc per questo pacchetto bidirezionale è fornito con il SDK nel file docs/apidoc.zip.
Da Java 5.0, la classe BigDecimal IBM è stata adottata dalla Sun come java.math.BigDecimal. | IBM non effettua più manutenzione su com.ibm.math.BigDecimal ed è contrassegnato come sconsigliato. | Si raccomanda di migrare il codice Java esistente in modo che usi java.math.BigDecimal.
|Il nuovo java.math.BigDecimal usa gli stessi metodi di entrambe le precedenti |java.math.BigDecimal e com.ibm.math.BigDecimal. Il codice esistente che usa java.math.BigDecimal |continua a funzionare correttamente.
|Per migrare il codice Java esistente in modo che usi la classe java.math.BigDecimal, cambiare l'istruzione di importazione |in cima al file java da: import com.ibm.math.*; in import java.math,*;.
IBM SDK e Runtime Environment impostano l'Euro come valuta predefinita per quelle nazioni dell'EMU (European Monetary Union) per le date a partire dal 1 gennaio, 2002.
Per usare la valuta nazionale, specificare -Duser.variant=PREEURO sulla riga comandi Java.
Se si sta usando la locale UK, Danese o Svedese e si vuole usare l'Euro, specificare -Duser.variant=EURO sulla riga comandi Java.
L'interfaccia delle applicazioni di programmazione (API) di Java Communications (JavaComm) è un pacchetto facoltativo fornito per essere usato con Runtime Environment per Windows. JavaComm viene installato indipendentemente da SDK o da Runtime Environment.
L'API di JavaComm fornisce alle applicazioni Java un modo indipendente dalla piattaforma per eseguire comunicazioni tra porte seriali e parallele per tecnologie come voice mail, fax e smartcard. Dopo aver scritto comunicazioni per porte seriali o parallele per le applicazioni, è possibile includere quei file nelle proprie applicazioni.
L'API di Java Communications supporta le porte seriali di Electronic Industries Association (EIA)-232 (RS232) e le porte parallele dell'Institute of Electrical and Electronics Engineers (IEEE) 1284 ed è supportata su sistemi con IBM Versione 5.0 Runtime Environment.
Con l'utilizzo di Java Communications API, è possibile:
Accertarsi che una copia di SDK o di Runtime Environment venga installata prima di installare l'API di Java Communications.
Per installare l'API di Java Communications da un file zip :
Se durante l'installazione di Runtime Environment è stata accettata la directory predefinita, il file comm.jar si troverà in C:\Program Files\IBM\Java50\jre\lib\ext.
Se il file ZIP viene decompresso in un'altra directory, i file verranno memorizzati nella stessa struttura di directory, mentre C:\Program Files\IBM\Java50\ viene sostituita dalla directory in cui era stato decompresso il file.
Dopo aver installato Java Communications API, bisogna:
Quando si stampa con Java Communications API, potrebbe essere necessario premere "Alimentazione fogli" o "Continua" o qualcosa di simile sulla stampante.
Per disinstallare Java Communications API, cancellare i seguenti file dalla directory in cui è stato installato il Runtime Environment:
Per impostazione predefinita, Runtime Environment viene installato in C:\Program Files\IBM\Java50\.
E' possibile trovare trovare la documentazione API ed esempi di Java Communications API sul sito web della Sun: http://java.sun.com.
Il plug-in Java è un plug-in del browser Web. Se si utilizza il plug-in Java, è possibile ignorare il JVM predefinito del browser Web e utilizzare il Runtime Environment desiderato per eseguire gli applet o i bean nel browser.
Occorre consentire gli applet per terminare il caricamento in modo da impedire al browser di rimanere 'bloccato'. Ad esempio, se si utilizza il pulsante Indietro e quindi quello Avanti mentre si sta caricando un applet, è possibile che le pagine HTML non possano essere caricate.
La documentazione sul plug-in Java è resa disponibile dalla Sun presso il seguente sito: http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.
|
| |Sistema operativo | |Internet Explorer | |Netscape | |Mozilla |
|---|---|---|---|
| |Windows 2000 | |5.5 SP2, 6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows XP | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows Server 2003 | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
Si noti che Internet Explorer 5.01, il browser predefinito su Windows 2000, |non è supportato.
A causa di limitazioni in alcuni browser, potrebbe non essere possibile implementare tutte le funzioni del pacchetto org.w3c.dom.html.
Il plug-in Java supporta i caratteri a doppio byte (ad esempio il Cinese tradizionale BIG-5, il Coreano e il Giapponese) come parametri per le tag <APPLET>, <OBJECT> e <EMBED>. E' necessario selezionare la codifica caratteri corretta per il documento HTML in modo che il plug-in Java possa analizzare il parametro. Specificare la codifica dei caratteri per il documento HTML utilizzando il tag <META> nella sezione <HEAD>, come riportato di seguito:
<meta http-equiv="Content-Type" content="text/html; charset=big5">
Questo esempio indica al browser di utilizzare la codifica caratteri Cinese BIG-5 per l'analisi del file HTML. Tutti i parametri vengono passati al plug-in Java in modo corretto. Tuttavia, alcune versioni meno recenti dei browser potrebbero non interpretare il tag correttamente. In questo caso, è possibile forzare il browser in modo da ignorare questo tag, ma potrebbe essere necessario modificare manualmente la codifica.
E' possibile specificare quale codifica utilizzare per l'analisi del file HTML:
E' possibile usare Java Web Start per distribuire le applicazioni Java. Web Start consente agli utenti di lanciare e di gestire le applicazioni direttamente dal Web. L'uso di Java Web Start consente di avviare facilmente le applicazioni dal Web, assicurandosi che si sta usando la versione più recente ed eliminando le procedure di installazione o di aggiornamento. Java Web Start elimina la necessità di scaricare ed installare il software, bypassando le opzioni di installazione.
|In aggiunta a java-vm-args documentata su http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, Web Start supporta -Xgcpolicy per l'impostazione della politica di raccolta dei dati obsoleti.
Per informazioni sui browser supportati da Web Start, consultare Browser supportati.
Per ulteriori informazioni su Web Start, consultare: http://java.sun.com/products/javawebstart e http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Per ulteriori informazioni sulla distribuzione delle applicazioni, consultare: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.
E' possibile richiamare Web Start in tre modi:
Una volta scaricata l'applicazione, questa viene memorizzata nella cache delle applicazioni Java. Se si accede di nuovo all'applicazione, Java Web Start scarica una versione più recente dell'applicazione, se disponibile, ed utilizza la versione nella cache nel caso che non vi siano versioni più recenti.
Se si verifica un errore in un file .jnlp (quale un nome tag non valido), Web Start non funziona e non visualizza alcun messaggio di errore.
Un'applicazione Java, diversamente da un applet Java, non può fare affidamento su browser Web per l'installazione e i servizi runtime. Quando si invia un'applicazione Java, il pacchetto software probabilmente è formato dalla parti seguenti:
Per eseguire l'applicazione, occorre Runtime Environment per Windows. Il software SDK per Windows contiene un Runtime Environment. Tuttavia, non è possibile supporre che il software SDK per Windows sia installato.
La licenza software SDK per Windows non consente di ridistribuire alcun file SDK con l'applicazione. Occorre assicurarsi che sia installata una versione su licenza di SDK per Windows sulla macchina di destinazione.
| | |L'IBM Virtual Machine (VM) consente di condividere classi bootstrap e delle applicazioni tra VM, memorizzandoli in una cache della memoria condivisa. La condivisione delle classi riduce il consumo totale della memoria virtuale quando più VM condividono una cache. La condivisione di classi riduce inoltre il tempo di avvio per un VM dopo la creazione della cache. La cache della classe condivisa è indipendente da qualsiasi VM attivo e persiste oltre la durata del VM che ha avviato la cache.
| |IBM SDK consente di condividere il maggior numero di classi possibile ed è trasparente all'utente.
| |La cache delle classi condivise contiene dati e metadati di classe statiche di sola lettura che descrivono le classi. Qualsiasi VM può leggere o aggiornare la cache. I VM che sono in condivisione devono essere allo stesso livello di release. Prestare molta attenzione |se viene utilizzata la modifica del bytecode di avvio. (Consultare Modifiche bytecode al runtime.)
| |Poiché la cache delle classi condivise persiste oltre la durata di qualsiasi VM, la cache viene aggiornata in modo dinamico per riflettere tutte le modifiche che potrebbero essere apportate ai JAR o alle classi nel sistema di file. L'aggiornamento dinamico rende la cache trasparente all'applicazione che la utilizza.
| |Abilitare la condivisione di classi con l'opzione -Xshareclasses quando si avvia un VM, |affinché il VM si colleghi ad una cache esistente oppure ne crei una se non esiste. Tutte le classi bootstrap e delle applicazioni caricate dal VM vengono condivise per impostazione predefinita. Classloader personalizzati effettuano automaticamente la condivisione se estendono il classloader delle applicazioni, altrimenti, devono utilizzare le API di Java Helper fornite con il VM per accedere alla cache. (Consultare Adattamento dei classloader personalizzati per la condivisione di classi.)
| |L'accesso alla cache delle classi condivise è limitato dalle autorizzazioni del sistema operativo e da quelle della sicurezza. Solo un programma di caricamento classi con classi di condivisione registrate può aggiungere classi alla cache delle classi condivise. Se viene installato un Java SecurityManager, ai ClassLoader, esclusi quelli di estensione, applicazione e bootstrap predefiniti, dovrà essere concessa l'autorizzazione alla condivisione di classi aggiungendo |SharedClassPermissions al file java.policy. (Consultare Utilizzo di SharedClassPermissions.) |RuntimePermission "createClassLoader" limita la creazione di nuovi ClassLoader e di conseguenza anche l'accesso alla cache.
| |Su un sistema possono esistere più cache e sono specificate per |nome come un'opzione secondaria del comando -Xshareclasses. Una VM può collegarsi ad una sola cache per volta. Viene specificata la dimensione della cache all'avvio utilizzando -Xscmx<n>[k|m|g], ma tale dimensione è quindi fissata per la durata della cache. Le cache esistono finché non vengono distrutte esplicitamente utilizzando un'opzione secondaria del comando |-Xshareclasses oppure finché il sistema non viene riavviato.
| |Tutti i programmi di utilità della cache sono opzioni secondarie del comando -Xshareclasses. Utilizzare -Xshareclasses:help per consultare un elenco di opzioni secondarie disponibili.
| |La condivisione di classi è abilitata e configurata utilizzando le opzioni -Xshareclasses e -Xscmx della riga comandi.
|Per abilitare la condivisione di classi, aggiungere -Xshareclasses[:name=<nome |alla riga comandi dell'applicazione. La VM si collegherà ad una cache esistente con il nome specificato oppure creerà una nuova cache con quel nome. Se è stata creata una nuova cache, in essa verranno inserite tutte le classi bootstrap e delle applicazioni caricate finché non si riempie. Se vengono avviati contemporaneamente due o più VM, popoleranno tutti contemporaneamente la cache.
|Per verificare che la cache sia stata creata, eseguire java -Xshareclasses:listAllCaches. Per verificare quante classi sono state memorizzate e quanti dati delle classi, eseguire java -Xshareclasses:[name=<nome>],printStats. Tali programmi di utilità possono essere eseguiti dopo che il VM dell'applicazione è stato terminato oppure in un'altra finestra comandi.
|Per visualizzare le classi caricate dalla cache oppure memorizzate nella cache, aggiungere -Xshareclasses:[name=<nome>],verbose alla riga comandi dell'applicazione.
|Per eliminare la cache creata, eseguire java -Xshareclasses:[name=<nome>],delete. Occorre eliminare le cache solo se contengono molte classi stale oppure se la cache è piena e si desidera crearne una più grande.
|Si consiglia di regolare la dimensione della cache per la specifica applicazione utilizzata, perché è improbabile che l'impostazione predefinita sia la dimensione ottimale. Il modo migliore per determinare la dimensione ottimale per la cache consiste nello specificare una cache di grandi dimensioni (utilizzando -Xscmx), eseguire l'applicazione e quindi utilizzare printStats per stabilire la quantità di dati di classe memorizzati. Aggiungere una piccola quantità al valore mostrato in printStats. Si noti che poiché le classi possono essere caricare in qualsiasi momento della durata della VM, è consigliabile eseguire questa analisi una volta terminata l'applicazione. Tuttavia, una cache completa non ha un impatto negativo sulle prestazioni o sulle funzionalità delle VM ad essa collegate, pertanto è possibile impostare una dimensione della cache più piccola di quella richiesta.
|Se una cache si riempie, viene emesso un messaggio sulla riga comandi di tutte le VM che utilizzano tale cache e le VM caricheranno ulteriori classi nella propria memoria processi. Le classi in una cache piena possono essere condivise, ma una cache piena è di sola lettura e non può essere aggiornata con nuove classi.
| |La condivisione di classi è particolarmente utile su sistemi che utilizzano più VM con un codice simile; i traggono vantaggio dal consumo ridotto di memoria virtuale. Inoltre, è utile su sistemi che avviano e chiudono VM di frequente, che traggono vantaggio dal miglioramento del tempo di avvio.
|Il sovraccarico per creare e popolare una nuova cache è minimo. Il consumo per il tempo di avvio per una singola VM è compreso tra 0 e 5%, a seconda di quante classi vengono caricate. Il miglioramento del tempo di avvio del VM con una cache popolata è di solito tra il 10% e il 40%, a seconda del sistema operativo e del numero di classi caricate. Più VM in esecuzione contemporaneamente mostrano maggiori vantaggi del tempo di avvio generale.
|Quando si esegue l'applicazione con la condivisione di classi, è possibile utilizzare gli strumenti del sistema operativo per visualizzare la riduzione del consumo della memoria virtuale.
| |La cache massima teorica è 2 GB. La cache viene limitata dai seguenti fattori:
| |Qualsiasi VM che utilizza un agente JVMTI, che può modificare bytecode, non è in grado di condividere le classi a meno che non si utilizzi l'opzione secondaria modified=<contesto_modificato> da riga comandi (consultare la sezione relativa). Il contesto modificato è un descrittore specificato dall'utente che descrive il tipo di modifica da effettuare. Tutti i VM che utilizzano un contesto modificato specificato devono modificare il |bytecode in un modo ripetibile e prevedibile per ciascuna classe, così che le classi memorizzate nella cache avranno le modifiche previste quando verranno caricate da un altro VM. Ogni modifica deve essere prevedibile poiché le classi caricate da una cache di classi condivise non può essere modificata di nuovo dall'agente. Si noti che bytecode modificati e non modificati possono essere memorizzati nella stessa cache. Consultare Diagnostics Guide per ulteriori informazioni su questo argomento.
| |Per sistemi operativi che possono eseguire applicazioni sia a 32 bit che a 64 bit, non è consentita la condivisione di classi tra VM a 32 bit e quelli a 64 bit. |L'opzione secondaria listAllCaches elencherà le cache a 31 bit e quelle a 64 bit, a seconda del modo di indirizzo del VM utilizzato.
|La cache delle classi condivise richiede spazio su disco per memorizzare le informazioni di identificazione relative alle cache esistenti sul sistema. Queste informazioni vengono posizionate nella directory del profilo utente. Se la directory delle informazioni di identificazione viene eliminata, il VM non può identificare le classi condivise sul sistema e devono ricreare la cache.
|Le autorizzazioni per l'accesso a una cache delle classi condivise vengono applicate dal sistema operativo. Se un nome della cache non è specificato, il nome utente viene |aggiunto al nome predefinito così che più utenti sullo stesso sistema creino la loro cache per impostazione predefinita.
| |Se SecurityManager viene utilizzato insieme alla condivisione delle classi e l'applicazione in esecuzione utilizza propri classloader, a tali devono essere concesse autorizzazioni SharedClassPermissions prima di poter condividere le classi. Aggiungere SharedClassPermissions |al file java.policy utilizzando al nome classe ClassLoader (i caratteri jolly sono consentiti) |e "read", "write" o "read,write" per determinare l'accesso concesso. |Ad esempio:
|permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";
Se un ClassLoader non ha l'autorizzazione SharedClassPermission corretta e tenta di condividere classi, viene inviata un'eccezione AccessControlException. Non è possibile modificare o ridurre le autorizzazioni dei classloader di estensione, applicazione o bootstrap predefiniti.
| |Più applicazioni Java utilizzeranno i propri classloader del VM oppure avranno classloader personalizzati |che estendono java/net/URLClassLoader. Le applicazioni che utilizzano tali classloader potranno condividere automaticamente le classi bootstrap e delle applicazioni. |I classloader personalizzati, che non estendono java/net/URLClassLoader, richiedono che le modifiche utilizzino la condivisione di classi. A tutti i classloader personalizzati dovranno essere concesse autorizzazioni SharedClassPermissions se viene utilizzato un SecurityManager. Consultare. Utilizzo di SharedClassPermissions. IBM fornisce svariate interfacce Java per diversi tipi di classloader personalizzati, che consentono ai classloader di individuare e memorizzare classi nella cache di classi condivise. |Tali classi si trovano nel pacchetto |com.ibm.oti.shared. Il Javadoc per questo pacchetto è fornito con il SDK nel file docs/apidoc.zip. |Consultare Diagnostics |Guide per ulteriori informazioni su queste interfacce.
Se si ha diritto ai servizi per il codice del programma conforme a IBM Solutions Developer Program, rivolgersi a IBM Solutions Developer Program attraverso il normale metodo di accesso oppure presso il seguente sito Web: http://www-1.ibm.com/partnerworld/.
Se è stato acquistato un contratto di servizio (cioè Personal Systems Support Line IBM oppure un servizio equivalente nel vostro paese), i termini e le condizioni di tale contratto di servizio determinano a quali servizi si ha diritto, se disponibili, rispetto al programma.
Le guide per l'utente fornite con SDK e Runtime Environment sono state testate usando dei lettori di schermi. E' possibile usare uno screen reader come Home Page Reader o JAWS con queste guide.
Per cambiare le dimensioni dei font nelle guide, usare la funzione fornita dal browser, che di solito si trova nel menu Visualizza.
Per gli utenti che richiedono la navigazione tramite tastiera, una descrizione delle sequenze di tasti per le applicazioni Swing è reperibile in "Swing Key Bindings" all'indirizzo Webhttp://www-128.ibm.com/developerworks/java/jdk/additional/
|Oltre alla GUI, il tool iKeyman fornire il tool di riga comandi IKEYCMD, che ha le stesse funzioni della GUI. IKEYCMD consente di gestire chiavi, certificati e richieste di |certificato. E' possibile chiamare IKEYCMD dagli script shell nativi e dai programmi che devono essere usati quando le |applicazioni hanno bisogno di aggiungere interfacce personalizzate al certificato e alle attività di gestione chiavi. IKEYCMD può creare file di database per tutti i tipi che |iKeyman supporta al momento. IKEYCMD può inoltre creare richieste di certificati, importare |certificati firmati CA e gestire certificati auto-firmati.
Per eseguire un comando IKEYCMD, immettere:
java [-Dikeycmd.properties=<properties file>]com.ibm.gsk.ikeyman.ikeycmd <oggetto> <azione> [opzioni]
dove:
Per ulteriori informazioni, consultare la guida di iKeyman all'indirizzo: http://www.ibm.com/developerworks/java/jdk/security/index.html.
Se ci si sposta lateralmente lungo l'elenco a discesa del componente JComboBox con i tasti del cursore, il pulsante o il campo editabile delle caselle combinate non modificano il loro valore finché non viene selezionata una voce. Questo è il comportamento desiderato per questo rilascio e migliora l'accessibilità e l'usabilità assicurando che il comportamento trasversale della tastiera sia coerente con quello del mouse.
IBM Java Web Start v5.0 contiene diversi miglioramenti di accessibilità ed utilizzo rispetto ai release precedenti, compreso un supporto migliore per screen reader e una tastiera per la navigazione migliorata.
E' possibile usare la riga comandi solo per lanciare un'applicazione Java abilitata per Web Start. Per cambiare le opzioni delle preferenze, editare il file di configurazione, Application Data\IBM\Java\Deployment\deployment.properties nella directory principale dell'utente. Prima di modificare questo file farne una copia di riserva. Non tutte le preferenze impostabili in Java Application Cache Viewer sono disponibili nel file di configurazione.
È possibile ottenere file delle politiche di giurisdizione illimitata da http://www.ibm.com/developerworks/java/jdk/security/index.html. La documentazione relativa a JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS e dei pacchetti di sicurezza IBM e la crittografia hardware è anche disponibile presso questo sito Web.
Prendere nota di queste limitazioni in IBM 32-bit SDK for Windows, v5.0:
Se si verifica questa eccezione, si può impostare la proprietà di sistema java.nio.debug=pipe per vedere quali sono i numeri delle porte bloccate.
Se si hanno dei commenti da esprimere relativi all'utilità o dei commenti di qualsiasi tipo su questa guida è possibile utilizzare uno dei canali riportati di seguito. Si noti che tali canali non sono impostati per rispondere ad interrogazioni tecniche ma sono intesi solo per i commenti relativi alla documentazione. Inviare i commenti a:
Annotazioni. Inviando un messaggio alla IBM, tutte le informazioni in esso contenute, incluso i dati di feedback, come ad esempio domande, commenti, suggerimenti verranno ritenute non riservate e IBM non avrà nessun obbligo di nessun tipo rispetto a tali informazioni e potrà riprodurle, utilizzarle, diffonderle e distribuirle a terzi illimitatamente. IBM inoltre, si riserva il diritto di utilizzare idee, concetti, conoscenze o tecniche contenute in tali informazioni per qualsiasi scopo, incluso ma non limitato allo sviluppo, fabbricazione e commercializzazione di prodotti che incorporano tali informazioni.
Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati Uniti d'America. E' possibile che la IBM non offra i prodotti, i servizi o le funzioni trattati in questo documento in altri paesi. Consultare il rappresentante commerciale IBM per informazioni relative ai prodotti e servizi disponibili nel proprio paese. Ogni riferimento a prodotti programmi o servizi IBM non significa che possano essere usati soltanto tali programmi, prodotti o servizi. In sostituzione a quelli forniti dall'IBM, possono essere usati prodotti, programmi o servizi funzionalmente equivalenti che non comportino violazione dei diritti di proprietà intellettuale. Tuttavia, è responsabilità dell'utente valutare e verificare la possibilità di usare programmi, prodotti o servizi non IBM.
L'IBM può avere brevetti o domande di brevetto in corso relativi a quanto trattato nella presente pubblicazione. La fornitura di questa pubblicazione non implica la concessione di alcuna licenza su di essi. Chi desiderasse ricevere informazioni relative a licenze può rivolgersi per iscritto a:
Chi desiderasse ricevere delucidazioni sulle licenze relative alle informazioni DBCS, può contattare IBM Intellectual Property Department nel proprio paese o rivolgersi per iscritto a:
Il seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui leggi nazionali siano in contrasto con le disposizioni in esso contenute:
L'IBM FORNISCE QUESTA PUBBLICAZIONE SENZA ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI GARANZIE DI COMMERCIABILITÀ' ED IDONEITÀ' AD UNO SCOPO PARTICOLARE. Alcune nazioni non escludono le garanzie implicite; di conseguenza la suddetta esclusione potrebbe, in questo caso, non essere applicabile.
Queste informazioni potrebbero contenere imprecisioni tecniche o errori tipografici. Le correzioni relative saranno incluse nelle nuove edizioni. L'IBM si riserva il diritto di apportare miglioramenti o modifiche al prodotto o al programma descritto in qualsiasi momento e senza preavviso.
Tutti i riferimenti a pubblicazioni e a siti Web non dell'IBM contenuti in questo documento sono forniti solo per consultazione. I materiali contenuti in tali pubblicazioni e siti Web non fanno parte di questo prodotto e l'utilizzo di questi è a discrezione dell'utente.
L'IBM può utilizzare o distribuire qualsiasi informazione voi forniate nel modo più appropriato senza incorrere in alcuna obbligazione nei vostri riguardi.
Coloro che detengono la licenza su questo programma e desiderano avere informazioni su di esso allo scopo di consentire: (i) uno scambio di informazioni tra programmi indipendenti ed altri (compreso questo) e (ii) l'uso reciproco di tali informazioni, dovrebbero rivolgersi a:
Queste informazioni possono essere rese disponibili secondo condizioni contrattuali appropriate, compreso, in alcuni casi, l'addebito di un canone.
Il programma su licenza descritto in queste informazioni e tutto il materiale su licenza ad esso relativo sono forniti dall'IBM nel rispetto delle condizioni previste dalla licenza d'uso.
I dati relativi alle prestazioni contenuti nel presente documento sono stati ottenuti in un ambiente controllato. Pertanto, i risultati ottenibili in altri ambienti operativi potrebbero variare significativamente. Alcune rilevazioni sono state effettuate su sistemi in fase di sviluppo e non si garantisce in alcun modo che tali rilevazioni siano uguali su tutti i sistemi. Inoltre, alcune rilevazioni non state effettuate tramite estrapolazione. Pertanto, i risultati effettivi possono essere differenti. Gli utenti devono verificare l'applicabilità dei dati negli specifici ambienti operativi.
Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di tali prodotti. L'IBM non ha verificato tali prodotti e, pertanto, non può garantirne l'accuratezza delle prestazioni. Eventuali commenti relativi alle prestazioni dei prodotti non IBM devono essere indirizzati ai fornitori di tali prodotti.
IBM è un marchio della International Business Machines Corporation.
Java e tutti i marchi ed i logo basati su Java sono marchi della Sun Microsystems, Inc.
Microsoft, Windows e il logo Windows logo sono marchi della Microsoft Corporation negli Stati Uniti e/o in altre nazioni.
I nomi di altre società, prodotti e servizi potrebbero essere marchi di altre società.
Questo prodotto è basato anche parzialmente su FreeType Project. Per ulteriori informazioni su Freetype, consultare http://www.freetype.org.
Questo prodotto include il software sviluppato da Apache Software Foundation http://www.apache.org/.