IBM SDK a 64-bit per piattaforme Windows, Java Technology Edition, Versione 6

SDK e Manuale di Runtime



Copyright International Business Machines Corporation 2003, 2007. Tutti i diritti riservati.

Indice

Prefazione
Panoramica
Compatibilità versione
Migrazione da altri IBM JVM
Contenuti di SDK e Runtime Environment
Strumenti e classi di Runtime Environment
Strumenti SDK ed informazioni di riferimento
Installazione e configurazione di SDK e Runtime Environment
Operazioni preliminari
Installazione dei pacchetti
Installazione presidiata (interattiva)
Installazione di Runtime Environment come JVM (Java Virtual Machine) di sistema
Installazione non presidiata
Abilitazione di IBM Accessibility Bridge
Disabilitazione del supporto Java Accessibility
Informazione per gli utenti di lingue europee
Impostazione del path
Impostazione del percorso delle classi
Esecuzione di applicazioni Java
I comandi java e javaw
Recuperare informazioni sulla versione
Specificazione di opzioni Java e proprietà di sistema
Opzioni standard
Globalizzazione dei comandi java
Esecuzione automatica di un file Java
Compilatore Just-In-Time (JIT)
Come disabilitare JIT
Abilitazione di JIT
Come determinare se JIT è abilitato
Specificazione dei criteri di raccolta dei dati obsoleti
Opzioni di Raccolta dei dati obsoleti
Tempo di pausa
Riduzione della pausa
Ambienti con heap molto pieni
Supporto del simbolo dell'Euro
| |
Utilizzare i metodi di immissione per le lingue indiane e thailandesi
Utilizzo di SDK per lo sviluppo di applicazioni Java
| |
Utilizzare XML
| |
Migrazione a XL-TXE-J
| |
Informazioni di riferimento XML
Esecuzione del debug di applicazioni Java
Java Debugger (JDB)
Individuazione in un'applicazione di una JVM a 32 bit o 64 bit
Modalità di elaborazione di JVM dei segnali
Segnali utilizzati da JVM
Collegamento di un driver di codice nativo alla libreria concatenazione di segnali
Scrittura di applicazioni JNI
Configurazione dell'allocazione di memoria di pagine grandi
Supporto CORBA
Proprietà di sistema per tracciare l'ORB
Proprietà di sistema per ottimizzare ORB
Autorizzazioni Java Security per ORB
Classi di implementazione ORB
RMI su IIOP
Implementazione di Connection Handler Pool per RMI
BigDecimal migliorato
Applet Viewer
Operazioni con gli applet
Esecuzione delle applet con Applet Viewer
Esecuzione del debug delle applet con Applet Viewer
Invio di un'applicazione Java
Condivisione di dati di classe tra le JVM
Panoramica sulla condivisione dei dati di classe
Abilitazione e configurazione della condivisione dei dati delle classi
Creazione, popolamento ed eliminazione di una cache
Prestazioni e consumo della memoria
Considerazioni e restrizioni sull'utilizzo della condivisione dei dati delle classi
Limiti di dimensioni della cache
Modifiche bytecode al runtime
Limitazioni del sistema operativo
Utilizzo di SharedClassPermission
Adattamento dei classloader personalizzati per la condivisione di classi
Utilizzo dell'API Java Communications (JavaComm)
Installazione dell'API Java Communications da file compresso
Configurazione di Java Communications API
Specifica dei dispositivi nel file javax.comm.properties
Limitazioni di stampa con Java Communications API
Disinstallazione di Java Communications API
Documentazione di Java Communications API
Servizio e supporto per fornitori di software indipendente
Accessibilità
Tastiera trasversale di componenti JComboBox in Swing
Note generali sulla sicurezza
Commenti riguardanti il manuale per l'utente
Appendice A. Opzioni non standard
Appendice B. Limitazioni note
Informazioni particolari
Marchi

Prefazione

Questo manuale per l'utente fornisce informazioni generali su IBM SDK a 64-bit e Runtime Environment per Windows su architettura AMD64/EM64T, Java Technology Edition, Versione 6 ed informazioni specifiche sulle differenze nell'implementazione IBM rispetto all'implementazione Sun.

Leggere questo manuale per l'utente insieme alla documentazione più esaustiva presente sul sito web della Sun: http://java.sun.com.

SDK e Runtime Environment sono supportati sui seguenti prodotti:

Il Manuale per la diagnostica fornisce informazioni più dettagliate sulla Virtual Machine IBM per Java.

Questo manuale per l'utente fa parte di un rilascio ed è applicabile solo a tale rilascio specifico. Assicurarsi di possedere il manuale per l'utente appropriato per il rilascio che si sta utilizzando.

In questo manuale per l'utente, i termini "Runtime Environment" e "Java Virtual Machine" sono utilizzati scambievolmente.

|Le modifiche tecniche presenti in questa versione del manuale per l'utente, oltre a quelle meno importanti oppure ovvie, sono indicate in blu durante la visualizzazione in un Centro Informazioni, in rosso con barre verticali a sinistra delle modifiche durante la visualizzazione in HTML o nella stampa a colori, oppure da barre verticali a sinistra delle modifiche durante la visualizzazione in PDF.

The Codice Programma non è progettato o inteso per essere utilizzato per il controllo in tempo reale di aerei, traffico aereo, navigazione aerea o comunicazioni aeree; o nella progettazione, costruzione, funzionamento o manutenzione di qualsiasi apparecchiatura nucleare.

Panoramica

IBM SDK è un ambiente di sviluppo per la scrittura e l'esecuzione di applet e applicazioni conformi a Java 6 Core Application Program Interface (API).

SDK comprende Runtime Environment per Windows, che consente solo di eseguire le applicazioni Java. Se è installato SDK, è incluso Runtime Environment.

Runtime Environment contiene Java Virtual Machine e i file di supporto, compresi i e i file delle classi. Runtime Environment contiene solo un insieme secondario delle classi contenute nell'SDK e consente l'esecuzione dei programmi Java, ma non la compilazione di programmi Java. Runtime Environment per Windows non include alcun tool di sviluppo, come appletviewer.exe o il compilatore Java (javac.exe), o le classi destinate solamente ai sistemi di sviluppo.

Inoltre, viene fornito il pacchetto API (Application Programming Interface) di Java Communications, da utilizzare con Runtime Environment per Windows. Per informazioni, consultare la sezione Utilizzo dell'API Java Communications (JavaComm).

Compatibilità versione

In generale, qualsiasi applet o applicazione eseguibile con una versione precedente di SDK dovrebbe funzionare correttamente con IBM 64-bit SDK per Windows, v6. Non è garantito che le classi compilate con questo rilascio funzionino con i rilasci precedenti.

Per informazioni su questioni di compatibilità tra i rilasci, consultare il sito web della Sun:

|http://java.sun.com/javase/6/webnotes/compatibility.html

http://java.sun.com/j2se/5.0/compatibility.html

http://java.sun.com/j2se/1.4/compatibility.html

http://java.sun.com/j2se/1.3/compatibility.html

Se si sta utilizzando l'SDK come parte di un altro prodotto (ad esempio, IBM WebSphere Application Server), e si desidera aggiornare un livello precedente dell'SDK è possibile che le classi serializzate e v5.0 non siano compatibili. Ad ogni modo, le classi sono compatibili tra i differenti aggiornamenti di servizio.

Migrazione da altri IBM JVM

Dalla versione 5.0, il Runtime Environment IBM per Windows contiene le nuove versioni della Virtual Machine IBM per Java e il compilatore JIT (Just-In-Time).

Se si sta eseguendo la migrazione da una versione più vecchia di IBM Runtime Environment, notare che:

Contenuti di SDK e Runtime Environment

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.

I manuali per l'utente, Javadoc, e la relativa licenza , i file di copyright, javadoc, e la directory demo costituiscono la sola documentazione inclusa in questa SDK per Windows. E' possibile visualizzare la documentazione software della Sun visitando il sito web della Sun oppure scaricando il pacchetto della documentazione software della Sun sul sito web della Sun: http://java.sun.com.

Strumenti e classi di Runtime Environment

Un elenco di classi e tool utilizzabili con Runtime Environment standard.

Strumenti SDK ed informazioni di riferimento

Un elenco di strumenti e di informazioni di riferimento inclusi nell'SDK standard.

I seguenti tool sono parte di SDK e si trovano nella directory C:\Program Files\IBM\Java60\bin:
appletviewer.exe (Visualizzatore Applet Java)
Testa ed esegue applet al di fuori di un browser web.
apt.exe (Annotation Processing Tool)
Trova ed esegue processori di annotazione basati sulle annotazioni presenti nella serie di file sorgente specificati esaminati.
extcheck.exe (programma di utilità Extcheck)
Rileva i conflitti di versione tra il file jar di destinazione e i file con estensione jar installati al momento.
idlj.exe (Compilatore IDL su Java)
Genera binding Java da un dato file IDL.
ikeycmd.exe (utilità da riga comandi iKeyman)
Consente di gestire chiavi, certificati, e richieste di certificato da riga comandi. Per ulteriori informazioni consultare Security Guide e visitare il sito http://www.ibm.com/developerworks/java/jdk/security.
jar.exe (Tool di archiviazione Java)
Combina file multipli in un singolo file jar (Java Archive).
jarsigner.exe (Firma JAR e tool di verifica)
Genera firme per i file JAR e verifica le firme dei file JAR firmati.
java-rmi.exe (strumento di inoltro richieste HTTP-to-CGI)
Accetta le richieste RMI su HTTP e le inoltra a un server RMI in attesa su una qualsiasi porta.
javac.exe (Compilatore Java)
Compila programmi scritti in linguaggio di programmazione Java in bytecodes (codice Java compilato).
javadoc.exe (Java Documentation Generator)
Genera pagine HTML di documentazione API dai file sorgente Java.
javah.exe (Intestazione in C e generatore di file matrice)
Abilita l'associazione dei metodi nativi con il codice scritto in linguaggio di programmazione Java.
javap.exe (Disassemblatore file di classe)
Disassembla i file compilati e può stampare una rappresentazione dei bytecode.
javaw.exe (Interprete Java)
Esegue le classi Java nello stesso modo del comando java, ma non usa una finestra di console.
jconsole.exe (strumento JConsole di monitoraggio e gestione)
Effettua il monitoraggio delle JVM da locale e remoto, mediante una GUI. JMX-compliant.
jdb.exe (Programma di debug Java)
Aiuta ad eseguire il debug dei propri programmi Java.
jdmpview.exe (Programma di formattazione del dump di piattaforme incrociate)
Analizza i dump. Per ulteriori informazioni, consultare il Manuale per la diagnostica.
native2ascii.exe (Convertitore di Native-To-ASCII)
Converte un file con codifica nativa in un file ASCII contenente caratteri codificati in Latin-1 o in Unicode o in entrambi.
rmic.exe (Convertitore matrice RMI (Remote Method Invocation)Java)
Genera matrici, strutture e congiunzioni per gli oggetti remoti. Include RMI oltre al supporto del protocollo RMI_IIOP (Internet Inter-ORB Protocol).
schemagen.exe
Crea un file di schema per ogni spazio nomi referenziato nelle proprie classi Java.
serialver.exe (Comando di versione seriale)
Restituisce il serialVersionUID per uno o più classi in un formato appropriato per la copia in una classe in evoluzione.
wsgen.exe
Genera risorse JAX-WS portabili utilizzate nei servizi web JAX-WS.
wsimport.exe
Genera risorse JAX-WS portabili da un file WSDL.
xjc.exe
Compila file di schema XML.
File include
Intestazione in C per programmi JNI.
Demo
La directory demo contiene un numero di sottodirectory contenenti esempi di codifica sorgente, demo, applicazioni e applet da usare. |Dalla versione 6, il demo RMI-IIOP non è incluso nell'SDK.
copyright
Notizie riguardanti il copyright del SDK per il softwareWindows.
Licenza

Il file della Licenza, C:\Program Files\IBM\Java60\docs\content\<locale>\LA_<locale>, contiene l'accordo di licenza per l'SDK per il software Windows (dove <locale> è il nome della locale utilizzata, ad esempio en). Per visualizzare o stampare l'accordo di licenza, aprire il file in un browser Web.

Installazione e configurazione di SDK e Runtime Environment

Utilizzare la procedura guidata d'installazione oppure il file compresso per installare l'SDK. Configurare l'SDK mediante le variabili d'ambiente, le opzioni da riga comandi, e i file delle proprietà.

Operazioni preliminari

per installare SDK oppure il pacchetto Runtime Environment, scaricare il relativo pacchetto di installazione. Assicurarsi di aver scaricato tutti i pacchetti nella stessa directory e che ci sia spazio sufficiente nella directory temporanea.

I pacchetti ed i relativi nomi file sono elencati in Installazione dei pacchetti; 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.

Installazione dei pacchetti

È possibile installare diversi pacchetti in maniera indipendente, incluso l'SDK, Runtime Environment, Javacomm, la documentazione, e le demo.

I pacchetti che possono essere installati sono:

Altri pacchetti vengono forniti come file compressi:

Se si installa l'SDK oppure Runtime Environment dal pacchetto compresso, non sarà possibile utilizzare Web Start o il plug-in Java, ed il pannello di controllo conterrà una scheda Aggiorna non funzionante.

Installazione presidiata (interattiva)

Utilizzare l'installazione presidiata per installare l'SDK oppure JRE su un singolo client.

  1. Avviare ibm-java-sdk-60-win-x86_64.exe (per SDK) o ibm-java-jre-60-win-x86_64.exe (solo per Runtime Environment).
  2. Seguire le istruzioni indicate nella procedura guidata di installazione.

    Viene installato Runtime Environment per impostazione predefinita nella directory C:\Program Files\IBM\Java60\jre.

    Se si è scaricato il pacchetto installabile dell'SDK, è possibile scegliere quali componenti installare:

    Per la procedura di installazione, vengono visualizzate le seguenti opzioni:

    In Windows Vista, è possibile che si verifichi un ritardo dopo aver selezionato la lingua d'installazione.

    Se l'installazione non riesce e viene generato un messaggio di errore "Errore nell'applicare la trasformata", le informazioni di configurazione di Windows Installer sono corrotte. Per riparare l'errore, utilizzare l'utilità Windows Installer CleanUp da http://support.microsoft.com/kb/290301 per sostituire le informazioni di configurazione di Windows Installer corrotte.

Installazione di Runtime Environment come JVM (Java Virtual Machine) di sistema

Quando si installa Runtime Environment (sia come parte del pacchetto installabile SDK, sia dal pacchetto installabile Runtime Environment), viene richiesto se si desidera installare Runtime Environment come JVM (Java Virtual Machine) di sistema. Se lo si installa come JVM di sistema, il programma di installazione copia i programmi di avvio java.exe, javacpl.cpl, javaws.exe e javaw.exe nella directory di sistema di Windows.

Se una versione di java.exe o javaw.exe è presente attualmente nella directory di sistema di Windows, viene richiesto di sovrascrivere la versione esistente con quella attuale. L'installazione di questi file nella directory di sistema di Windows rende questo Runtime Environment la JVM predefinita per il sistema. In aggiunta, la chiave di registro "Current Version" viene impostata per corrispondere a questa installazione.

Nota: L'installazione di Runtime Environment come JVM di sistema copia solo java.exe e javaw.exe dentro la directory di sistema di Windows. Non viene copiato nessun altro programma (quale ad esempio javac.exe o appletviewer.exe).

Installazione non presidiata

Utilizzare l'installazione non presidiata per installare l'SDK o JRE su più client.

Per creare un'installazione non presidiata, per prima cosa è necessario completare un'installazione presidiata e creare un file di 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-java-sdk-60-win-x86_64 /r

oppure

ibm-java-jre-60-win-x86_64 /r

A seconda del proprio prodotto Windows, viene creato un file di risposte (setup.iss) nella directory C:\Windows oppure C:\Winnt.

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 viene visualizzato questo messaggio, fare clic su No ed uscire dall'installazione. Andare sulla directory di sistema di Windows ed eliminare 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 un'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-java-sdk-60-win-x86_64 /s /f1c:\Windows\setup.iss /f2c:\setup.log
ibm-java-jre-60-win-x86_64 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Nota:
  1. Dopo /f1 o /f2 non vi sono spazi.
  2. L'opzione /f1 specifica il nome e l'ubicazione del file delle risposte. Il segnalatore /f2 specifica il nome e l'ubicazione del file di log.

Se l'installazione viene completata con esito positivo, il file di registrazione conterrà la stringa ResultCode=0. Se l'installazione non è riuscita, il file di log conterrà un differente codice di risultato.

Abilitazione di IBM Accessibility Bridge

Per impostazione predefinita, IBM Accessibility Bridge è stato installato ma non abilitato. Per abilitare IBM Accessibility Bridge, rimuovere il commento della voce assistive_technologies nel file Accessibility.properties.

Il file Accessibility.properties si trova nella directory jre/lib. Eliminare il simbolo # all'inizio della seguente riga:

#assistive_technologies=JawBridge

Questo sito Web fornisce ulteriori informazioni sulle Accessibility Utilities:

http://java.sun.com/products/jfc/accessibility.html

Disabilitazione del supporto Java Accessibility

È possibile disabilitare il supporto Java Accessibility per migliorare le prestazioni di caricamento JVM di applicazioni Java che non forniscono supporto di tecnologia assistiva Java, specialmente sui collegamenti di rete. Per disabilitare il supporto Java Accessibility, impostare la variabile d'ambiente JAVA_ASSISTIVE su OFF.

Una tecnologia assistiva, quale JawBridge, non è disponibile se questa variabile d'ambiente è impostata su OFF, anche se la tecnologia è abilitata nel file Accessibility.properties.

Informazione per gli utenti di lingue europee

In Windows, un processo possiede due codepage: la codepage ANSI (oppure Windows) e la codepage OEM (oppure DOS). Il comando javaw utilizza sempre la codepage ANSI a meno che non sia stata impostata la proprietà di sistema console.encoding.

La finestra comandi di solito utilizza la codepage OEM. L'output della console Java utilizza la codepage della finestra comandi dal quale si avvia Java. Tuttavia, il comando javaw utilizza sempre la codepage ANSI. È possibile specificare la codepage da utilizzare per l'output della console output con l'opzione -Dconsole.encoding su java oppure con il programma di avvio javaw. Ad esempio, mediante il comando -Dconsole.encoding=Cp1252 tutti gli output della console saranno nella codepage Windows ANSI Latin1 (1252).

Impostazione del path

Se si altera la variabile d'ambiente PATH, si sovrascriverà ogni programma di avvio Java presente nel proprio percorso.

La variabile d'ambiente PATH abilita Windows a trovare programmi ed utilità, come per esempio javac, java, e javadoc, da ogni directory corrente. Per visualizzare il valore corrente del proprio PATH, immettere in quanto segue richiesta comandi:

echo %PATH%

Per aggiungere i programmi di avvio Java al proprio percorso:

  1. Se è stato installato SDK oppure Runtime Environment in C:\Program Files\IBM\Java60\, aggiungere le seguenti directory alla variabile d'ambiente PATH:
  2. Chiudere e riaprire ogni finestra di richiesta comandi per attivare la nuova variabile d'ambiente PATH.

Dopo aver impostato il percorso, è possibile eseguire uno strumento digitandone il nome da una richiesta comandi a partire da qualsiasi directory. Ad esempio, per compilare il file Myfile.Java, da richiesta comandi, digitare:

javac Myfile.Java

Impostazione del percorso delle classi

Il percorso delle classi dice ai tool SDK, come java, javac, e javadoc, dove trovare le librerie delle classiJava.

È necessario impostare il percorso di classe esplicitamente soltanto se:

Per visualizzare il valore attuale della propria variabile d'ambiente CLASSPATH, digitare il comando seguente in una richiesta comandi:

  echo %CLASSPATH%

Se si sviluppa e si eseguono applicazioni che usano differenti ambienti runtime, comprese altre versioni installate separatamente, bisogna impostare esplicitamente CLASSPATH e PATH per ciascuna applicazione. Se si eseguono applicazioni multiple simultaneamente e si usano differenti ambienti runtime, ciascuna applicazione deve essere eseguita in una propria richiesta comandi.

Esecuzione di applicazioni Java

È possibile avviare le applicazioni Java mediante il programma di avvio java oppure mediante JNI. Le impostazioni vengono passate a un'applicazione Java mediante argomenti da riga comandi, variabili d'ambiente, e file di proprietà.

I comandi java e javaw

Una breve introduzione ai comandi java e javaw.

Funzione

I tool java e javaw avviano un'applicazione Java avviando Java Runtime Environment e caricando classe specificata.

Il comando javaw e java sono identici, ma javaw 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.

Utilizzo

La 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.

I comandi java e javaw hanno la seguente sintassi:

java [ opzioni ] <classe> [ argomenti ... ]
java [ opzioni ] -jar <file.jar> [ argomenti... ]
javaw [ opzioni ] <classe> [ argomenti ... ]
javaw [ opzione ] -jar <file.jar> [ argomenti ... ]

Parametri

[opzioni]
Opzioni riga comandi da passare all'ambiente runtime.
<classe>
Classe di startup. La classe deve contenere un metodo main().
<file.jar>
Il nome del file jar da richiamare. Utilizzare solo con l'opzione -jar. Il file jar indicato deve contenere i file di risorsa e di classe dell'applicazione, insieme classe di startup specificata nell'intestazione manifest Main-Class.
[argomenti ...]
Argomenti di riga comandi da passare alla funzione main() della classe di startup.

Recuperare informazioni sulla versione

Il numero di versione e di build IBM per la propria installazione Java si ottiene mediante l'opzione -version. |È anche possibile ottenere informazioni sulla versione per tutti i file jar sul percorso della classe utilizzando l'opzione -Xjarversion.

  1. Aprire una richiesta comandi.
  2. Immettere il seguente comando:
    java -version
    Verranno visualizzate informazioni simili a quelle che seguono:
    java version "1.6.0-internal"
    Java(TM) SE Runtime Environment (build 20070405_01)
    IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows Vista amd64-64 jvmwa6460-20070326_12091 (JIT abilitato)
    J9VM - 20070326_12091_LEdSMr
    JIT  - dev_20070326_1800
    GC   - 20070319_AA)
    La data precisa e le versioni della build saranno differenti.

| |

È anche possibile creare un elenco delle informazioni sulla versione |per tutti i file jar disponibili nel percorso di classe, nel percorso di classe di avvio, |e nella directory delle estensioni; digitare il seguente comando:

|
java -Xjarversion
|

Verranno visualizzate informazioni simili a quelle che seguono:

|
...
|C:\Program Files\IBM\Java60\jre\lib\ext\ibmpkcs11impl.jar  VERSIONE: 1.0 build_20070125
|C:\Program Files\IBM\Java60\jre\lib\ext\dtfjview.jar
|C:\Program Files\IBM\Java60\jre\lib\ext\xmlencfw.jar  VERSIONE: 1.00, 20061011  LIVELLO: -20061011
|
|...
|

Le informazioni disponibili possono variare per ciascun file jar |e derivano dalle proprietà Implementation-Version e Build-Level |nel manifesto del file jar.

Specificazione di opzioni Java e proprietà di sistema

È possibile specificare opzioni Java e proprietà di sistema della riga comandi, utilizzando un file di opzioni, oppure una variabile d'ambiente.

Questi metodi per specificare opzioni Java sono elencati in ordine di precedenza:

  1. Specificare l'opzione o la proprietà sulla riga comandi. Ad esempio:
    java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
  2. Creare un file che contiene le opzioni e specificarlo sulla riga comandi utilizzando -Xoptionsfile=<file>.
  3. Creare una variabile d'ambiente denominata IBM_JAVA_OPTIONS contenente le opzioni. Ad esempio:
    set IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"

Le opzioni più a destra sulla riga comandi hanno la precedenza su quelle più a sinistra; ad esempio, se si specifica:

java -Xint -Xjit myClass

L'opzione-Xjit ha la precedenza.

Opzioni standard

Definizioni delle opzioni standard.

-agentlib:<nomelib>[=<opzioni>]
Carica la libreria dell'agente nativo <libname>; ad esempio -agentlib:hprof. Per ulteriori informazioni, specificare -agentlib:jdwp=help e-agentlib:hprof=help sulla riga comandi.
-agentpath:nomelib[=<opzioni>]
Carica un libreria dell'agente nativo con il nome completo del percorso.
-cp <directory o file jar o zip separati da ;>
Imposta il percorso di ricerca per risorse e classi dell'applicazione. Se non vengono utilizzate -classpath e -cp e non si imposta la variabile d'ambiente CLASSPATH, il percorso di classe dell'utente è, per impostazione predefinita, la directory corrente (.).
-classpath <directory o file jar o zip separati da ;>
Imposta il percorso di ricerca per risorse e classi dell'applicazione. Se non vengono utilizzate -classpath e -cp e non si imposta la variabile d'ambiente CLASSPATH, il percorso di classe dell'utente è, per impostazione predefinita, la directory corrente (.).
-D<nome proprietà>=<valore>
Imposta una proprietà di sistema.
-help o -?
Visualizza le informazioni relative all'utilizzo.
-javaagent:<jarpath>[=<opzioni>]
Carica un agente del linguaggio di programmazione Java. Per ulteriori informazioni, consultare la documentazione dell'API java.lang.instrument.
-jre-restrict-search
Include i JRE privati dell'utente nella ricerca della versione.
-no-jre-restrict-search
Esclude i JRE privati dell'utente dalla ricerca della versione.
-showversion
Visualizza la versione del prodotto e continua.
-verbose:<opzioni>
Abilita l'output dettagliato. Le opzioni disponibili sono:
classe
Scrive una voce nello stderr per ciascuna classe caricata.
gc
Invia informazioni dettagliate sulla raccolta dei dati obsoleti allo stderr. Utilizzare-Xverbosegclog per controllare l'output. Consultare ilManuale per la diagnostica per ulteriori informazioni.
jni
Scrive sullo stderr informazioni che descrivono i servizi JNI richiamati dall'applicazione e dalla JVM.
sizes
Scrive sullo stderr informazioni che descrivono le impostazioni di utilizzo della memoria attiva.
stack
Scrive sullo stderr informazioni che descrivono l'utilizzo di ciascun thread da parte di Java e C.
-version
SScrive la versione del prodotto.
-version:<valore>
Per essere eseguibile, richiede la versione specificata, ad esempio "1.5".
-X
Visualizza le istruzioni relative alle opzioni non standard.

Globalizzazione dei comandi java

I programmi di avvio java e javaw accettano argomenti e nomi di classe contenenti qualsiasi carattere della serie di caratteri della locale corrente. È possibile anche specificare un qualsiasi carattere Unicode nel nome classe e gli argomenti utilizzando le sequenze di escape Java.

A eseguire tale operazione, utilizzare l'azione riga comandi -Xargencoding.

-Xargencoding
Utilizza l'encoding dell'argomento. Per specificare un carattere Unicode, utilizzare sequenze di escape nel formato \u####, dove # è una cifra esadecimale (da 0 a 9, dalla A alla F).
-Xargencoding:utf8
Utilizza l'encoding UTF8.
-Xargencoding:latin
Utilizza l'encoding ISO8859_1.

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 tradotti. Tali messaggi differiscono in base alla lingua in cui Java è in esecuzione. Le descrizioni dettagliate dell'errore ed altre informazioni di debug restituite da java sono in lingua inglese.

Esecuzione automatica di un file Java

Per impostare una classe Java oppure un file jar in modo che vengano avviati automaticamente dall'Esplora risorse di Windows, utilizzare l'opzione Strumenti -> Opzioni Cartella -> Tipo file di Esplora risorse di Windows.

Oppure, da una richiesta comandi, immettere:

assoc .class=javaclass  
ftype javaclass=C:\Program Files\IBM\Java60\jre\bin\java.exe''%l''%*'

Nota:
  1. Il carattere %l rappresenta il numero 1 e non la lettera l.
  2. Se Java è installato in una directory diversa da C:\Program Files\IBM\Java60\, sostituire la directory di installazione del sistema utilizzato.

Compilatore Just-In-Time (JIT)

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. The compilatore JIT v6 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. È possibile disabilitare JIT al fine di facilitare l'individuazione di un problema. Se si verifica un problema durante l'esecuzione di un applet o di un'applicazione Java, è possibile disabilitare JIT al fine di facilitare l'individuazione del problema. La disabilitazione di JIT è solo una una soluzione temporanea; per prestazioni soddisfacenti è richiesto JIT.

Per ulteriori informazioni su JIT, consultare ilManuale per la diagnostica.

Come disabilitare JIT

JIT può essere disabilitato in modi differenti. Entrambe le opzioni di riga comandi sovrascrivono la variabile d'ambiente JAVA_COMPILER.

Disabilitare JIT è una misura temporanea che può aiutare a isolare i problemi durante l'esecuzione del debug di applicazioni Java.

Abilitazione di JIT

JIT è abilitato per impostazione predefinita. È possibile abilitare esplicitamente JIT in diversi modi. Entrambe le opzioni di riga comandi sovrascrivono la variabile d'ambiente JAVA_COMPILER.

Come determinare se JIT è abilitato

È possibile determinare lo stato di JIT utilizzando l'opzione -version.

Eseguire il programma di avvio java con l'opzione -version. Immettere quanto segue in 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 il Manuale per la diagnostica.

Specificazione dei criteri di raccolta dei dati obsoleti

Il Garbage Collector (raccoglitore di dati obsoleti) gestisce la memoria utilizzata da Java e dalle applicazioni in esecuzione con la JVM.

Quando il raccoglitore dei dati obsoleti riceve una richiesta per la memorizzazione, la memoria heap non usata viene messa da parte in un processo chiamato "assegnazione". La raccolta dei dati obsoleti controlla inoltre le aree di memoria cui non si fa più riferimento e le rilascia per consentire nuovamente il loro utilizzo. Questo processo è chiamato "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 per una chiamata System.gc() esplicita.

La raccolta dei dati obsoleti può influire significativamente sulle prestazioni dell'applicazione, per cui IBM virtual machine fornisce vari metodi per ottimizzare il modo in cui i dati obsoleti vengono eliminati, riducendo potenzialmente l'effetto sulle applicazioni.

Per ulteriori informazioni sulla raccolta di dati obsoleti, consultare il Manuale per la diagnostica.

Opzioni di Raccolta dei dati obsoleti

Le opzioni -Xgcpolicy controllano il comportamento del Raccoglitore di dati obsoleti. Bilanciano alla velocità dell'applicazione e quella del sistema generale, e le pause determinate dalla raccolta dei dati obsoleti.

Il formato dell'opzione ed i suoi valori sono:

-Xgcpolicy:optthruput
(Valore predefinito e raccomandato.) Fornisce una capacità di elaborazione elevata alle applicazioni, ma comporta pause occasionali.
-Xgcpolicy:optavgpause
Riduce il tempo impiegato dalle pause della raccolta dei dati obsoleti e limita l'effetto dell'incremento della memoria riservata nella lunghezza della pausa della raccolta dei dati obsoleti. Utilizzare optavgpause se la configurazione ha una memoria riservata molto grande.
-Xgcpolicy:gencon
Richiede l'uso combinato della raccolta dati obsoleti simultanea e generazionale per ridurre il tempo impiegato nella pausa della raccolta dei dati obsoleti.

Tempo di pausa

Quando il tentativo di un'applicazione di creare un oggetto non può essere immediatamente soddisfatto a causa dello spazio disponibile nell'heap, il raccoglitore dei dati obsoleti è responsabile dell'identificazione degli oggetti cui non si fa riferimento (obsoleti), della loro cancellazione e della reimpostazione dell'heap 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.

Riduzione della pausa

JVM utilizza due tecniche per ridurre i tempi di pausa: la raccolta dei dati obsoleti simultanea e la raccolta dei dati obsoleti generazionale.

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 sugli oggetti che hanno la maggior probabilità di essere riciclabili, è possibile ridurre ulteriormente i tempi di pausa per alcune applicazioni. La raccolta dati obsoleti generazionale riduce le pause 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.

Ambienti con heap molto pieni

Quando un heap Java è quasi pieno 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 l'heap viene utilizzato al limite delle sue capacità, è possibile che le prestazioni delle applicazioni ne risentano indipendentemente da quali opzioni di raccolta dei dati obsoleti vengano utilizzate; inoltre, se si continua ad inoltrare richieste per ulteriore spazio sull'heap, è possibile che l'applicazione riceva un OutOfMemoryError, che determina la chiusura della JVM se l'eccezione non viene catturata e gestita. A questo punto, la JVM genera un file Javadump da utilizzare per la diagnostica. In queste situazioni, si consiglia di aumentare la dimensione dell'heap utilizzando l'opzione e -Xmx oppure di ridurre il numero di oggetti in uso.

Per ulteriori informazioni, consultare il Manuale per la diagnostica.

Supporto del simbolo dell'Euro

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. Dall'1 gennaio 2008, anche Cipro e Malta avranno l'Euro come principale valuta.

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.

| | |

Utilizzare i metodi di immissione per le lingue indiane e thailandesi

|
|

A partire dalla versione 6, i metodi di immissione per le lingue indiane e i thailandesi non sono disponibili per impostazione predefinita. Per utilizzare i metodi di immissione per le lingue indiane e thailandesi, è necessario includere manualmente il file jar del metodo di immissione |nel percorso delle estensioni.Java.

|

Nella versione 5.0 i file jar dei metodi di immissione |erano inclusi nella directory jre\lib\ext ed erano caricati automaticamente dalla JVM. Nella versione 6, i file jar dei metodi di immissione |sono inclusi nella directory jre\lib\im e devono essere aggiunti manualmente al percorso delle estensioni Java per abilitare i metodi di immissione per le lingue indiane e thailandesi. Per eseguire l'operazione descritta utilizzare uno dei seguenti metodi:

| |

|

Se SDK or Runtime Environment installato in una directory differente, |sostituire C:\Program Files\IBM\Java60\ con |la directory in cui è installato SDK o Runtime Environment.

Utilizzo di SDK per lo sviluppo di applicazioni Java

L'SDK per Windows contiene diversi strumenti e librerie necessarie per lo sviluppo di software Java.

Consultare Strumenti SDK ed informazioni di riferimento per informazioni dettagliate sugli strumenti disponibili.

| | |

Utilizzare XML

|
|

IBM SDK contiene i parser XML4J e |XL XP-J, il compilatore XL TXE-J 1.0 XSLT, e l'interprete XSLT4J XSLT. |Questi strumenti consentono di analizzare sintatticamente, convalidare, trasformare, e serializzare i documenti XML indipendentemente da qualsiasi implementazione di elaborazione XML fornita.

|

|

Utilizzare i factory finder per localizzare le implementazioni delle classi factory astratte, come descritto in Selezione di un processore XML. |Mediante i factory finder, è possibile selezionare una libreria XML differente senza dover modificare il proprio codice |Java.

|

| |

Librerie XML disponibili

|

L'SDK IBM per Java contiene le seguenti librerie XML.

|
|
XML4J 4.5
|
|

XML4J è un parser di convalida che fornisce supporto ai seguenti standard: |

|
    |
  • XML 1.0 (edizione 4)
  • |
  • Spazio nomi in XML 1.0 (edizione 2)
  • |
  • XML 1.1 (edizione 2)
  • |
  • Spazio nomi in XML 1.1 (edizione 2)
  • |
  • W3C XML Schema 1.0 (edizione 2)
  • |
  • XInclude 1.0 (edizione 2)
  • |
  • OASIS XML Catalogs 1.0
  • |
  • SAX 2.0.2
  • |
  • DOM Livello 3 Nucleo, Carica e Salva
  • |
  • DOM Livello 2 Nucleo, Eventi, Trasverso e Range
  • |
  • JAXP 1.4
| |

XML4J 4.5 è basato su Apache Xerces-J 2.9.0. Consultare http://xerces.apache.org/xerces2-j/ per ulteriori informazioni.

|
|
XL XP-J 1.1
|
|

XL XP-J 1.1 è un parser ad alte prestazioni e non di convalida che fornisce |supporto a StAX 1.0 (JSR 173); un'API bidirezionale per il pull-parsing e la serializzazione del flusso dei documenti XML 1.0 e XML 1.1. Consultare la sezione Informazioni di riferimento XL XP-J per maggiori dettagli su ciò che è supportato da XL XP-J 1.1.

|
|
XL TXE-J 1.0.1 Beta
|
|

Nella versione 5.0, l'SDK IBM per Java includeva il compilatore XSLT4J e l'interprete. |L'interprete XSLT4J è abilitato per impostazione predefinita.

| |

Nella versione 6, l'SDK IBM per Java includeva |XL TXE-J. XL TXE-J include l'interprete XSLT4J 2.7.8 ed un nuovo compilatore XSLT. |Il nuovo compilatore è abilitato per impostazione predefinita. Il compilatore XSLT4J non è più incluso |nell'SDK IBM |per Java; |consultare Migrazione a XL-TXE-J per informazioni riguardanti la migrazione a XL TXE-J.

| |

XL TXE-J fornisce supporto ai seguenti standard: |

|
    |
  • XSLT 1.0
  • |
  • XPath 1.0
  • |
  • JAXP 1.4
|
|
|

| |

Selezione di un processore XML

|

La selezione del processore XML |viene eseguita utilizzando i service provider. Quando si utilizza un factory |finder, Java cerca nelle seguenti posizioni per vedere quale provider di servizi utilizzare: |

|
    |
  1. La proprietà di sistema con lo stesso nome del service provider.
  2. |
  3. Solo per XMLEventFactory, XMLInputFactory, |e XMLOutputFactory. Il valore del provider di servizi nel file C:\Program Files\IBM\Java60\jre\lib\stax.properties.
  4. |
  5. Per altre factory. Il valore del service provider nel file C:\Program Files\IBM\Java60\jre\lib\jaxp.properties.
  6. |
  7. I contenuti del file META-INF\services\<service.provider>
  8. |
  9. Il service provider predefinito.
|

I seguenti fornitori di servizi controllano le librerie per l'elaborazione XML utilizzate da Java: |

|
|
javax.xml.parsers.SAXParserFactory
|
Seleziona il parser SAX. Per impostazione predefinita, viene utilizzato org.apache.xerces.jaxp.SAXParserFactoryImpl dalla |libreria XML4J. |
|
javax.xml.parsers.DocumentBuilderFactory
|
Seleziona il document builder. Per impostazione predefinita, viene utilizzato org.apache.xerces.jaxp.DocumentBuilderFactoryImpl dalla |libreria XML4J. |
|
javax.xml.datatype.DatatypeFactory
|
Seleziona la factory di datatype. Per impostazione predefinita, viene utilizzato org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl dalla libreria XML4J. |
|
javax.xml.stream.XMLEventFactory
|
Seleziona la factory di eventi StAX. Per impostazione predefinita, viene utilizzato com.ibm.xml.xlxp.api.stax.XMLEventFactoryImpl dalla libreria XL XP-J. |
|
javax.xml.stream.XMLInputFactory
|
Seleziona il parser StAX. Per impostazione predefinita, viene utilizzato com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl dalla libreria XL XP-J. |
|
javax.xml.stream.XMLOutputFactory
|
Seleziona il serializzatore StAX. Per impostazione predefinita, viene utilizzato com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl dalla libreria XL XP-J. |
|
javax.xml.transform.TransformerFactory
|
Seleziona il processore XSLT. I valori possibili sono: | |
|
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
|
Utilizza il compilatore XL TXE-J. Questo l'impostazione predefinita. |
|
org.apache.xalan.processor.TransformerFactoryImpl
|
Utilizza l'interprete XSLT4J. |
|
|
|
javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema
|
Seleziona la factory di schema per il linguaggio di schema XML W3C. Per impostazione predefinita, viene utilizzato org.apache.xerces.jaxp.validation.XMLSchemaFactory dalla libreria XML4J. |
|
javax.xml.xpath.XPathFactory
|
Seleziona il processore XPath . Per impostazione predefinita, viene utilizzato org.apache.xpath.jaxp.XPathFactoryImpl dalla |libreria XSLT4J. |
|

| |

Migrazione a XL-TXE-J

|
|

Il compilatore XL TXE-J ha sostituito l'interprete XSLT4J come processore |XSLT predefinito. Seguire questi tre passi per preparare la propria applicazione alla nuova libreria.

|

|

Il compilatore XL TXE-J è più veloce dell'interprete XSLT4J quando si |applica la stessa trasformazione più volte. Se ogni singola trasformazione viene |eseguita solo una volta, il compilatore XL TXE-J risulta più lento dell'interprete |XSLT4J a causa del sovraccarico dovuto alla compilazione e ottimizzazione.

|

Per continuare a utilizzare l'interprete XSLT4J come processore XSLT, impostare |il provider di servizio javax.xml.transform.TransformerFactory |a org.apache.xalan.processor.TransformerFactoryImpl.

|

Per migrare al compilatore XL-TXE-J, seguire questi passi:

|
    |
  1. Utilizzare com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl quando si imposta il service provider javax.xml.transform.TransformerFactory.
  2. |
  3. Rigenerare i file delle classi generati con il compilatore the XSLT4J. XL TXE-J non può eseguire file di classe generati d al compilatore XSLT4J.
  4. |
  5. È possibile che alcuni metodi generati dal compilatore superino il limite di dimensione del metodo JVM, ed in tal caso il compilatore tenterà di suddividere tali metodi in metodi più piccoli. | |
      |
    • Se il compilatore riesce a suddividere i metodi, si riceverà la seguente avvertenza: "Alcune funzioni generate hanno superato il limite di dimensione del metodo JVM e sono state automaticamente suddivise in funzioni più piccole. È possibile raggiungere delle prestazioni migliori suddividendo manualmente dei modelli molto grandi in modelli più piccoli, utilizzando l'opzione 'splitlimit' nel comando Process oppure Compile, oppure impostando l'attributo di transformer factory 'http://www.ibm.com/xmlns/prod/xltxe-j/split-limit'.". È possibile usare le classi compilate,ma controllando la divisione manualmente si ottengono prestazioni migliori.
    • |
    • Se il compilatore non riesce a suddividere il metodo, si riceverà una delle seguenti eccezioni: "com.ibm.xtq.bcel.generic.ClassGenException: |Branch target offset too large for short" oppure "bytecode array size > 65535 |at offset=#####". Provare ad impostare il limite di suddivisione manualmente, oppure utilizzando un limite di suddivisione più piccolo.
    Per impostare il limite di suddivisione, utilizzare l'opzione -SPLITLIMIT quando si usano i comandi |Process o Compile, oppure l'attributo del transformer factory http://www.ibm.com/xmlns/prod/xltxe-j/split-limit quando si usa il transformer factory. Il limite di divisione deve essere compreso tra 100 e 2000. Quando si imposta il limite della divisione manualmente, utilizzare il limite di divisione più alto possibile per ottenere prestazioni migliori.
  6. |
  7. XL TXE-J può aver bisogno di più memoria del compilatore XSLT4J. Se si esaurisce la memoria o se le prestazioni sembrano insufficienti, aumentare le dimensioni dell'heap utilizzando l'opzione -Xmx.
  8. |
  9. Migrare l'applicazione per utilizzare le nuove chiavi degli attributi. Le vecchie chiavi degli attributi sono deprecate. I vecchi nomi saranno accettati con un messaggio di avviso. | | |||||||||||||||||||||||||||||||||||||||||||||||||||
    Tabella 1. Modifiche delle chiavi di attributo dal compilatore XSL4J al compilatore XL TXE-J
    Attributo del compilatore XSL4J Attributo del compilatore XL TXE-J
    translet-name http://www.ibm.com/xmlns/prod/xltxe-j/translet-name
    destination-directory http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory
    package-name http://www.ibm.com/xmlns/prod/xltxe-j/package-name
    jar-name http://www.ibm.com/xmlns/prod/xltxe-j/jar-name
    generate-translet http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet
    auto-translet http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet
    use-classpath http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath
    debug http://www.ibm.com/xmlns/prod/xltxe-j/debug
    indent-number http://www.ibm.com/xmlns/prod/xltxe-j/indent-number
    enable-inlining Obsoleta nel nuovo compilatore
  10. |
  11. Opzionale: Per avere massime prestazioni, assicurarsi di non ricompilare |le trasformazioni XSLT riusabili. Per riutilizzare le trasformazioni compilate, usare uno dei metodi |seguenti: | |
      |
    • Se il foglio di stile non cambia al runtime, compilarlo come parte |del processo di generazione e inserire le classi compilate nel proprio classpath. |Utilizzare il comando org.apache.xalan.xsltc.Compile per compilare |il foglio di stile e impostare l'attributo http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath del transformer factory |su true per caricare le classi dal |classpath.
    • |
    • Se l'applicazione utilizzerà lo stesso foglio di stile per più esecuzioni, |impostare l'attributo http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet del transformer factory |su true per salvare automaticamente il foglio di stile compilato |su disco e riutilizzarlo in futuro. Se è disponibile un foglio di stile compilato, il compilatore lo utilizzerà, |altrimenti, se il foglio di stile non è disponibile o è obsoleto, lo ricompilerà. |Per impostare la directory utilizzata per memorizzare i fogli di stile compilati, |utilizzare l'attributo http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory del transformer factory. |Per impostazione predefinita, i fogli di stile compilati sono memorizzati nella stessa directory del foglio di stile.
    • |
    • Se l'applicazione ha una lunga esecuzione nella quale lo stesso foglio di stile viene |utilizzato più di una volta, utilizzare il transformer factory per compilare il foglio di stile e |creare un oggetto Templates. È possibile utilizzare l'oggetto Templates |per creare oggetti Transformer senza ricompilare il foglio di stile. |Gli oggetti Transformer possono anche essere riutilizzati ma non sono |thread safe.
| |

Informazioni di riferimento XML

|
|

Le librerie XL XP-J e XL TXE-J XML sono nuove per la versione 6 dell'SDK. Tali informazioni di riferimento descrivono le funzionalità supportate da tali librerie.

| | |

Informazioni di riferimento XL XP-J

|
|

XL XP-J 1.1 è un parser ad alte prestazioni e non di convalida che fornisce |supporto a StAX 1.0 (JSR 173); un'API bidirezionale per il pull-parsing e la serializzazione del flusso dei documenti XML 1.0 e XML 1.1.

|

| |

Caratteristiche non supportate
|

Le caratteristiche StAX facoltative seguenti |non sono supportate da XL XP-J: |

|

|

| |

Riferimento XMLInputFactory
|

Le seguenti proprietà sono supportate |dall'implementazione javax.xml.stream.XMLInputFactory, |come descritto nel Javadoc XMLInputFactory.

| |||||||||||||||||||||||||||||||||||||||||||
Tabella 2.
Nome proprietà Supportate
javax.xml.stream.isValidating No. Lo scanner XL XP-J non supporta la convalida.
javax.xml.stream.isNamespaceAware Sì (supporta true e false). Per gli XMLStreamReader |creati da DOMSource, l'elaborazione dello spazio nomi dipende dai metodi che sono stati utilizzati per |creare l'albero DOM, e questo valore non ha alcun effetto.
javax.xml.stream.isCoalescing
javax.xml.stream.isReplacingEntityReferences Sì. Per gli XMLStreamReader creati |da DOMSource, se le entità sono state già sostituite nell'albero DOM, l'impostazione di questo parametro non ha alcun effetto.
javax.xml.stream.isSupportingExternalEntities
javax.xml.stream.supportDTD No. Le DTD sono sempre supportate. Impostare il valore a false non ha nessun effetto.
javax.xml.stream.reporter
javax.xml.stream.resolver
|

XL XP-J supporta anche il metodo facoltativo createXMLStreamReader(javax.xml.transform.Source), |che consente ai reader StAX di essere creati da origini DOM e SAX.

|

| |

Riferimento XMLStreamReader
|

Le seguenti proprietà |sono supportate dall'implementazione javax.xml.stream.XMLStreamReader, |come descritto nel JavadocXMLStreamReader.

| |||||||||||||||||||
Tabella 3.
Nome proprietà Supportate
javax.xml.stream.entities
javax.xml.stream.notations
|

XL XP-J supporta anche la proprietà javax.xml.stream.isInterning, che restituisce un Boolean indicante se il parser abbia effettuato l'interning degli URI dei nomi XML e dello spazio nomi |restituiti dalle chiamate API.

|

| |

Riferimento XMLOutputFactory
|

Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLOutputFactory, come descritto nel Javadoc XMLOutputFactory.

| |||||||||||||||
Tabella 4.
Nome proprietà Supportate
javax.xml.stream.isRepairingNamespaces
|

| |

Riferimento XMLStreamWriter
|

Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLStreamWriter, come descritto nel Javadoc XMLStreamWriter.

| |||||||||||||||
Tabella 5.
Nome proprietà Supportate
javax.xml.stream.isRepairingNamespaces
|

Le proprietà degli oggetti XMLStreamWriter sono di sola lettura.

| | |

Informazioni di riferimento XL TXE-J

|
|

XL TXE-J è una libreria XSLT contenente l'interprete XSLT4J 2.7.8 e un compilatore XSLT.

|

| |

Tabella di confronto delle funzioni

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tabella 6. Confronto tra le caratteristiche dell'interprete XSLT4J, del compilatore XSLT4J, e del compilatore XL TXE-J.
Funzione Interprete XSLT4J (incluso) Compilatore XSLT4J (non incluso) Compilatore XL TXE-J (incluso)
caratteristica http://javax.xml.transform.stream.StreamSource/feature
caratteristica http://javax.xml.transform.stream.StreamResult/feature
caratteristica http://javax.xml.transform.dom.DOMSource/feature
caratteristica http://javax.xml.transform.dom.DOMResult/feature
caratteristica http://javax.xml.transform.sax.SAXSource/feature
caratteristica http://javax.xml.transform.sax.SAXResult/feature
caratteristica http://javax.xml.transform.stax.StAXSource/feature No
caratteristica http://javax.xml.transform.stax.StAXResult/feature No
caratteristica http://javax.xml.transform.sax.SAXTransformerFactory/feature
caratteristica http://javax.xml.transform.sax.SAXTransformerFactory/feature/xmlfilter
caratteristica http://javax.xml.XMLConstants/feature/secure-processing
attributo http://xml.apache.org/xalan/features/incremental No No
attributo http://xml.apache.org/xalan/features/optimize No No
attributo http://xml.apache.org/xalan/properties/source-location No No
attriburo translet-name N/D Sì (con nome differente)
attributo destination-directory N/D Sì (con nome differente)
attributo package-name N/D Sì (con nome differente)
attributo jar-name N/D Sì (con nome differente)
attributo generate-translet N/D Sì (con nome differente)
attributo auto-translet N/D Sì (con nome differente)
attributo use-classpath N/D Sì (con nome differente)
attributo enable-inlining No No (obsoleto in TL TXE-J)
attributo indent-number No Sì (con nome differente)
attributo debug No Sì (con nome differente)
estensioni Java Sì (solo sintassi abbreviata, costrutti xalan:component/xalan:script |non supportati)
estensioni JavaScript No No
elementi Extension No No
funzioni extension EXSLT Sì (escluse quelle dinamiche) Sì (escluse quelle dinamiche)
estensioni redirect Sì (escluse redirect:open e redirect:close)
estensioni output No
estensioni nodeset
funzioni di estensione NodeInfo No No
estensioni libreria SQL No No
estensioni pipeDocument No No
estensioni evaluate No No
estensioni tokenize No No
XML 1.1
|

| |

Note
|

Con il comando Process, utilizzare -FLAVOR |sr2sw per trasformare mediante elaborazione del flusso StAX, e -FLAVOR |er2ew per l'elaborazione di eventi StAX.

|

Il nuovo compilatore non cerca |il service provider org.apache.xalan.xsltc.dom.XSLTCDTMManager. Invece, utilizzando StreamSource il compilatore |utilizza un parser XML ad alte prestazioni.

|

L'inlining è obsoleto in XL |TXE-J. |

| |

La classe org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl non è più supportata.

| |

Utilizzo di una versione precedente di Xerces o Xalan

|
|

Se si sta usando una versione più vecchia di Xerces (antecedente alla 2.0) o Xalan (antecedente alla 2.3) durante un processo di sovrascrittura approvata, è possibile ricevere un'eccezione NullPointerException 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: |

|

Esecuzione del debug di applicazioni Java

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) (JPDA) fornito da SDK per Windows.

Ulteriori informazioni sulla diagnostica dei problemi relativi all'utilizzo di Java sono reperibili nel Manuale per la diagnostica.

Java Debugger (JDB)

JDB (Java Debugger) è incluso nel SDK perWindows. Il programma di debug è richiamato dal comando jdb; questo si "collega" alla JVM tramite JPDA.

Per eseguire il debug di un'applicazione Java:

  1. Avviare una JVM con le seguenti opzioni:
    java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<porta> <classe>
    La JVM si avvia ma sospende l'esecuzione prima di avviare l'applicazione Java.
  2. In una sessione separata, è possibile collegare il programma di debug alla JVM:
    jdb -attach <porta>
    Il programma di debug si collega alla 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:

  1. Immettere jdb
  2. Alla richiesta comandi jdb, immettere help

È inoltre possibile usare JDB per eseguire il debug delle applicazioni Java in esecuzione su macchine remote. JPDA utilizza un socket TCP/IP per connettersi alla JVM remota.

  1. Avviare una JVM con le seguenti opzioni:
    java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<porta> <classe>
    La JVM si avvia ma sospende l'esecuzione prima di avviare l'applicazione Java.
  2. Collegare il programma di debug alla JVM remota:
    jdb -connect com.sun.jdi.SocketAttach:hostname=<host>,port=<porta>

JVMDI (Java Virtual Machine Debugging Interface) non è supportato in questo rilascio. È stata sostituito da JVMTI (Java Virtual Machine Tool Interface).

Per ulteriori informazioni su JDB e JPDA e sul loro uso, consultare questi siti web:

Individuazione in un'applicazione di una JVM a 32 bit o 64 bit

Alcune applicazioni Java devono essere in grado di determinare se stanno eseguendo una JVM a 32 bit 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 la JVM di cui si dispone. Vengono restituiti i seguenti valori:

È possibile esaminare la proprietà com.ibm.vm.bitmode dal codice dell'applicazione utilizzando la chiamata:

System.getProperty("com.ibm.vm.bitmode");

Modalità di elaborazione di JVM dei segnali

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 thread non-Java.

Se il segnale è per un thread Java, la 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, viene richiamato il gestore applicazioni per questo segnale quando JVM ha terminato l'elaborazione.

Se il segnale S per un thread non-Java, e l'applicazione che installava la JVM aveva precedentemente installato il proprio gestore segnali, il controllo viene passato a tale gestore. In caso contrario, se il segnale viene richiesto dalla JVM o dall'applicazione Java, il segnale viene ignorato oppure viene eseguita l'azione predefinita.

Quando un segnale viene 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 informazioni su come scrivere un programma di avvio che specifica gli hook sopra indicati, consultare: http://www.ibm.com/developerworks/java/library/i-signalhandling/. Questo elemento è stato scritto perJava V1.3.1, ma è valido anche per le versioni successive.

Per segnali di interruzione, JVM immette inoltre una sequenza di chiusura controllata, ma questa volta viene trattata come una normale chiusura che:

  1. Chiama il gestore segnali dell'applicazione per quel segnale.
  2. Esegue tutti gli hook di chiusura delle applicazioni.
  3. Chiama eventuali hook di uscita di applicazioni installate.
  4. Esegue le necessarie pulizie JVM.

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.

Segnali utilizzati da JVM

I tipi di segnale sono Interruzioni, e Controlli.

Tabella 7 di seguito vengono illustrati i segnali utilizzati da JVM. I segnali sono raggruppati in una tabella per tipo o uso, nel seguente modo:

Eccezioni
Il sistema operativo emette in modo sincrono un appropriato segnale di eccezione ogni volta che si verifica una condizione irreversibile.
Errori
Una JVM emette un SIGABRT se rileva una condizione per la quale non può effettuare il recupero.
Interruzioni
Per richiedere una chiusura, i segnali di interruzione vengono emessi in modo asincrono al di fuori del processo JVM.
Controlli
Altri segnali di controllo utilizzati da JVM.

Tabella 7. Segnali utilizzati da JVM
Nome segnale Tipo segnale Descrizione Disabilitato da -Xrs
SIGINT (2) Interrotto Attenzione interattiva (CTRL-C). JVM esce normalmente.
SIGTERM (15) Interrotto Richiesta termine. JVM uscirà normalmente.
SIGBREAK Controllo Segnale di interruzione per un terminale. Per impostazione predefinita, ciò innesca un Javadump.

IBM JVM utilizza le API AddVectoredExceptionHandler() e the SetConsoleCtrlHandler()s. Queste vengono disabilitate con -Xrs. -Xnosigchain viene ignorato su Windows.

Utilizzare l'opzione -Xrs (riduce uso segnale) per evitare che JVM gestisca la maggior parte dei segnali. Per ulteriori informazioni, consultare la pagina d'avvio dell'applicazione Sun Java..

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 a meno che non possa fare a meno della JVM.

Collegamento di un driver di codice nativo alla libreria concatenazione di segnali

Runtime Environment contiene il concatenamento dei segnali. Questa funzione consente alle JVM di operare in modo più efficiente con il codice 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 dietro 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.

La libreria libjsig.dll nasconde anche i gestori di segnale della JVM all'applicazione. Per questo motivo, chiamate come signal(), sigset() e sigaction() eseguite dopo l'avvio della JVM non restituiscono un riferimento al gestore di segnale della JVM, ma restituiscono i gestori installati prima dell'avvio della JVM.

È necessario impostare la variabile d'ambiente JAVA_HOME alla posizione dell'SDK, ad esempio,C:\Program Files\IBM\Java60\.

Per utilizzare jsig.dll, eseguire il collegamento all'applicazione che crea oppure inserisce una JVM.

Scrittura di applicazioni JNI

Numeri di versione JNI validi che i programmi nativi possono specificare sulla chiamata JNI_CreateJavaVM() API sono: JNI_VERSION_1_2(0x00010002) e JNI_VERSION_1_4(0x00010004).

Limitazione: La versione 1.1 di JNI (Java Native Interface) non è supportata.

Questo numero di versione determina solo il livello dell'interfaccia nativa JNI da utilizzare. Il livello attuale della JVM creata viene specificato dalle librerie JSE (cioè, v6). L'API interfaccia JNI non influisce sulla specifica della lingua implementata da JVM, sulle API delle librerie delle classi oppure su qualsiasi altra area di azione di JVM. Per ulteriori informazioni, consultare http://java.sun.com/javase/6/docs/technotes/guides/jni/.

Se all'applicazione sono necessarie due librerie JNI, una creata per il 32- e l'altra per il 64-bit, utilizzare la proprietà di sistema com.ibm.vm.bitmode per determinare se si è in esecuzione una JVM a 32- o a 64-bit e scegliere la libreria appropriata.

Configurazione dell'allocazione di memoria di pagine grandi

È 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 derivano principalmente dal numero ridotto di mancati riscontri nel TLB (Translation Lookaside Buffer). TLB mappa un intervallo più ampio di memoria virtuale e questo porta a un miglioramento.

Affinché la 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".

Supporto CORBA

JSE (Java Platform, Standard Edition) supporta, come minimo, le specifiche definite nel documento di conformità di Sun. In alcuni casi, IBM JSE ORB supporta versioni più recenti delle specifiche.

Le specifiche minime supportate sono definite in Official Specifications for CORBA support in Java SE 6.

Supporto per GIOP 1.2

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.

http://www.omg.org/cgi-bin/doc?formal/99-10-07

GIOP bidirezionale non è supportato.

Supporto per Portable Interceptors

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 hooks posti in ORB che i servizi ORB possono utilizzare per intercettare il normale flusso di esecuzione di ORB.

Supporto per Interoperable Naming Service

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, è cambiata 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 specification, e l'operazione ORB::string_to_object ora supporta i formati di stringa ObjectURL (corbaloc: ecorbaname:) 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 allaVersione 6. 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 è un oggetto CORBA, connesso a ORB. Questo meccanismo è temporaneo e non è compatibile con le versioni di ORB future o portabili su sistemi non-IBM.

Proprietà di sistema per tracciare l'ORB

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.

Proprietà della traccia

com.ibm.CORBA.Debug=true
Attiva la traccia ORB.
com.ibm.CORBA.CommTrace=true
Aggiunge messaggi GIOP (inviati e ricevuti) alla traccia.
com.ibm.CORBA.Debug.Output=<file>
Specifica il file di output. Per impostazione predefinita, il file è specificato nella forma orbtrc.DDMMYYYY.HHmm.SS.txt.

Esempi di traccia ORB

Ad esempio, per tracciare gli eventi e i messaggi formattati GIOP dalla riga comandi, immettere:

java -Dcom.ibm.CORBA.Debug=true
     -Dcom.ibm.CORBA.CommTrace=true <myapp>

Limitazioni

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 riportare 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( ORB.shutdown().

Il contenuto e il formato dell'output di traccia potrebbero variare da versione a versione.

Proprietà di sistema per ottimizzare ORB

ORB deve essere ottimizzato per operare adeguatamente nella rete specifica utilizzata. Le proprietà necessarie per ottimizzare ORB sono descritte qui.

com.ibm.CORBA.FragmentSize=<dimensioni in byte>
Utilizzato per controllare la frammentazione di GIOP 1.2. La dimensione predefinita e di 1024 byte.

Per disabilitare la frammentazione, impostare la dimensione del frammento a 0 byte:

java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
com.ibm.CORBA.RequestTimeout=<tempo in secondi>
Imposta il tempo massimo di attesa per una Request CORBA. Per impostazione predefinita ORB attende per un tempo indefinito. Non impostare il timeout su un valore troppo basso, altrimenti le connessioni potrebbero terminare inutilmente.
com.ibm.CORBA.LocateRequestTimeout=<tempo in secondi>
Imposta a tempo massima di attesa per una LocateRequest CORBA. Per impostazione predefinita ORB attende per un tempo indefinito.
com.ibm.CORBA.ListenerPort=<numero porta>
Imposta la porta da cui ORB legge le richieste in entrata. Se viene impostata questa proprietà, ORB si mette in ascolto appena viene inizializzato. Altrimenti, si mette in ascolto solo quando viene richiesto.

Autorizzazioni Java Security per ORB

Quando si utilizza Java SecurityManager, è possibile che il richiamo di alcuni metodi nelle classi API di CORBA causi l'effettuazione di controlli sulle autorizzazioni, che potrebbero comportare un'eccezione SecurityException. Se i programmi di cui si dispone usano alcuni di questi metodi, assicurarsi che siano garantite le autorizzazioni necessarie.

Tabella 8. Metodi interessati durante l'utilizzo di Java SecurityManager
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 (String, boolean) java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl _get_interface_def java.net.SocketPermission connect
org.omg.CORBA. Request invoke java.net.SocketPermission connect
org.omg.CORBA. Request send_deferred java.net.SocketPermission connect
org.omg.CORBA. Request send_oneway java.net.SocketPermission connect
javax.rmi. PortableRemoteObject narrow java.net.SocketPermission connect

Classi di implementazione ORB

Un elenco delle classi di implementazione ORB.

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 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 su IIOP

RMI (Remote Method Invocation) Java fornisce un semplice meccanismo per la programmazione distribuita Java . RMI su IIOP (RMI-IIOP) utilizza il protocollo IIOP (Internet Inter-ORB Protocol) standard dell'architettura 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:

Implementazione di Connection Handler Pool per RMI

Per impostazione predefinita, il pooling dei thread per i gestori di connessioni RMI non è abilitato.

Per abilitare il pool delle connessioni implementato a livello RMI TCPTransport, impostare l'opzione

-Dsun.rmi.transport.tcp.connectionPool=true

Questa versione di Runtime Environment non ha un'impostazione utilizzabile per limitare il numero di thread nel pool delle connessioni.

BigDecimal migliorato

Da Java 5.0, la classeIBM BigDecimal è stata adottata da Sun come java.math.BigDecimal. La classe com.ibm.math.BigDecimal è riservata da IBM per possibili usi futuri ed è attualmente deprecata. Migrare il codice Java esistente in modo che utilizzijava.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. Le due classi non utilizzano il meccanismo di serializzazione.

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.*; a import java.math.*;.

Applet Viewer

Java Plug-in viene utilizzato per eseguire le applicazioni Java all'interno del browser. L'appletviewer viene utilizzato per provare le applicazioni progettate per essere eseguite in un browser. Java Web Start è utilizzato per distribuire applicazioni desktop Java su una rete, e fornisce un meccanismo per mantenerle aggiornate.

Operazioni con gli applet

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.

Esecuzione delle applet con Applet Viewer

Utilizzare il seguente comando per eseguire un applet con Applet Viewer.

Da una richiesta comandi, immettere:

   appletviewer <name>

dove <name> è uno dei seguenti:

Ad esempio, per richiamare un'Applet Viewer su un file HTML che richiama un'applet, immettere in un richiesta comandi:

appletviewer <demo>\GraphLayout\example1.html

Dove a <demo> va sostituito il percorso completo in cui è stato spacchettato il pacchetto della demo.

Per richiamare Applet Viewer su una pagina web, digitare da una richiesta 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 Applet Viewer 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

Esecuzione del debug delle applet con Applet Viewer

Si può eseguire il debug delle applet usando l'opzione -debug di Applet Viewer.

Ad esempio:

cd demo\applets\TicTacToe
..\..\..\bin\appletviewer -debug example1.html

La documentazione sulle modalità di debug degli applet mediante l'utilizzo di Applet Viewer si trova nel sito web della Sun: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.

Invio di un'applicazione Java

Le applicazioni Java tipicamente consistono di classi, risorse, e file di dati.

Quando si invia un'applicazione Java, il pacchetto software è generalmente 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.

Condivisione di dati di classe tra le JVM

La condivisione di dati delle classi consente a differenti JVM di condividere un singolo spazio in memoria.

La JVM (Java Virtual Machine) consente di condividere dati di classe tra JVM memorizzandoli in un file di cache memory-mapped su disco. La condivisione riduce il consumo totale della memoria virtuale quando più JVM condividono una cache. La condivisione riduce inoltre il tempo di avvio per una JVM dopo la creazione della cache. La cache delle classi condivise è indipendente da ogni JVM attiva e persiste fino alla sua distruzione.

Una cache condivisa può contenere:

Panoramica sulla condivisione dei dati di classe

La condivisione dei dati di classe fornisce un metodo trasparente per ridurre il footprint di memoria e per migliorare il tempo di avviamento della JVM. |Java 6 |fornisce caratteristiche nuove e migliorate nella gestione della cache, nell'isolamento, e nelle prestazioni.

Abilitazione della condivisione dei dati di classe

Abilita la condivisione dei dati di classe utilizzando l'opzione-Xshareclasses all'avvio di una JVM. La JVM si collegherà ad una cache esistente oppure creerà una nuova cache se non ce ne sono.

Tutte le classi di bootstrap e delle applicazioni caricate dalla JVM vengono condivise per impostazione predefinita. I classloader personalizzati effettuano automaticamente la condivisione delle classi se estendono il classloader dell'applicazione; altrimenti, per accedere alla cache devono usare l'API Java Helper fornita con la JVM. (Consultare Adattamento dei classloader personalizzati per la condivisione di classi.)

|La JVM può anche memorizzare del codice compilato AOT (Ahead-Of-Time) nella cache per alcuni metodi, in modo da migliorare il tempo di avvio di JVM successive. Il codice compilato AOT non è al momento condiviso tra le JVM, ma viene memorizzato nella cache |al fine di ridurre il tempo di compilazione quando la JVM viene avviata. La quantità di codice AOT memorizzato nella cache viene determinato in maniera euristica. Non è possibile controllare quali metodi vengono memorizzati nella cache, ma è possibile impostare dei limiti superiori ed inferiori relativamente alla quantità di spazio in cache da destinare al codice AOT, oppure è possibile scegliere di disabilitare completamente la memorizzazione su cache di codice AOT. |Consultare Abilitazione e configurazione della condivisione dei dati delle classi per ulteriori informazioni.

Accesso alla cache

|Una JVM |può accedere alla cache sia in sola lettura che in lettura-scrittura. Ogni JVM connessa alla cache con accesso lettura-scrittura può aggiornare la cache. La cache può essere letta contemporaneamente da qualsiasi numero di JVM, anche se un'altra JVM ci sta scrivendo dentro.

Prestare molta attenzione se viene utilizzata la modifica del bytecode di avvio. Consultare Modifiche bytecode al runtime per ulteriori informazioni.

Aggiornamento dinamico della cache

Poiché la cache delle classi condivise persiste oltre la durata di qualsiasi JVM, 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.

Sicurezza della cache

L'accesso alla cache delle classi condivise è limitato dalle autorizzazioni del sistema operativo e delle autorizzazioni di sicurezza Java. Solo un classloader registrato per la condivisione dei dati delle classi può aggiornare la cache delle classi condivise.

|La memoria della cache è protetta contro |la corruzione accidentale o deliberata mediante la protezione di pagina di memoria. Questo non implica garanzia assoluta contro la corruzione perché per scrivere sulle pagine la JVM deve rimuoverne la protezione. L'unica maniera di garantire che una cache non possa essere modificata è quella di aprirla in modalità di sola lettura.

Se è stato installato un Java SecurityManager, è necessario che i classloader (esclusi quelli di estensione, applicazione e bootstrap predefiniti) siano autorizzati a condividere le classi aggiungendo le righe SharedClassPermission al file java.policy. (Consultare Utilizzo di SharedClassPermission.) RuntimePermission "createClassLoader" limita la creazione di nuovi classloader e di conseguenza anche l'accesso alla cache.

Intervallo di tempo valido della cache

Su un sistema possono esistere più cache e sono specificate per nome come un'opzione secondaria del comando -Xshareclasses. Una JVM può collegarsi ad una cache alla volta.

È possibile sovrascrivere la dimensione predefinita della cache all'avvio mediante -Xscmx<n><size>, ma questa dimensione rimane poi fissata per la durata della cache. Le cache esistono finché non vengono distrutte esplicitamente mediante l'opzione secondaria del comando -Xshareclasses, oppure o il file di cache non viene eliminato manualmente.

Programmi di utilità della cache

Tutti i programmi di utilità della cache sono opzioni secondarie del comando -Xshareclasses. Consultare Abilitazione e configurazione della condivisione dei dati delle classi, o utilizzare -Xshareclasses:help per un elenco delle opzioni secondarie disponibili.

Abilitazione e configurazione della condivisione dei dati delle classi

La condivisione dei dati delle classi e le utilità di gestione della cache vengono controllate mediante opzioni da riga comandi al programma di avvio java.

Per le opzioni che assumono il parametro <size>, aggiungere al numero un suffisso "k" o "K" per indicare i kilobyte, "m" o "M" per indicare i megabyte, oppure "g" o "G" per indicare i gigabyte.

-Xscmaxaot<dimensione>
Imposta il numero massimo di byte nella cache utilizzabili per i dati AOT. Utilizzare questa opzione per assicurarsi che una certa quantità di cache resti disponibile per i dati non AOT. Per impostazione predefinita, il limite massimo per i dati AOT corrisponde allo spazio disponibile della cache. Il valore di questa opzione non dovrebbe essere più piccolo del valore di -Xscminaot e più grande del valore di -Xscmx.
-Xscminaot<dimensione>
Imposta il numero minimo di byte della cache da riservare ai dati AOT. Per impostazione predefinita, non viene riservato alcuno spazio per i dati AOT, anche se i dati AOT vengono scritti sulla cache fino a riempirla o fino al raggiungimento del limite -Xscmaxaot. Il valore di questa opzione non dovrebbe essere più grande del valore di -Xscmx o -Xscmaxaot. Valore di -Xscminaot dovrebbe sempre essere significativamente più piccolo del totale della dimensione della cache e poiché i dati AOT possono essere creati solo per classi interne alla cache. Se il valore di -Xscminaot è uguale al valore di -Xscmx, non vengono memorizzati né i dati della classe, né i dati AOT; questo perché è necessario che i dati AOT siano associati con una classe nella cache.
-Xscmx<dimensione>
Specifica la dimensione della cache. Questa opzione si applica solo se viene creata una cache e non esiste un'altra cache con lo stesso nome. La dimensione predefinita della cache dipende dalla piattaforma. È possibile scoprire il valore della dimensione utilizzato aggiungendo -verbose:sizes come argomento di riga comandi. La dimensione minima della cache è 4 KB. Inoltre, la dimensione massima della cache dipende dalla piattaforma. (Consultare Limiti di dimensioni della cache.)
-Xshareclasses:<opzione secondaria>[,<opzione secondaria>...]
Abilita la condivisione dei dati di classe. Può avere una serie di opzioni secondarie, alcune delle quali sono programmi di utilità della cache. I programmi di utilità della cache effettuano l'operazione richiesta sulla cache specificata ma senza l'avvio del VM. È possibile combinare più opzioni secondarie, separate da virgole, ma i programmi di utilità della cache si escludono a vicenda. Durante l' esecuzione di programmi di utilità della cache, è previsto il messaggio "Could not create the Java virtual machine". I programmi di utilità della cache non generano un virtual machine.

Alcune utilità di cache possono funzionare con le cache provenienti da precedenti versioni Java o da cache create dalle JVM con differenti larghezze di bit. Ci si riferisce a tali cache come cache "incompatibili".

È possibile utilizzare le seguenti opzioni secondarie con l'opzione -Xshareclasses :

help
Elenca tutte le opzioni secondarie da riga comandi.
name=<nome>
Collega una cache di un nome specificato, creando una cache se non esiste già. È utilizzato anche per indicare la cache che verrà modificata dei programmi di utilità e la cache, ad esempio, destroy. Utilizzare l'utilità listAllCaches per visualizzare quali cache con nome sono attualmente disponibili. Se non si specifica un nome, verrà utilizzato il nome predefinito "sharedcc_%u". %u nel nome della cache inserirà in nome dell'utente corrente.
|cacheDir=<directory>
|Imposta la directory nella quale verranno letti e scritti i dati di cache. Per impostazione predefinita <directory> è la C:\Documents and Settings\<username>\Local |Settings\Application Data\javasharedresources directory. È necessario che l'utente disponga di autorizzazioni sufficienti all'interno di <directory>. Per impostazione predefinita, la JVM scrive i file di cache persistente direttamente nella directory specificata. È possibile spostare ed eliminare i file di cache persistente dal filesystem con sicurezza. Cache non-persistenti Le sono memorizzate nella memoria condivisa e dispongono di file di controllo che descrivono la locazione della memoria. I file di controllo sono memorizzati in una sottodirectory javasharedresources della cacheDir specificata. |I file di controllo in questa directory non dovrebbero essere spostati o eliminati manualmente. L'utilità listAllCaches, |l'utilità destroyAll e l'opzione secondaria expire funzionano solo all'interno dell'ambito di una data cacheDir.
|readonly
|Apre una cache esistente con autorizzazioni di sola lettura. La JVM non creerà una nuova cache con questa opzione secondaria. L'apertura di una cache di sola lettura impedisce alla JVM di effettuare l'aggiornamento della cache stessa. Consente anche alla JVM di connettersi alle |cache create da altri utenti o gruppi senza richiedere accesso in scrittura. Per impostazione predefinita, questa opzione secondaria non è specificata.
|nonpersistent
|Utilizza una cache non persistente. Per impostazione predefinita, la JVM crea un file di cache |su disco, che persiste dopo il riavvio del sistema operativo. L'opzione secondaria nonpersistent causa l'eliminazione del file di cache quando il sistema operativo viene spento. Le cache persistenti e non persistenti possono avere lo stesso nome, ed è necessario che l'opzione secondaria nonpersistent |sia sempre utilizzata quando si eseguono utilità come la destroy su una cache non persistente. Per impostazione predefinita, questa opzione secondaria non è specificata.
verbose
Abilita l'output verboso, che fornisce lo stato generale sulla cache di classe condivisa e messaggi di errore con maggior dettaglio.
|verboseAOT
|Attiva l'output dettagliato quando del codice AOT viene trovato o memorizzato |nella cache. Il codice AOT Viene generato in maniera euristica. Per piccole applicazioni, è possibile |che non venga generato codice AOT. È possibile disabilitare le operazioni di cache AOT mediante l'opzione secondaria noaot.
verboseIO
Fornisce un output dettagliato sulle attività di I/O della cache, elencando informazioni sulle classi memorizzate e trovate. A ciascun classloader viene assegnato un ID univoco (il programma di caricamento di avvio è sempre 0) e l'output visualizza la gerarchia dei classloader attivi, dove i classloader devono chiedere ai parent una classe prima di poterla caricare. È normale che vi siano molte richieste non riuscite; questo comportamento è previsto per la gerarchia dei classloader.
verboseHelper
Abilità l'output dettagliato per le API Java Helper Questo output mostra come ClassLoader utilizzi l'API Helper.
silent
Disattiva tutti i messaggi delle classi condivise, compresi i messaggi di errore.
nonfatal
Consente l'avvio del JVM anche se la condivisione dei dati di classe ha esito negativo. Il normale comportamento per la JVM è quello di rifiutare l'avvio se la condivisione dei dati di classe non riesce. Se viene selezionato nonfatal e la cache delle classi condivise non viene inizializzata, la JVM tenterà di connettersi alla cache in modalità di sola lettura. Se ciò non riesce, la JVM si avvia senza la condivisione dei dati di classe.
none
È possibile aggiungerla alla fine della riga comandi per disabilitare la condivisione dei dati di classe. Questa opzione secondaria sostituisce gli argomenti di condivisione di classe trovati finora sulla riga comandi.
modified=<contesto modificato>
Utilizzata quando è installato un agente JVMTI che potrebbe modificare il bytecode durante l'esecuzione. Se non si specifica questa opzione e viene installato un agente di modifica bytecode, le classi saranno condivise in modo sicuro con un costo aggiuntivo nelle prestazioni. <contesto modificato> è un descrittore scelto dall'utente, ad esempio "myModification1". Tale opzione partiziona la cache, in modo che solo le JVM che utilizzano il contesto myModification1 possono condividere le stesse classi. Ad esempio, se si esegue HelloWorld con un contesto di modifica e di seguito lo si esegue ancora con un contesto di modifica differente, si vedrà che tutte le classi sono state memorizzate due volte nella cache. Consultare Modifiche bytecode al runtime per ulteriori informazioni.
|reset
|Determina la distruzione della cache e una nuova creazione all'avvio della JVM. È possibile aggiungerla alla fine della riga comandi come -Xshareclasses:reset.
destroy (opzione di utilità)
Distrugge una cache specificata dalle opzioni secondarie name, cacheDir, e nonpersistent. È possibile distruggere una cache solo se sono spente tutte le JVM che la utilizzano, e se l'utente dispone di autorizzazioni sufficienti.
destroyAll (opzione di utilità)
Cerca di distruggere tutte le cache disponibili mediante le opzioni secondarie cacheDir e nonpersistent specificate. È possibile distruggere una cache solo se sono spente tutte le JVM che la utilizzano, e se l'utente dispone di autorizzazioni sufficienti.
expire=<tempo in minuti>
Distrugge tutte le cache che non sono state utilizzate nel periodo di tempo specificato prima che vengano caricate le classi condivise. Non si tratta di una opzione di utilità in quanto non causa l'uscita della JVM. Su file system NTFS, l'opzione expire è accurata fino all'ora più vicina.
listAllCaches (opzione di utilità)
Elenca tutte le cache compatibili ed incompatibili presenti nella directory di cache specificata. Se non viene specificata la cacheDir, viene utilizzata la directory predefinita. Le informazioni di riepilogo, come la versione Java e l'utilizzo attuale, vengono visualizzate per ogni cache.
printStats (opzione di utilità)
Visualizza le informazioni di riepilogo per la cache specificata dalle opzioni secondarie name, cacheDir, e nonpersistent. Le informazioni più utili visualizzate sono relative a quanto è piena la cache e a quante classi contiene. Le classi "stale" sono classi aggiornate sul sistema di file e che la cache ha quindi contrassegnato come "stale". Le classi stale non vengono eliminate dalla cache e possono essere riutilizzate. Consultare il Manuale per la diagnostica per ulteriori informazioni.
printAllStats (opzioni di utilità)

Visualizza le informazioni dettagliate per la cache specificata dalle opzioni secondarie name, cacheDir, e nonpersistent. Ogni classe viene elencata in ordine cronologico con un riferimento alla posizione dalla quale è stata caricata. Viene anche elencato il codice AOT per i metodi di classe.

Consultare il Manuale per la diagnostica per maggiori informazioni.

|mprotect=[ all || default | none ]
|Per impostazione predefinita, le pagine di memoria contenenti la cache sono protette in ogni momento, a meno che una pagina specifica non sia in corso di aggiornamento. Ciò aiuta a proteggere la cache da corruzione accidentale o deliberata. Per impostazione predefinita, l'intestazione della cache non è protetta perché ciò comporta una piccola riduzione delle prestazioni. Specificando "all" si garantisce che tutte le pagine della |cache siano protette, inclusa l'intestazione. Specificando "none" la protezione delle pagine viene disabilitata.
|noBootclasspath
|Impedisce la memorizzazione delle classi caricate dal classloader di bootstrap nella cache delle classi condivise. È possibile usarla con l'API SharedClassURLFilter in modo da controllare esattamente quali classi vengono memorizzate nella cache. Consultare il Manuale per la diagnostica per ulteriori informazioni sul filtraggio delle classi condivise.
|cacheRetransformed
|Abilita la memorizzazione e la cache delle classi che sono state trasformate con la funzione JVMTI RetransformClasses.
|noaot
|Disabilita la memorizzazione su cache ed il caricamento del codice AOT.

Creazione, popolamento ed eliminazione di una cache

Una panoramica sul lifecycle di una cache di dati di classi condivise, che include degli esempi di utilità di gestione della cache.

Per abilitare la condivisione dei dati di classe, aggiungere -Xshareclasses[:name=<name>] alla riga comandi dell'applicazione.

La JVM 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ù JVM, 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=<name>],printStats. (Tali programmi di utilità possono essere eseguiti dopo che il JVM dell'applicazione è stato terminato, oppure in un'altra finestra comandi.)

Per ottenere più feedback sull'utilizzo della cache durante l'esecuzione di un JVM, utilizzare l'opzione secondaria verbose. Ad esempio, java -Xshareclasses:[name=<name>],verbose.

Per visualizzare le classi caricate dalla cache oppure memorizzate nella cache, aggiungere -Xshareclasses:[name=<name>],verboseIO alla riga comandi dell'applicazione.

Per eliminare la cache creata, eseguire java -Xshareclasses:[name=<name>],destroy. 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 JVM, è consigliabile eseguire questa analisi una volta terminata l'applicazione. Tuttavia, una cache completa non ha un impatto negativo sulle prestazioni o sulle funzionalità dei JVM ad essa collegati, 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 ogni JVM che utilizza l'opzione secondaria verbose. Tutti i JVM che condividono la cache piena caricheranno quindi tutte le classi successive nella memoria del loro processo. Le classi in una cache piena possono essere condivise, ma una cache piena è di sola lettura e non può essere aggiornata con nuove classi.

Prestazioni e consumo della memoria

La condivisione di dati di classe è particolarmente utile su sistemi che utilizzano più JVM con un codice simile; il sistema trae vantaggio dal consumo ridotto di memoria virtuale. Inoltre, è utile su sistemi che avviano e chiudono JVM 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 JVM è generalmente tra lo 0 e il 5% maggiore rispetto a una macchina che non usa la condivisione dei dati di classe, a seconda di quante classi vengono caricate. Il tempo di avvio della JVM con una cache popolata è di solito tra il 10% e il 40% minore rispetto a un sistema che non uso la condivisione di dati di classe, a seconda del sistema operativo e del numero di classi caricate. Più JVM in esecuzione contemporaneamente mostrano maggiori vantaggi del tempo di avvio generale.

Le classi duplicate sono consolidate all'interno della cache delle classi condivise. Per esempio, una classe A caricata da myClasses.jar e una classe A caricata da myOtherClasses.jar (con contenuto identico) viene memorizzata una sola volta nella cache. Il programma di utilità printAllStats mostra più voci per le classi duplicate, e ciascuna di esse punta alla stessa classe.

Quando si esegue l'applicazione con la condivisione dei dati di classe, è possibile utilizzare gli strumenti del sistema operativo per visualizzare la riduzione del consumo della memoria virtuale.

Considerazioni e restrizioni sull'utilizzo della condivisione dei dati delle classi

Fattori da considerare quando si distribuisce la condivisione dei dati delle classi in un prodotto, e quando si utilizza la condivisione dei dati delle classi in un ambiente di sviluppo.

Limiti di dimensioni della cache

La cache massima teorica è 2 GB. La dimensione della cache che è possibile specificare è limitata dalla quantità di spazio su disco disponibile e dallo spazio degli indirizzi virtuali disponibile.

La cache è limitata dai seguenti fattori:

Modifiche bytecode al runtime

Ogni JVM che utilizza un agente JVMTII (JVM Tool Interface) che possa modificare i dati di bytecode dovrebbe usare l'opzione secondaria modificata=<modified_context> se questa JVM desidera condividere le classi modificate con un'altra JVM.

Il contesto modificato è un descrittore specificato dall'utente che descrive il tipo di modifica da effettuare. Il contenuto modificato partiziona la cache per consentire a tutte le JVM eseguiti nello stesso contesto di condividere una partizione.

Questo perfezionamento consente alle JVM Che non utilizzano il bytecode modificato di condividere in sicurezza una cache con quelle che utilizzano un bytecode modificato. Tutte le JVM che utilizzano un dato contesto modificato devono modificare il bytecode in maniera ripetibile e prevedibile per ogni classe, in modo che le classi memorizzate nella cache dispongano delle modifiche previste quando vengono caricate da un'altra JVM. Ogni modifica deve essere prevedibile poiché le classi caricate da una cache di classi condivise non possono essere modificate di nuovo dall'agente.

Se si utilizza un agente JVMTI senza un contesto di modifica, le classi vengono ancora condivise in modo sicuro dalla JVM, ma con un piccolo impatto sulle prestazioni. L'utilizzo di un contesto di modifica con un agente JVMTI elimina la necessità di effettuare controlli extra, e pertanto non ha alcun impatto sulle prestazioni. Un ClassLoader personalizzato che estende java.net.URLClassLoader e modifica il bytecode durante il tempo di caricamento senza usare JVMTI memorizza automaticamente quel bytecode modificato nella cache, ma la cache non tratta il bytecode come modificato. Qualsiasi altro VM che condivide la suddetta cache carica le classi modificate. L'opzione secondaria modified=<contesto_modifica> può essere utilizzata come con gli agenti JVMTI per partizionare il bytecode modificato nella cache. Se un ClassLoader personalizzato deve effettuare modifiche non prevedibili alle classi durante il tempo di caricamento, tale ClassLoader non deve tentare di utilizzare la condivisione di dati di classe.

Consultare ilManuale per la diagnostica per ulteriori informazioni su questo argomento.

Limitazioni del sistema operativo

Non è possibile condividere le classi tra JVM a 32- e a 64-bit. È necessario che sia disponibile dello spazio temporaneo su disco, in modo da conservare le informazioni di cache. Le autorizzazioni di cache sono imposte dal sistema operativo.

Per sistemi operativi che possono eseguire applicazioni sia a 32 bit che a 64 bit, non è consentita la condivisione di dati di classe tra le JVM a 32 bit e quelle a 64 bit. L'opzione secondaria listAllCaches elenca le cache a 31 bit e quelle a 64 bit, a seconda del modo di indirizzo della JVM utilizzata.

La cache delle classi condivise richiede spazio su disco per memorizzare le informazioni di identificazione relative alle cache esistenti sul sistema. Queste informazioni sono all'interno della directory del profilo utente. Se la directory delle informazioni di identificazione viene eliminata, la JVM non può identificare le classi condivise sul sistema e deve ricreare la cache.

Le autorizzazioni per l'accesso alla cache delle classi condivise sono imposte 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.

Utilizzo di SharedClassPermission

Se SecurityManager viene utilizzato insieme alla condivisione delle classi e l'applicazione in esecuzione utilizza propri classloader, a tali classloader devono essere concesse autorizzazioni di classe condivise prima di poter condividere le classi.

Si aggiungono autorizzazioni di classe condivise al file java.policy utilizzando il nome di classe ClassLoader (i caratteri jolly sono consentiti) e "read", "write", o "read,write" per determinare il grado di accesso concesso. Ad esempio:

permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";

Se un ClassLoader non ha le autorizzazioni corrette, non può condividere classi. Non è possibile modificare le autorizzazioni dei classloader di estensione, applicazione o bootstrap predefiniti.

Adattamento dei classloader personalizzati per la condivisione di classi

Ogni classloader che estende java.net.URLClassLoader può condividere le classi senza dover apportare modifiche. È necessario adattare i classloader che non estendono java.net.URLClassLoader affinché condividano i dati di classe.

È necessario che a tutti i classloader personalizzati siano concesse le autorizzazioni di condivisione delle classi se viene utilizzato un SecurityManager, consultare Utilizzo di SharedClassPermission. IBM fornisce diverse interfacce Java per diversi tipi di classloader personalizzati, che consentono ai classloader di individuare e memorizzare le classi nella cache di classi condivise. Tali classi si trovano nel pacchetto com.ibm.oti.shared.

Il Javadoc per questo pacchetto è fornito con l'SDK nella directory docs/content/apidoc.

Consultare il Manuale per la diagnostica per ulteriori informazioni sull'uso di queste interfacce.

Utilizzo dell'API Java Communications (JavaComm)

Il pacchetto API Java Communications (JavaComm) è un pacchetto facoltativo fornito per l'utilizzo 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.

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 6 Runtime Environment.

Con l'utilizzo di Java Communications API, è possibile:

Installazione dell'API Java Communications da file compresso

Assicurarsi che l'SDK oppure Runtime Environment siano installati prima di installare l'API Java Communications.

Per installare Java Communications API da un file compresso:

  1. Inserire il file compresso dell'API Java Communications, ibm-javacomm-3.0-0.0-win-x86_64.zip, nella directory in cui è stato installato l'SDK o Runtime Environment. Se sono installati nella directory predefinita, tale directory èC:\Program Files\IBM\Java60\.
  2. Estrarre il file compresso. Java Communications API viene estratto nelle relative sottodirectory all'interno della directory esistente.
  3. |Copiare i file javacomm nelle directory |corrette all'interno del proprio SDK. | |
      |
    1. Copiare il file lib\win64com.dll nella propria directory jre\bin\.
    2. |
    3. Copiare il file jar\comm.jar nella propria directory jre\lib\ext\.
    4. |
    5. Copiare il file lib\javax.comm.properties nella propria |directory jre\lib\.
    Per impostazione predefinita, SDK viene installato nella directory C:\Program Files\IBM\Java60\.
  4. |Aggiungere comm.jar al proprio |classpath. Ciò non è obbligatorio per un'installazione JRE. | |
      |
    • Se non si dispone di un classpath definito: set CLASSPATH=\jre\lib\ext\comm.jar
    • |
    • Se già si dispone di un classpath definito: set CLASSPATH=\jre\lib\ext\comm.jar;%classpath%

Configurazione di Java Communications API

Per utilizzare l'API Java Communications, è necessario modificare la modalità di accesso delle porte seriali e parallele, e impostare il PATH, se l'impostazione non è stata effettuata durante l'installazione di Java.

Consultare Impostazione del path.

Specifica dei dispositivi nel file javax.comm.properties

Il file javax.comm.properties consente di specificare i prefissi dei dispositivi resi disponibili all'API Java Communications e se essi sono paralleli o seriali. I numeri delle porte sono allocati sequenzialmente per tutti i dispositivi.

Ad esempio, se si specifica /dev/ttyS=PORT_SERIAL ed esistono i dispositivi /dev/ttyS0 e /dev/ttyS1, questi saranno allocati rispettivamente come COM1 e COM2.

Per usare i connettori USB-serial, eliminare il commento dalla riga /dev/ttyUSB=PORT_SERIAL presente nel file javax.comm.properties. Se i dispositivi /dev/ttyUSB0 e /dev/ttyUSB1 esistono e se COM1 e COM2 sono già stati definiti, i dispositivi USB-serial vengono allocati nelle porte sequenziali successive, COM3 e COM4.

Limitazioni di stampa con Java Communications API

Quando si stampa con Java Communications API, potrebbe essere necessario premere "Alimentazione fogli", "Continua", o qualcosa di simile sulla stampante.

Disinstallazione di Java Communications API

Per disinstallare l'API Java Communications, eliminare i file seguenti dalla directory in cui è installato il Runtime Environment:

Per impostazione predefinita, Runtime Environment viene installato in C:\Program Files\IBM\Java60\.

Documentazione di Java Communications API

È possibile trovare trovare la documentazione delle API ed esempi di Java Communications API sul sito web della Sun.

http://java.sun.com/products/javacomm/.

Servizio e supporto per fornitori di software indipendente

Contattare il servizio:

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.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.

Accessibilità

I manuali per l'utente che sono forniti con SDK e Runtime Environment sono stati testati utilizzando dei lettori di schermo.

Per modificare le dimensioni dei font nei manuali per l'utente, utilizzare la funzione fornita con il proprio browser, che di solito si trova nell'opzione di menu Visualizza.

Per gli utenti che richiedono la navigazione da tastiera, una descrizione dei tasti per le applicazioni Swing si trova in Swing Key Bindings in http://www.ibm.com/developerworks/java/jdk/additional/.

Tastiera trasversale di componenti JComboBox in Swing

Se ci si sposta lateralmente lungo l'elenco a discesa del componente JComboBox con i tasti del cursore, il pulsante o il campo editabile del JComboBox non modificano il loro valore finché non viene selezionata una voce. Questo è il comportamento corretto per questo rilascio e migliora l'accessibilità e l'usabilità assicurando che il comportamento trasversale della tastiera sia coerente con quello del mouse.

Note generali sulla sicurezza

È possibile ottenere file delle politiche di giurisdizione illimitata da http://www.ibm.com/developerworks/java/jdk/security/index.html. La documentazione relativa ai pacchetti di sicurezza IBM JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS e alla crittografia hardware è disponibile anche presso questo sito Web.

Commenti riguardanti il manuale per l'utente

Se si hanno commenti riguardanti questo manuale per l'utente, contattarci attraverso uno dei seguenti canali. Notare che questi canali non sono creati per rispondere a domande di natura tecnica, ma solo per i commenti relativi alla documentazione.

Inviare i commenti a:

Annotazioni. Inviando un messaggio a 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.

Appendice A. Opzioni non standard

Le opzioni -X sotto elencate sono non standard e soggette a modifica senza preavviso.

Per le opzioni che assumono il parametro <size>, aggiungere al numero un suffisso "k" o "K" per indicare i kilobyte, "m" o "M" per indicare i megabyte, oppure "g" o "G" per indicare i gigabyte.

Per le opzioni che assumono il parametro <percentage>, utilizzare un numero da 0 a 1. Ad esempio, 50% è 0.5.

-Xargencoding
Consente di inserire le sequenze di escape Unicode nell'elenco di argomenti. Questa opzione è impostata sull'impostazione predefinita off.
-Xbootclasspath:<directory e file zip o jar separati da :>
Imposta il percorso di ricerca per le risorse e le classi bootstrap. L'impostazione predefinita è di effettuare la ricerca delle classi di bootstrap e delle risorse all'interno delle directory delle VM interne e dei file .jar.
-Xbootclasspath/a:<directory e file zip o jar separati da :>
Accoda le directory specificate, i file jar o zip alla fine del percorso di classe di bootstrap. L'impostazione predefinita è di effettuare la ricerca delle classi di bootstrap e delle risorse all'interno degli indirizzari VM interni e dei file .jar.
-Xbootclasspath/p:<directory e file zip o jar separati da :>
Inserisce le directory specificate, i file jar o zip all'inizio del percorso di classe di bootstrap. Non distribuire le applicazioni che utilizzano l'opzione -Xbootclasspath: o -Xbootclasspath/p: per sovrascrivere una classe nell'API standard, poiché tale distribuzione potrebbe contravvenire la licenza sul codice binario Java Runtime Environment. L'impostazione predefinita è di effettuare la ricerca delle classi di bootstrap e delle risorse all'interno delle directory delle VM interne e dei file .jar.
|-Xcheck:classpath
|Visualizza un messaggio di avviso se viene scoperto un errore nel percorso della classe, per esempio una directory o un file jar mancante.
-Xcheck:gc[:<opzioni scan >][:<opzioni verifica >][:<opzioni varie >]
Esegue un ulteriore verifica sulla raccolta dei dati obsoleti. Per impostazione predefinita, non viene effettuata alcuna verifica. Per ulteriori informazioni, consultare l'output di -Xcheck:gc:help.
-Xcheck:jni
Esegue un'ulteriore verifica per le funzioni JNI. Per impostazione predefinita, non viene effettuata alcuna verifica.
|-Xcheck:memory[:<opzione>]
Identifica le perdite di memoria all'interno della JVM utilizzando controlli severi che causano l'uscita della JVM in caso di errore. Se non viene specificata alcuna opzione, all viene utilizzata per impostazione predefinita. Per ulteriori informazioni consultare l'output di -Xcheck:memory:help oppure il Manuale per la diagnostica.
-Xcheck:nabounds
Esegue un'ulteriore verifica per le funzioni JNI. Per impostazione predefinita, non viene effettuata alcuna verifica.
-Xclassgc
Abilita la raccolta di oggetti classe ad ogni raccolta di dati obsoleti. Consultare anche -Xnoclassgc. Per impostazione predefinita, questa opzione è abilitata.
-Xcodecache<dimensione>
Imposta la dimensione delle unità dei blocchi di memoria allocati per memorizzare codice nativo di metodi Java compilati. È possibile a scegliere una dimensione appropriata per l'applicazione in esecuzione. Per impostazione predefinita, tale dimensione viene scelta internamente in base all'architettura CPU e alle capacità del sistema.
-Xcompactexplicitgc
Esegue una compattazione per ogni chiamata a System.gc(). Consultare anche -Xnocompactexplicitgc. Per impostazione predefinita, la compressione avviene solo quando viene attivata internamente.
-Xcompactgc
Effettua una compattazione per ogni raccolta di dati obsoleti. Consultare anche -Xnocompactgc. Per impostazione predefinita, la compressione avviene solo quando viene attivata internamente.
-Xconcurrentbackground<numero>
Specifica il numero di thread in secondo piano a bassa priorità allegati per assistere i thread mutator nel contrassegno simultaneo. L'impostazione predefinita è 1.
-Xconcurrentlevel<numero>
Specifica una velocità "tax" di allocazione. Indica il rapporto tra la quantità di heap allocati e la quantità di heap contrassegnati. L'impostazione predefinita è 8.
-Xconmeter:<soa|loa|dynamic>
Determina quale utilizzo dell'area, LOA (Large Object Area) o SOA (Small Object Area), viene misurata e pertanto quali allocazioni vengono tassate durante il contrassegno simultaneo. La velocità "tax" di allocazione viene applicata all'area selezionata. Se si specifica -Xconmeter:dynamic il raccoglitore determina in modo dinamico l'area da misurare sulla base di quale area si è esaurita prima. Per impostazione predefinita, l'opzione è impostata su -Xconmeter:soa.
-Xdbg:<opzioni>
Carica le librerie di debug per il supporto del debug remoto delle applicazioni. Consultare Esecuzione del debug di applicazioni Java per ulteriori informazioni. Specificando-Xrunjdwp si ottiene lo stesso supporto.
-Xdebug
Avvia la JVM con il programma di debug abilitato. Per impostazione predefinita, il programma di debug viene disabilitato.
-Xdisableexcessivegc
Disabilita l'attivazione di un'eccezione OutOfMemoryError se viene impiegato troppo tempo nella GC. Per impostazione predefinita, questa opzione è off.
-Xdisableexplicitgc
I segnali al VM che chiama System.gc() non devono avere effetto. Per impostazione predefinita, chiamate a System.gc() attivano una raccolta di dati obsoleti.
-Xdisablestringconstantgc
Impedisce alle stringhe di essere raccolte nella tabella interna delle stringhe. Per impostazione predefinita, questa opzione è disabilitata.
-Xdisablejavadump
Disattiva la generazione di Javadump in caso di errori e segnali. Per impostazione predefinita, la generazione di Javadump è disabilitata.
-Xenableexcessivegc
Se viene impiegato un tempo eccessivo in GC, questa opzione restituisce NULL per una richiesta di allocazione e pertanto provoca l'attivazione di un'eccezione OutOfMemory. Questa azione si verifica solo quando l'heap è stato espanso completamento e il tempo impiegato è di almeno il 95%. Questo è il comportamento predefinito.
-Xenableexplicitgc
Segnala alla VM che le chiamate a System.gc() dovrebbero innescare una raccolta di dati obsoleti. Questo l'impostazione predefinita.
-Xenablestringconstantgc
Abilita la raccolta delle stringhe nella tabella interna delle stringhe. Per impostazione predefinita, questa opzione è abilitata.
-Xfuture
Attiva i controlli del formato classe file severi. Utilizzare questo segnalatore durante lo sviluppo del nuovo codice, poiché nei rilasci successivi i controlli saranno più severi per impostazione predefinita. Per impostazione predefinita, i controlli severi del formato vengono disabilitati.
-Xgcpolicy:<optthruput|optavgpause|gencon>
Controlli del comportamento del Raccoglitore di dati obsoleti. Consultare Opzioni di Raccolta dei dati obsoleti per ulteriori informazioni.
-Xgcthreads<numero di thread>
Imposta il numero di thread dell'helper utilizzati per le operazioni parallele durante la raccolta di dati obsoleti. Per impostazione predefinita, il numero di thread viene impostato sul numero di CPU fisiche esistenti -1, con un minimo di 1.
-Xgcworkpackets<numero>
Specifica il numero totale di pacchetti di lavoro disponibili nella raccolta globale. Se non specificata, il raccoglitore alloca il numero di pacchetti basato sulla dimensione massima di heap.
-Xint
Questa opzione fa utilizzare a JVM solo l'interprete, disabilitando il compilatore JIT (Just-In-Time). Per impostazione predefinita, l compilatore JIT è abilitato.
-Xiss<dimensione>
Imposta la dimensione di stack dei thread Java iniziale. L'impostazione predefinita è 2 KB. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
|-Xjarversion
|Consultare Recuperare informazioni sulla versione.
-Xjit[:<opzione secondaria>,<opzione secondaria>...]
Abilita JIT. Per dettagli sulle opzioni secondarie, consultare il Manuale per la diagnostica. Consultare anche -Xnojit. Per impostazione predefinita, JIT è abilitato.
-Xlinenumbers
Visualizza i numeri della riga nelle tracce di stack, per effettuare il debug. Consultare anche -Xnolinenumbers. Per impostazione predefinita, i numeri della riga sono impostati su on.
-Xloa
Alloca una LOA (Large Object Area). Gli oggetti saranno allocati in questa LOA anziché nella SOA. Per impostazione predefinita, la LOA è abilitata per tutte le normative GC eccetto per il lotto secondario, in cui la LOA non è disponibile. Vedere anche -Xnoloa.
-Xloainitial<percentuale>
<percentuale> è un numero compreso tra 0 e 0,95, che specifica la percentuale iniziale dello spazio di possesso attuale allocato su una LOA (large object area). Il valore predefinito è 0,05 o 5%.
-Xloamaximum<percentuale>
<percentuale> è un numero compreso tra 0 e 0,95, che specifica la percentuale massima dello spazio di possesso attuale allocato su una LOA (large object area). Il valore predefinito è 0,5 o 50%.
-Xlp (Windows 2003)
Richiede alla JVM di allocare l'heap di Java con pagine grandi. Se le pagine grandi non sono disponibili, JVM non verrà avviato, visualizzando un messaggio di errore simile al seguente: GC: system configuration does not support option --> '-Xlp'. Le pagine grandi sono supportate da sistemi che eseguono Windows 2003, in cui il sistema operativo è stato impostato per l'uso di pagine grandi. Per impostazione predefinita, le pagine grandi non vengono utilizzate. Consultare Configurazione dell'allocazione di memoria di pagine grandi.
-Xmaxe<dimensione>
Imposta la quantità massima su cui il raccoglitore di dati obsoleti espanderà la memoria riservata. Di solito, il raccoglitore di dati obsoleti espande la memoria riservata quando lo spazio libero ha una quantità compresa tra il 30% (o la quantità specificata utilizzando -Xminf), in base alla quantità richiesta per ripristinare lo spazio libero al 30%. L'opzione -Xmaxe limita l'espansione al valore specificato, ad esempio -Xmaxe10M limita l'espansione a 10 MB. Per impostazione predefinita, non esiste alcuna dimensione di espansione massima.
-Xmaxf<percentuale>
Specifica la percentuale massima di memoria riservata che deve essere libera in seguito ad una raccolta di dati obsoleti. Se lo spazio libero supera tale quantità, JVM tenta di restringere la memoria limitata. Il valore predefinito è 0,6 (60%).
-Xmca<dimensione>
Imposta il passo di espansione per la memoria allocata per memorizzare la parte RAM delle classi caricate. Ogni volta che viene richiesta più memoria per memorizzare le classi nella RAM, la memoria allocata viene aumentata da questa quantità. Per impostazione predefinita, il passo di espansione è di 32 Kb. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmco<dimensione>
Imposta il passo di espansione per la memoria allocata per memorizzare la parte ROM delle classi caricate. Ogni volta che viene richiesta più memoria per memorizzare le classi nella ROM, la memoria allocata viene aumentata da questa quantità. Per impostazione predefinita, il passo di espansione è di 128 Kb. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmine<dimensione>
Imposta la quantità minima per cui il raccoglitore di dati obsoleti espanderà la memoria riservata. Di solito, il raccoglitore dati obsoleti, espande la memoria riservata in base alla quantità richiesta per ripristinare lo spazio libero al 30% (o la quantità specificata utilizzando -Xminf). L'opzione -Xmine imposta l'espansione per essere almeno uguale al valore specificato, ad esempio -Xmine50M imposta la dimensione di espansione su un minimo di 50. Per impostazione predefinita, la dimensione di espansione minima è di 1 Mb.
-Xminf<percentuale>
Specifica la percentuale minima di memoria riservata che deve essere libera in seguito ad una raccolta di dati obsoleti. Se lo spazio libero non raggiunge tale quantità, JVM tenta di espandere la memoria limitata. Per impostazione predefinita, il valore minimo è di 0,3 (30%).
-Xmn<dimensione>
Imposta la dimensione iniziale e massima del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Impostare -Xmn è equivalente a impostare -Xmns e -Xmnx. Se si imposta -Xmns oppure -Xmnx, non è possibile impostare -Xmn. Se si cerca di impostare -Xmn con -Xmns oppure con -Xmnx, VM non verrà avviato e restituirà un errore. Per impostazione predefinita, -Xmn viene selezionato internamente in base alle caratteristiche del sistema. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmns<dimensione>
Imposta la dimensione iniziale del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmn. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmnx<dimensione>
Imposta la dimensione massima del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmn. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmo<dimensione>
Imposta la dimensione iniziale e massima dell'heap precedente (di possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. E' equivalente all'impostazione sia di -Xmos che di -Xmox. Se si imposta -Xmos oppure -Xmox, non è possibile impostare -Xmo. Se si cerca di impostare -Xmo con -Xmos oppure con -Xmox, la M non verrà avviata e restituirà un errore. Per impostazione predefinita, -Xmo viene selezionato internamente in base alle caratteristiche del sistema. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmoi<dimensione>
Imposta la quantità di heap Java incrementata quando si utilizza -Xgcpolicy:gencon. Se è impostata su zero, non viene consentita alcuna espansione. Per impostazione predefinita, la dimensione di incremento viene calcolata sulla dimensione di espansione -Xmine e -Xminf.
-Xmos<dimensione>
Imposta la dimensione iniziale dell'heap precedente (possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmo. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmox<dimensione>
Imposta la dimensione massima dell'heap precedente (possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmo. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmr<dimensione>
Imposta la dimensione dell'"impostazione ricordata" della raccolta dati obsoleti quando si utilizza -Xgcpolicy:gencon. Questo è un elenco di oggetti della vecchia memoria riservata (posseduta) che si riferiscono ad oggetti nella nuova memoria riservata (asilo). Per impostazione predefinita, questa opzione viene impostata a 16 kilobyte. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmrx<dimensione>
Imposta il settaggio della dimensione massima ricordata.
-Xms<dimensione>
Imposta la dimensione della memoria riservata Java iniziale. È possibile utilizzare anche -Xmo. Il valore predefinito viene impostato internamente in base alle capacità del sistema. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmso<dimensione>
Imposta la dimensione dello stack C dei thread Java duplicati. Per impostazione predefinita, a questa opzione è impostata a 32 KB su piattaforme a 32-bit e a 256 KB su piattaforme a 64-bit. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xmx<dimensione>
Imposta la dimensione massima della memoria riservata Java. Per impostazione predefinita, questa opzione è impostata internamente in base alle capacità del sistema. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xnoclassgc
Disabilita la raccolta disordinata di classi. Questa opzione disattiva la raccolta dei dati obsoleti della memoria associata alle classi Java che non sono più utilizzate da JVM. Consultare anche -Xclassgc. Per impostazione predefinita, viene effettuata la raccolta di dati obsoleti della classe.
-Xnocompactexplicitgc
Disabilita la compattazione su una chiamata a System.gc(). Consultare anche -Xcompactexplicitgc. Per impostazione predefinita, la compressione è abilitata sulle chiamate a System.gc().
-Xnocompactgc
Disabilita il compattamento per il Raccoglitore di dati obsoleti. Consultare anche -Xcompactgc. Per impostazione predefinita, la compressione è abilitata.
-Xnojit
Disabilita il compilatore JIT. Consultare anche -Xjit. Per impostazione predefinita, l compilatore JIT è abilitato.
-Xnolinenumbers
Disabilita i numeri di riga per il debug. Consultare anche -Xlinenumbers. Per impostazione predefinita, i numeri della riga sono impostati su on.
-Xnoloa
Impedisce l'allocazione di una LOA (Large Object Area). Tutti gli oggetti saranno allocati nella SOA. Per impostazione predefinita, la LOA è abilitata per tutte le normative GC eccetto per il lotto secondario, in cui la LOA non è disponibile. Vedere anche -Xloa.
-Xnopartialcompactgc
Disabilita la compressione incrementale. Consultare anche -Xpartialcompactgc.
-Xnosigcatch
Disabilita il codice di gestione del segnale JVM. Consultare anche -Xsigcatch. Per impostazione predefinita, la gestione del segnale è abilitata.
-Xnosigchain
Disabilita il concatenamento della gestione del segnale. Consultare anche -Xsigchain. Per impostazione predefinita, il concatenamento della gestione del segnale è abilitato.
-Xoptionsfile=<file>
Specifica un file che contiene le opzioni JVM e esegue la definizione. Per impostazione predefinita, non viene utilizzato alcun file di opzioni.
-Xoss<dimensione>
Imposta la dimensione di stack Java e la dimensione di stack C per tutti i thread. Questa opzione viene fornita per motivi di compatibilità ed è equivalente a impostare entrambi i parametri -Xss e -Xmso sul valore specificato.
-Xpartialcompactgc
Abilita la compressione parziale. Per impostazione predefinita, questa opzione non viene impostata, pertanto tutte le compressioni sono piene. Consultare anche -Xnopartialcompactgc.
-Xquickstart
Migliora il tempo di avvio ritardando la compilazione JIT e le ottimizzazioni. Per impostazione predefinita, viene disabilitato quickstart e non vi è alcun ritardo nella compilazione JIT.
-Xrdbginfo:<host>:<porta>
Carica e passa le opzioni al server di informazioni di debug remoto. Per impostazione predefinita, il server delle informazioni di debug remoto viene disabilitato.
-Xrs
Riduce l'utilizzo dei segnali del sistema operativo. Per impostazione predefinita, VM utilizza completamente i segnali del sistema operativo; per informazioni consultare Segnali utilizzati da JVM.
-Xrun<nome libreria>[:<opzioni>]
Carica le librerie dell'helper. Per caricare più librerie, specificarle più volte nella riga comandi. Alcuni esempi di libreria sono:
-Xrunhprof[:help] | [:<opzione>=<valore>, ...]
Esegue heap, CPU, profili di controllo. Per ulteriori informazioni, consultare il Manuale per la diagnostica.
-Xrunjdwp[:help] | [:<opzione>=< valore>, ...]
Carica le librerie di debug per il supporto del debug remoto delle applicazioni. Consultare -Xdbg per ulteriori informazioni.
-Xrunjnichk[:help] | [:<opzione>=<valore>, ...]
Obsoleta, utilizzare -Xcheck:jni.
-Xscmx<dimensione>
Per informazioni dettagliate su -Xscmx, consultare Abilitazione e configurazione della condivisione dei dati delle classi.
-Xshareclasses:<opzioni>
Per informazioni dettagliate sulle opzioni -Xshareclasses, consultare Abilitazione e configurazione della condivisione dei dati delle classi.
-Xsigcatch
Abilita il codice di gestione del segnale VM. Consultare anche -Xnosigcatch. Per impostazione predefinita, la gestione del segnale è abilitata.
-Xsigchain
Abilita il concatenamento della gestione del segnale. Consultare anche -Xnosigchain. Per impostazione predefinita, il concatenamento della gestione del segnale è abilitato.
-Xsoftrefthreshold<numero>
Imposta il numero di GC dopo i quali un riferimento soft verrà eliminato se il relativo referente non è stato contrassegnato. Il valore predefinito è 3, cioè, al terzo GC in cui non viene contrassegnato il referente, il riferimento soft verrà eliminato.
-Xss<dimensione>
Imposta la dimensione di stack Java massima per tutti i thread. Per impostazione predefinita, in quest'opzione è impostata su 256 KB. Utilizzare l'opzione -verbose:sizes per inviare all'output il valore utilizzato dalla VM.
-Xthr:<opzioni>
Imposta le opzioni di thread.
-Xverbosegclog:< percorso per il file>[X,Y]

Comporta che l'output dettagliato della raccolta dati obsoleti (GC) venga scritto nel file specificato. Se il file esiste, viene sovrascritto. Altrimenti, se non si riesce ad aprire un file esistente, o se non è possibile creare un nuovo file, l'output viene reindirizzato a stderr. Se si specificano gli argomenti X e Y (entrambi interi) l'output GC dettagliato viene indirizzato sul numero X di file, ciascuno contenente il numero Y di cicli GC validi dell'output GC dettagliato . Questi file hanno il formato nomefile1, nomefile2 e così via. Per impostazione predefinita, non viene effettuato alcun log verboso della raccolta di dati obsoleti.

Consultare il Manuale per la diagnostica per ulteriori informazioni sull'output GC dettagliato.

-Xverify
Abilita il controllo classi severo per ciascuna classe caricata. Per impostazione predefinita, il controllo severo delle classi è disabilitato.
-Xverify:none
Disabilita il controllo severo delle classi. Per impostazione predefinita, il controllo severo delle classi è disabilitato.

Appendice B. Limitazioni note

Limitazioni note di SDK e Runtime Environment per Windows.

È possibile trovare un ulteriore aiuto per la diagnosi del problema nel Manuale per la diagnostica in http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.

Impostazioni BIOS su sistemi SMP AMD64:

L'impostazione BIOS Node memory interleaving deve essere impostata su DISABLED. In caso contrario, possono verificarsi risultati imprevedibili, comprese interruzioni e blocchi di Java. Questa istruzione è conforme alle raccomandazioni di AMD.

Problemi relativi ai caratteri nelle locali supportate

IBM 64-bit SDK per Windows, v6 supporta le seguenti locali:

Tuttavia, i font di queste locali potrebbero non funzionare sui componenti AWT.

Utilizzo dei socket con IPv6

IBM 64-bit SDK per Windows, v6 supporta IPv6. Tuttavia, poiché il supporto IPv6 corrente in Windows non è dual-stack, SDK emula un comportamento dual-stack su un sistema IPv6 abilitato. L'applicazione Java utilizzata potrebbe usare sino a due volte i socket a causa della natura dell'emulazione. Per disabilitare questa emulazione, disabilitare il supporto IPv6 in SDK impostando la proprietà del sistema java.net.preferIPv4Stack su true.

Pannello Locale del tool di monitoraggio JConsole

Nel tool IBM JConsole, il pannello Local, che consente la connessione ad altre Virtual Machines sullo stesso sistema, non è disponibile. Inoltre, l'opzione di riga comandi pid non è supportata. È invece possibile utilizzare il pannello Remote in JConsole per connettersi alle Virtual Machine che si desiderano monitorare. In alternativa, utilizzare l'opzione di riga comandi connection, specificando un host di localhost e un numero di porta. Lanciando l'applicazione che si desidera monitorare, impostare queste opzioni di riga comandi:

-Dcom.sun.management.jmxremote.port=<valore>
Specifica quale porta l'agente di gestione deve ascoltare.
-Dcom.sun.management.jmxremote.authenticate=false
Disabilita l'autenticazione a meno che non abbiate creato un file nome utente.
-Dcom.sun.management.jmxremote.ssl=false
Disabilita la crittografia SSL.

Il motore Javascript Rhino non è disponibile

Il motore Mozilla Rhino Javascript non è incluso nell'SDK IBM per Java per motivi legati alla licenza. Per utilizzare il motore Rhino Javascript con l'SDK IBM per Java, scaricare il motore di scripting jsr223 da https://scripting.dev.java.net/, e il motore Rhino Javascript dal sito web di Mozilla: http://www.mozilla.org/rhino/.

Input Method Editor (IME)

Durante la gestione di IME, la composizione caratteri deve essere completata ed il candidato selezionato prima di utilizzare lo spazio di lavoro per le altre operazioni.

Quando un utente immette del testo in un'area di testo AWT mentre utilizza un IME (Input Method Editor), e modifica quindi la finestra dell'applicazione prima di eseguire il commit del testo, il commit del testo viene eseguito automaticamente.

Lentezza nella creazione di coppie di chiavi DSA

La creazione di coppie di chiavi DSA di lunghezza insolita può richiedere molto tempo su macchine lente. Non interpretare questo ritardo come un blocco, poiché il processo verrà completato se sarà disponibile un periodo di tempo sufficiente. L'algoritmo di generazione delle chiavi DSA S stato ottimizzato in modo da generare lunghezze di chiavi standard (ad esempio 512, 1024) pi- velocemente di altre.

Firewall personali

I firewall personali possono causare problemi al codice Windows NIO, comportando il malfunzionamento di particolari operazioni. Ad esempio, la chiamata del metodo Selector.open() può comportare una "java.io.IOException: Unable to establish loopback connection" con causa "java.net.ConnectException: Connection refused: connect". L'eccezione viene causata dal sistema operativo che si collega su una porta bloccata dal firewall. La JVM tenterà l'operazione di connessione, richiedendo al sistema operativo di scegliere uno numero di porta differente. Se, dopo ripetuti tentativi, non è ancora possibile connettersi, viene ricevuto un ConnectException.

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.

Esaurimento degli handle per i file

Su Windows XP, il valore predefinito del numero di file che possono essere aperti simultaneamente è troppo basso e provocherà problemi alle applicazioni che hanno un I/O intenso. Per correggere questa limitazione, modificare il file <windows>\system32\CONFIG.NT e impostare i seguenti valori:

files=200
buffers=60

dove <windows> è la directory dove è installato Windows.

Caratteri DBCS

Se si sta scrivendo con caratteri DBCS in JTextArea, JTextField o JFileChooser, il passaggio da IME cinesi (in particolare, codice interno cinese e Zhengma) a Intelligent ABC IME potrebbe causare un core dump.

Installazione in lingua ceca

Per gli utenti della repubblica ceca, si noti che il pannello di selezione della lingua di InstallShield offre una voce tradotta in un'installazione diversamente non tradotta. Questa limitazione è dovuta a InstallShield. La stringa viene richiamata dal sistema operativo basato sulla codepage. Poiché il Polacco (per il quale è stata tradotta l'installazione) e il Ceco hanno la codepage 1250, InstallShield cerca di richiamare un elenco di lingue dal sistema per entrambe queste lingue, e viene visualizzata questa stringa nell'elenco di lingue.

Cinese tradizionale e il comando more

Se si utilizza il cinese tradizionale, non utilizzare il carattere pipe per l'emissione dall'applicazione Java direttamente nel comando more. Reindirizzare invece l'output in un file temporaneo e quindi visualizzare il file separatamente.

MS-IME giapponese e i temi di Windows XP

Se si utilizza la lingua giapponese MS-IME su Windows XP Professional x64 Edition, il SDK a 64 bit potrebbe causare errori con i temi di Windows XP. Per evitare questi errori, impostare la variabile d'ambiente IBMJAVA_USE_WINDOWS_CLASSIC_THEME per obbligare la finestra della GUI di Java a visualizzare i contenuti utilizzando il tema Windows classico, oppure modificare il tema del vostro sistema scegliendo Windows classico. Per ulteriori informazioni su questa limitazione, solo per il giapponese, vedere Microsoft Knowledge Base Article 905843.

NullPointerException con il Look-and-Feel GTK

Solo ambienti DBCS

Se usando il Look-and-Feel GTK l'applicazione non riesce e restituisce un NullPointerException, rimuovere l'impostazione della variabile d'ambiente GNOME_DESKTOP_SESSION_ID.

Alias codepage Unicode per Shift_JIS

Solo utenti giapponesi

L'alias codepage Unicode "\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe" per Shift_JIS è stato rimosso. Se si impiega questo codepage delle applicazioni utilizzate sostituirlo con Shift_JIS.

Informazioni particolari

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 IBM 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.

Marchi

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à.