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

SDK e Guida Runtime



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

Indice

Prefazione
Panoramica
Compatibilità della versione
Migrazione da altre JVM IBM
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 percorso
Impostazione del percorso di classe
Disinstallazione
Esecuzione di applicazioni Java
I comandi java e javaw
Come ottenere informazioni sulla versione
Specifiche delle opzioni e proprietà di sistema Java
Opzioni standard
Globalizzazione dei comandi java
Esecuzione automatica di un file Java
Esecuzione di applicazioni Java con le tecnologie native assistite
Compilatore JIT (Just-In-Time)
Come disabilitare JIT
Come abilitare JIT
Come determinare se JIT è abilitato
Specifica del criterio per la 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
| |
Utilizzo di metodi di immissione per indiano e thai
Utilizzo di SDK per sviluppare le applicazioni Java
| |
Utilizzo di XML
| |
Migrazione a XL-TXE-J
| |
Informazioni di riferimento XML
Esecuzione del debug nelle applicazioni Java
JDB (Java Debugger)
Come determinare se l'applicazione viene eseguita da una JVM 32 bit o a 64 bit
Modalità in cui la JVM elabora i segnali
Segnali usati da JVM
Collegamento di un driver di codice nativo alla libreria per il concatenamento 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 di sicurezza Java per l'ORB
Classi di implementazione ORB
RMI su IIOP
Implementazione di Connection Handler Pool per RMI
BigDecimal migliorato
Plug-in, Applet Viewer e Web Start
Utilizzo di Java Plug-in
Browser supportati
Supporto SSV (Secure Static Versioning)
Supporto DOM (Document Object Model) comune
Utilizzo dei parametri DBCS
Operazioni con le applet
Esecuzione delle applet con Applet Viewer
CLSID unici
Esecuzione del debug delle applet con Applet Viewer
Utilizzo di Web Start
Esecuzione di Web Start
WebStart Secure Static Versioning
Invio di applicazioni Java
Condivisione di dati delle classi tra JVM
Panoramica sulla condivisione dei dati delle classi
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 dell'API Java Communications
Specifica dei dispositivi nel file javax.comm.properties
Limitazioni di stampa con l'API Java Communications
Disinstallazione dell'API Java Communications
Documentazione Java Communications API
Servizio e supporto per fornitori di software indipendente
Accessibilità
Tastiera trasversale di componenti JComboBox in Swing
Accessibilità di Web Start
Note generali sulla sicurezza
Commenti riguardanti il manuale per l'utente
Appendice A. Opzioni non standard
Appendice B. Limiti noti
Informazioni particolari
Marchi

Prefazione

Questo manuale per l'utente fornisce informazioni generali su IBM SDK a 32-bit e Runtime Environment per Windows, 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:

Sono supportati questi Ambienti virtualizzati:

Si noti che IPv6 è supportato solo su Windows XP e Windows Server 2003.

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 questo specifico rilascio. Assicurarsi di possedere il manuale per l'utente appropriato per il rilascio che si sta utilizzando.

I termini "Runtime Environment" e "Java Virtual Machine" sono utilizzati scambievolmente in questo manuale per l'utente.

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

Il Codice Programma non è progettato o inteso per essere utilizzato in applicazioni in tempo reale quali (ma non soltanto) il controllo in linea di aeroplani, traffico aereo, navigazione aerea o comunicazioni aeree; o nella progettazione, costruzione, funzionamento o manutenzione di strutture nucleari.

Panoramica

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

SDK comprende Runtime Environment per Windows, che abilita ad eseguire solo applicazioni Java . Se è stato installato SDK, è incluso anche Runtime Environment.

Runtime Environment contiene la Java Virtual Machine e i file di supporto compresi i file .so file delle classi. Runtime Environment contiene solo un insieme secondario delle classi trovate in SDK e consente di supportare un programma Java in esecuzione ma non consente la compilazione di programmi Java . Runtime Environment per Windows non comprende alcuno strumento di sviluppo, per esempio appletviewer.exe o il compilatore Java (javac.exe), o le classi che sono solo per i sistemi di sviluppo.

Inoltre, il pacchetto API (application programming interface)Java Communications viene fornito per l'utilizzo con Runtime Environment per Windows. Per informazioni, consultare la sezione Utilizzo dell'API Java Communications (JavaComm).

Compatibilità della versione

In generale, ogni applet o applicazione eseguibile con una versione precedente di SDK dovrebbe essere eseguita correttamente con IBM SDK a 32 bit per Windows, v6. Non si garantisce che le classi compilate con questo rilascio funzionino con i rilasci precedenti.

IBM SDK a 32 bit per Windows, v6, viene generato con Microsoft Visual Studio .NET 2003.

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 v5.0 non siano compatibili. Tuttavia, le classi sono compatibili tra gli aggiornamenti di servizio.

Migrazione da altre JVM IBM

Dalla versione 5.0, il Runtime Environment IBMper 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 un IBM Runtime Environment più vecchio, notare che:

Contenuti di SDK e Runtime Environment

SDK contiene diversi strumenti di sviluppo e un JRE (Java Runtime Environment). Questa sezione descrive i contenuti degli strumenti SDK e di Runtime Environment.

Le applicazioni scritte interamente in Java non devono avere dipendenze dalla struttura delle directory di IBM SDK (o dai file di tali directory). Ogni dipendenza dalla struttura delle directory di SDK (o dai file in tali directory) potrebbe comportare problemi di portabilità dell'applicazione. Le applicazioni JNI (Java Native Interfacce avranno dipendenze minori.

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

Lista di classi e strumenti che si possono utilizzare con il Runtime Environment standard.

Strumenti SDK ed informazioni di riferimento

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

I seguenti strumenti fanno parte del SDK e si trovano nella directory C:\Program Files\IBM\Java60\bin:
appletviewer.exe (Applet ViewerJava)
Testa ed esegue applet al di fuori di un browser web.
apt.exe (Strumento Processore di Annotazioni)
Trova ed esegue processori di annotazioni che si basano sulle annotazioni presenti nell'insieme dei file sorgente specificati che sono oggetto di esame.
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.
HtmlConverter.exe (Programma di conversione HTML Java Plug-in)
Converte una pagina HTML che contiene delle applet in un formato che può usare il Plug-in Java .
idlj.exe (IDL su Compilatore Java )
Genera legami 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 il Manuale per la sicurezza e visitare il sito http://www.ibm.com/developerworks/java/jdk/security.
jar.exe (Strumento di Archiviazione Java)
Combina file multipli in un singolo file Java Archive (JAR).
jarsigner.exe (Strumento per firme e verifiche JAR)
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 (Compiler Java)
Compila programmi scritti nel linguaggio di programmazione Java in bytecode (codice Java compilato).
javadoc.exe (Generatore di Documentazione Java)
Genera pagine HTML di documentazione delle 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 allo stesso modo del comando java senza usare una finestra di console.
javaws.exe (Java Web Start)
Abilita la distribuzione e la manutenzione automatica delle applicazioni Java. Per ulteriori informazioni, fare riferimento a Esecuzione di Web Start.
jconsole.exe (strumento JConsole di monitoraggio e gestione)
Effettua il monitoraggio delle JVM da locale e remoto, mediante una GUI. JMX-compliant.
jdb.exe (Java Debugger)
Aiuta ad eseguire il debug dei 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 di matrici RMI Java Remote Method Invocation)
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 portatili utilizzate nei servizi web JAX-WS.
wsimport.exe
Genera risorse JAX-WS portatili da un file WSDL.
xjc.exe
Compila file di schema XML.
Includere File
Intestazione in C per programmi JNI.
Demo
La directory demo contiene un numero di sottodirectory contenenti esempi di codice sorgente, demo, applicazioni e applet da utilizzare. |Dalla versione 6, il demo RMI-IIOP non è incluso nell'SDK.
copyright
Notizie riguardanti il copyright del SDK per il softwareWindows.
Licenza

Il file di Licenza, C:\Program Files\IBM\Java60\docs\content\<locale>\LA_<locale>, contiene il contratto di licenza per SDK il softwareWindows (dove <locale> è il nome della localizzazione, per esempio en). Per visualizzare o stampare il contratto 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-i386.exe (per SDK) o ibm-java-jre-60-win-i386.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 associarsi 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-i386 /r

oppure

ibm-java-jre-60-win-i386 /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-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
ibm-java-jre-60-win-i386 /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) 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 percorso

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, digitare quanto segue a una richiesta di comandi:

echo %PATH%

Per aggiungere i programmi di avvioJava 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 prompt dei 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 prompt dei comandi, digitare:

javac Myfile.Java

Impostazione del percorso di classe

Il percorso di classe indica agli strumenti SDK , come java, javac, e javadoc, dove trovare le librerie della classe Java .

È 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 sviluppano e si eseguono applicazioni che utilizzano diversi ambienti runtime, comprese altre versioni installate separatamente, è necessario impostare esplicitamente CLASSPATH e PATH per ogni applicazione. Se si eseguono molteplici applicazioni simultaneamente e si usano diversi ambienti runtime, ciascuna applicazione deve essere eseguita nella propria richiesta comandi.

Disinstallazione

Utilizzare l'utilità Cambia/Rimuovi programmi di Windows per disinstallare SDK oppure Runtime Environment.

Per disinstallare SDK, sia che sia stata eseguita l'installazione presidiata che non presidiata, procedere come segue:

  1. Fare doppio clic su Risorse del computer sul desktop di Windows.
  2. Fare doppio clic su Pannello di controllo.
  3. Fare doppio clic su Installazione applicazioni.
  4. Fare clic su IBM 32-bit SDK per Java 2 v6 nell'elenco e poi fare clic su Cambia/Elimina.
  5. Fare clic su OK.

Questa procedura rimuove tutti i pacchetti installati con l'Installer. Non rimuove il pacchetto API Java Communications (consultareDisinstallazione dell'API Java Communications) oppure eventuali file aggiuntivi estratti dai pacchetti compressi.

Nota: Potrebbero essere visualizzati dei messaggi di avvertenza che indicano che non tutti i file o le voci di registro, o entrambi, sono stati rimossi. Queste avvertenze vengono emesse perché Windows ritiene che alcuni file siano ancora in uso; tali file, voci di registro, o entrambi, verranno rimossi al prossimo riavvio.

Se non si dispone delle autorizzazioni necessarie a disinstallare SDK oppure Runtime Environment, "Error1325.launchpad non è un nome abbreviato di file valido". Per disinstallare SDK oppure Runtime Environment, ripristinare le autorizzazioni corrette.

Quando si gestiscono installazioni multiple tra IBM SDK a 32 bit per Windows, v6, e le versioni a livello V1.3.1 o precedenti, se si disinstalla la versione precedente mentre è ancora installata una versione v6 il programma di disinstallazione di V1.3.1 rimuove le seguenti chiavi di registro e le sottochiavi richieste dalla versione v6,causando malfunzionamenti all'installazione di v6:

Pertanto, reinstallare v6 dopo aver disinstallato la versione V1.3.1. Questa restrizione è stata corretta con la versione V1.4.0 e con i rilasci successivi.

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

Breve sintesi dei comandi java e javaw .

Scopo

Gli strumenti java e javaw lanciano un'applicazione Java avviando Java Runtime Environment e caricando una classe specificata.

Il comando javaw è identico a java, se non per il fatto che javaw che non ha alcuna finestra di console associata. Usare javaw quando non si desidera che venga visualizzata una finestra di prompt dei 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 di classe o il nome del file jar vengono passati alla funzione principale.

I comandi java e javaw hanno la seguente sintassi:

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

Parametri

[opzioni]
Opzioni della riga dei comandi da passare all'ambiente di esecuzione.
<class>
Classe di avvio. La classe deve contenere un metodo principale().
<file.jar>
Il nome del file jar da richiamare. Utilizzata solo insieme all'opzione -jar . Il file jar nominato deve contenere file di classe e di risorsa per l'applicazione, insieme alla classe di avvio indicata nell'intestazione manifest Main-Class.
[argomenti ...]
Argomenti della riga dei comandi da passare alla funzione principale() della classe di avvio.

Come ottenere 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. Digitare il seguente comando:
    java -version
    Visualizzerete informazioni similari a:
    java version "1.6.0-internal" Java(TM) SE Runtime Environment (build 20070227_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20070226_11758 (JIT abilitato) J9VM - 20070226_11758_lHdSMR JIT  - dev_20070215_1800 GC   - 20070208_AA)
    Le date e versione esatte di generazione cambieranno.

| |

È 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:

|
...
|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 variano per ogni file jar |e si trovano nelle proprietà Implementation-Version e Build-Level |nel manifesto del file jar .

Specifiche delle opzioni e proprietà di sistema Java

È possibile specificare le opzioni e le proprietà di sistema Java sulla Java riga dei comandi usando un file opzioni o una variabile d'ambiente.

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

  1. Specificare l'opzione o la proprietà sulla riga dei comandi. Ad esempio:
    java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
  2. Creare un file che contiene le opzioni e specificarlo sulla riga dei comandi utilizzando -Xoptionsfile=<file>.
  3. Creare una variabile d'ambiente denominata IBM_JAVA_OPTIONS che contiene 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 per esempio se si specifica:

java -Xint -Xjit myClass

L'opzione -Xjit ha la precedenza.

Opzioni standard

Le definizioni per le opzioni standard.

-agentlib:<libname>[=<options>]
Carica la libreria dell'agente nativo <libname>; ad esempio -agentlib:hprof. Per ulteriori informazioni specificare -agentlib:jdwp=help e -agentlib:hprof=help sulla riga dei comandi.
-agentpath:libname[=<options>]
Carica un libreria dell'agente nativo con il nome completo del percorso.
-cp <directory e file zip o jar separati da ;>
Imposta il percorso di ricerca per risorse e classi dell'applicazione. Se -classpath e -cp non vengono usati e la variabile d'ambiente CLASSPATH non è impostata, il percorso di classe predefinito è sulla directory corrente (.).
-classpath <directory e file zip o jar separati da ;>
Imposta il percorso di ricerca per risorse e classi dell'applicazione. Se -classpath e -cp non vengono usati e la variabile d'ambiente CLASSPATH non è impostata, il percorso di classe predefinito è sulla directory corrente (.).
-D<property name>=<value>
Imposta una proprietà di sistema.
-help o -?
Visualizza le informazioni relative all'utilizzo.
-javaagent:<jarpath>[=<options>]
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:<option>
Abilita l'output dettagliato. Le opzioni possibili sono:
class
Scrive una voce in stderr per ciascuna classe caricata.
gc
Scrive informazioni dettagliate sulla raccolta dei dati obsoleti in stderr. Usare -Xverbosegclog per controllare l'output. Consultare il Manuale per la diagnostica per ulteriori informazioni.
jni
Scrive in stderr informazioni che descrivono i servizi della JNI richiamati dall'applicazione e la JVM.
sizes
Scrive in stderr informazioni che descrivono le impostazioni di utilizzo della memoria attiva.
stack
Scrive in stderr informazioni sull'uso dello stack in Java e C per ogni thread.
-version
Stampa la versione del prodotto.
-version:<value>
Richiede l'esecuzione della 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 .

Per eseguire tale operazione usare l'opzione della riga dei comandi -Xargencoding .

-Xargencoding
Utilizzo della codifica degli argomenti. Per specificare un carattere Unicode, utilizzare sequenze di escape nel formato \u####, dove # è una cifra esadecimale (da 0 a 9, da A a F).
-Xargencoding:utf8
Utilizzo della codifica UTF8.
-Xargencoding:latin
Utilizzo della codifica ISO8859_1.

Per 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 tradotti. Tali messaggi differiscono in base alla localizzazione 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 da 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.

Esecuzione di applicazioni Java con le tecnologie native assistite

Sun fornisce Java Access Bridge per dare alle tecnologie assistite Windows native come gli screen reader, l'accesso al supporto Java Accessibility in applicazioni Java . Tali tecnologie assistite Windows native devono supportare le chiamate verso Java Access Bridge.

Java Access Bridge disponibile della Sun comprende un programma di installazione, che colloca cinque file nelle directory appropriate: access-bridge.jar, jaccess.jar, accessibility.properties, JavaAccessBridge.dll e WindowsAccessBridge.dll. IBM invia una copia di jaccess.jar nella directory appropriata per utilizzarlo con JawBridge.

Se è stato già abilitato IBM Accessibility Bridge (JawBridge), che consente a Windows 2000 Magnifier di funzionare con applicazioni Swing, e si desidera abilitare JawBridge contemporaneamente a Java Access Bridge, modificare la riga nel file accessibility.properties in modo che si legga:

assistive_technologies=com.sun.java.accessibility.AccessBridge,JawBridge

Disattivare la riga immettendo il carattere # al suo inizio per disattivare entrambi i bridge. Questo sito Web indica come scaricare Java Access Bridge:

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

Compilatore JIT (Just-In-Time)

Il compilatore IBM JIT (Just-In-Time) genera dinamicamente il codice macchina per le sequenze di bytecode usate frequentemente nelle applicazioni e applet Java mentre sono in esecuzione. Il compilatore JIT v6 fornisce nuove ottimizzazioni come risultato della 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 negli strumenti 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 misura temporanea; JIT è richiesto per ottimizzare le prestazioni.

Per ulteriori informazioni su JIT, consultare il Manuale per la diagnostica.

Come disabilitare JIT

JIT può essere disabilitato in molti modi diversi. Entrambe le opzioni della riga dei comandi sovrascrivono la variabile d'ambiente JAVA_COMPILER.

Spegnere il JIT è una misura temporanea che può aiutare a isolare i problemi quando si effettua il debug delle applicazioni Java .

Come abilitare JIT

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

Come determinare se JIT è abilitato

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

Eseguire il programma di avvio java con l'opzione -version . Immettere quanto segue a 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.

Specifica del criterio per la 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 di Dati Obsoleti riceve una richiesta di memorizzazione, la memoria inutilizzata nell'heap viene impostata a parte in un processo chiamato "allocazione". Il Raccoglitore di Dati Obsoleti controlla inoltre le aree di memoria che non vengono più consultate e le rilascia per un nuovo uso. Questo processo è noto come "raccolta".

La fase di raccolta può partire in seguito ad un errore di allocazione della memoria, il che si verifica quando non viene lasciato spazio per una richiesta di memorizzazione, o in seguito a una esplicita chiamata System.gc() .

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

Per informazioni più dettagliate consultare il Manuale per la diagnostica.

Opzioni di Raccolta dei dati obsoleti

Le opzioni -Xgcpolicy controllano il comportamento del Raccoglitore di Dati Obsoleti. Bilanciano la velocità dell'applicazione e del sistema in generale, e i tempi di pausa determinati dalla raccolta di dati obsoleti.

Il formato dell'opzione ed i suoi valori sono:

-Xgcpolicy:optthruput
(Valore predefinito e raccomandato.) Dà alle applicazioni una velocità molto alta, ma comporta pause occasionali.
-Xgcpolicy:optavgpause
Riduce il tempo impiegato nella pause di raccolta dati obsoleti e limita l'effetto dell'incremento della dimensione degli heap 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 simultanea e generazionale per ridurre il tempo impiegato nelle pause della raccolta 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 Programma di raccolta 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

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

L'opzione della riga dei 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 utilizzato molto tempo per identificare gli oggetti di lunga durata che non possono essere raccolti. Se la raccolta dei dati obsoleti si concentra solo sugli oggetti che sono di solito riciclabili, si possono ridurre ulteriormente i tempi di pausa per alcune applicazioni. La GC (raccolta dati) generazionale riduce i tempi di pausa dividendo l'heap 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, alla fine vengono promossi all'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

Se un heap Java è quasi pieno, e ci sono pochi dati obsoleti da eliminare, è possibile che le richieste per nuovi oggetti non siano soddisfatte rapidamente perché 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 produce un file Javadump da utilizzare durante la diagnostica. In tali situazioni si raccomanda di aumentare la dimensione dell'heap usando l'opzione -Xmx o 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 hanno impostato l'Euro come valuta predefinita per i paesi che fanno parte 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 vecchia valuta nazionale specificare -Duser.variant=PREEURO sulla riga dei comandi Java .

Se si utilizza la localizzazione GB, danese o svedese e si desidera usare l'Euro, specificare -Duser.variant=EURO sulla riga dei comandi Java .

| | |

Utilizzo di metodi di immissione per indiano e thai

|
|

I metodi di immissione per indiano e thai non sono disponibili come predefiniti a partire dalla |Versione 6.0. Per utilizzare i metodi di immissione per indiano e thai è necessario aggiungerne manualmente i file jar |nel percorso delle estensioni Java.

|

Nella Versione 5.0 i file jar del metodo di immissione erano |contenuti nella directory jre\lib\ext |e venivano caricati automaticamente nella JVM. Nella Versione 6, i file jar del metodo di immissione |sono contenuti nella directory jre\lib\im |e devono essere aggiunti manualmente al percorso delle estensioni Java per abilitare i metodi di immissione per |indiano e thai. A questo scopo si possono utilizzare i seguenti metodi:

| |

|

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

Utilizzo di SDK per sviluppare le 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.

| | |

Utilizzo di 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 veniva utilizzato come predefinito.

| |

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 viene utilizzato come predefinito. 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 di processori XML |viene effettuata tramite fornitori di servizi. Quando si utilizza un factory |finder, Java cerca nelle seguenti posizioni per vedere quale fornitore di servizi utilizzare: |

|
    |
  1. La proprietà di sistema che ha lo stesso nome del fornitore di servizi.
  2. |
  3. Solo per XMLEventFactory, XMLInputFactory, |e XMLOutputFactory. Il valore del fornitore di servizio nel file C:\Program Files\IBM\Java60\jre\lib\stax.properties.
  4. |
  5. Per altre factory. Il valore del fornitore di servizi nel file C:\Program Files\IBM\Java60\jre\lib\jaxp.properties.
  6. |
  7. I contenuti del file META-INF\servizi\<service.provider>
  8. |
  9. Il fornitore di servizi 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 usato org.apache.xerces.jaxp.SAXParserFactoryImpl dalla |libreria XML4J. |
|
javax.xml.parsers.DocumentBuilderFactory
|
Seleziona il generatore di documenti. Per impostazione predefinita viene usato org.apache.xerces.jaxp.DocumentBuilderFactoryImpl dalla |libreria XML4J. |
|
javax.xml.datatype.DatatypeFactory
|
Seleziona la factory 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
|
Utilizzo del compilatore XL TXE-J. Questo è il comportamento predefinito. |
|
org.apache.xalan.processor.TransformerFactoryImpl
|
Utilizzo dell'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 usato 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. Usare com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl quando si imposta il provider di servizio javax.xml.transform.TransformerFactory .
  2. |
  3. Rigenerare i file delle classi generate dal compilatore XSLT4J. XL TXE-J non può eseguire file di classi generate dal compilatore XSLT4J.
  4. |
  5. È possibile che alcuni metodi generati dal compilatore superano 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'.". Si possono usare le classi compilate, ma è possibile ottenere una migliore prestazione controllando manualmente lo split limit.
    • |
    • 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 di transformer factory http://www.ibm.com/xmlns/prod/xltxe-j/split-limit quando si usano il transformer factory. Lo split limit può essere compreso tra 100 e 2000. Quando lo split limit viene impostato manualmente, per ottenere la migliore prestazione usare lo split limit più elevato possibile.
  6. |
  7. XL TXE-J potrebbe richiedere più memoria rispetto al compilatore XSLT4J. Se si sta esaurendo la memoria o sembra che le prestazioni siano rallentate, aumentare la dimensione dell'heap usando l'opzione -Xmx .
  8. |
  9. Migrare l'applicazione per usare le nuove chiavi di attributo. Le vecchie chiavi di attributo della transformer factory sono obsolete. I vecchi nomi saranno accettati con un 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 Obsoleto 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 queste 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 facoltativocreateXMLStreamReader(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 comparazione delle caratteristiche

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tabella 6. Confronto tra le caratteristiche dell'interprete XSLT4J, del compilatore XSLT4J, e del compilatore XL TXE-J.
Caratteristica 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
attributo translet-name N/D Sì (con nuovo nome)
attributo destination-directory N/D Sì (con nuovo nome)
attributo package-name N/D Sì (con nuovo nome)
attributo jar-name N/D Sì (con nuovo nome)
attributo generate-translet N/D Sì (con nuovo nome)
attributo auto-translet N/D Sì (con nuovo nome)
attributo use-classpath N/D Sì (con nuovo nome)
attributo enable-inlining No No (obsoleto in TL TXE-J)
attributo indent-number No Sì (con nuovo nome)
attributo debug No Sì (con nuovo nome)
estensioni Java Sì (solo sintassi abbreviata, costruzioni xalan:component/xalan:script |non supportate)
estensioni JavaScript No No
Elementi estensione No No
funzioni estensione EXSLT Sì (escluse le dinamiche) Sì (escluse le dinamiche)
estensione redirect Sì (escluso redirect:open e redirect:close)
estensione output No
estensione nodeset
funzioni estensione NodeInfo No No
estensione libreria SQL No No
estensione pipeDocument No No
estensione valutazione No No
estensione 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 provider di servizio org.apache.xalan.xsltc.dom.XSLTCDTMManager . Se, invece, si utilizza StreamSource il compilatore |passa a un parser XML con prestazioni elevate.

|

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 precedente di Xerces (antecedente alla 2.0) o Xalan (antecedente alla 2.3) nell'override approvato, si potrebbe avere una NullPointerException quando si lancia l'applicazione. Tale eccezione si verifica perché tali versioni precedenti non gestiscono il file jaxp.properties correttamente.

|

|

Per evitare questa situazione, usare una delle seguenti soluzioni alternative: |

|

Esecuzione del debug nelle applicazioni Java

Per eseguire il debug dei programmi Java , è possibile usare l'applicazione JDB (Java Debugger) o altri programmi di debug che comunicano tramite JPDA (Java Platform Debugger Architecture) fornito da SDK per Windows.

Ulteriori informazioni sulla diagnosi di problemi nell'uso di Java possono essere trovati nel Manuale per la diagnostica.

JDB (Java Debugger)

JDB (Java Debugger) è incluso in SDK per Windows. Il programma di debug è richiamato dal comando jdb; si collega alla JVM utilizzando JPDA.

Per eseguire il debug di un'applicazione Java:

  1. Avviare la JVM con le seguenti opzioni:
    java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<port> <class>
    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 <port>
    Il programma di debug si collega alla JVM, ed è ora possibile emettere una gamma di comandi per esaminare e controllare l'applicazione Java; per esempio, digitare run per consentire l'esecuzione dell'applicazione Java.

Per ulteriori informazioni sulle opzioni JDB, digitare:

jdb -help

Per ulteriori informazioni sui comandi JDB:

  1. Immettere jdb
  2. Alla richiesta jdb, digitare help

È inoltre possibile usare JDB per effettuare il debug delle applicazioni Java eseguite su computer remoti. JPDA usa un socket TCP/IP per collegarsi alla JVM remota.

  1. Avviare la JVM con le seguenti opzioni:
    java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<port> <class>
    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=<port>

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

Per ulteriori informazioni su JDB e JPDA e il loro utilizzo, consultare i siti Web:

Come determinare se l'applicazione viene eseguita da una JVM 32 bit o a 64 bit

Alcune applicazioni Java devono essere in grado di determinare se sono eseguite su una JVM 32 bit o a 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 usando la chiamata:

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

Modalità in cui la JVM elabora i segnali

Quando viene generato un segnale che possa essere di interesse per JVM, viene richiamato un programma di gestione segnali. Tale gestore di segnali determina se è stato invocato per un thread Java o non-Java.

Se il segnale riguarda un thread Java, la JVM prende il controllo del gestore di segnali. Se è installato un gestore di applicazioni per questo segnale e non è stata specificata l'opzione della riga dei comandi -Xnosigchain, il gestore di applicazioni per questo segnale viene richiamato dopo che la JVM ha terminato l'elaborazione.

Se il segnale è 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. Altrimenti, se il segnale viene richiesto dalla JVM o dall'applicazione Java, il segnale viene ignorato oppure viene eseguita l'azione predefinita.

Dove un segnale viene generato esternamente (ad esempio quando si immette CTRL-BREAK), viene creato un nuovo thread per il gestore di 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 dei comandi -Xnosigchain, viene richiamato il gestore applicazioni per questo segnale.

Per i segnali di errore e eccezione, la JVM esegue quanto segue:

per informazioni sulla scrittura di un programma di avvio che specifichi gli hook sopra indicati, consultare: http://www.ibm.com/developerworks/java/library/i-signalhandling/. Questo elemento è stato scritto per Java V1.3.1, ma è valido anche per 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 dei segnali dell'applicazione per quel segnale
  2. Esegue tutti gli hook di chiusura dell'applicazione
  3. Richiama eventuali hook di uscita installati dall'applicazione.
  4. Esegue le necessarie pulizie della 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 causa la generazione di un Javadump.

Segnali usati da JVM

I tipi di segnale sono Interruzioni, e Controlli.

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

Eccezioni
Il sistema operativo emette in modo sincrono un segnale appropriato di eccezione ogniqualvolta si verifichi una condizione irreversibile.
Errori
JVM emette un SIGABRT se rileva una condizione per cui non si può effettuare un recupero.
Interruzioni
I segnali di interruzione vengono emessi in modo asincrono, al di fuori da un processo JVM. per richiedere una chiusura.
Controlli
Altri segnali usati da JVM per il controllo.

Tabella 7. Segnali usati 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. Come impostazione predefinita, ciò innesca un Javadump.

IBM JVM utilizza le gestione delle eccezioni strutturata e l'API SetConsoleCtrlHandler() . Queste vengono disabilitate con -Xrs. -Xnosigchain viene ignorato in Windows.

Usare l'opzione -Xrs (riduzione uso del segnale) per evitare che la JVM gestisca la maggior parte dei segnali. Per maggiori informazioni, consultare la pagina di 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 se richiede ancora la JVM.

Collegamento di un driver di codice nativo alla libreria per il concatenamento di segnali

Runtime Environment contiene il concatenamento dei segnali. Questa funzione consente a JVM di operare in modo più efficiente con il code nativo che installa i propri gestori di segnale.

Il concatenamento dei segnali consente ad un'applicazione di collegare e caricare la libreria condivisa jsig.dll prima di msvcrt.dll. La libreria jsig.dll assicura che le chiamate a signal() vengano intercettate in modo che i relativi gestori non sostituiscano i gestori di segnale della JVM. Al contrario, tali chiamate salvano i nuovi gestori di segnale o li concatenano 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 inoltre nasconde all'applicazione i gestori di segnale della JVM. 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

I 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 è specificato dalle librerie JSE (cioè v6). L'API interfaccia JNI non influisce sulla specifica della lingua implementata da JVM, le API delle librerie delle classi oppure qualsiasi altra area di azione di JVM. Per ulteriori informazioni, fare riferimento a 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 nelle prestazioni alle applicazioni che allocano molta memoria e che accedono ad essa frequentemente. I miglioramenti delle prestazioni delle pagine grandi sono principalmente causati dal numero ridotto di mancati riscontri nel TLB (Translation Lookaside Buffer). Il TLB mappa un intervallo più ampio di memoria virtuale e così effettua questo miglioramento.

Affinché JVM utilizzi pagine grandi, il sistema deve avere un numero adeguato di pagine grandi contigue disponibili. Se le pagine grandi non possono essere allocate, anche quando sono disponibili sufficienti pagine, è possibile che le pagine grandi non siano contigue.

Le allocazioni di pagine grandi avranno esito positivo soltanto se il criterio di amministrazione locale per l'utente della JVM è configurato in modo da consentire l'opzione "Lock pages in memory".

Supporto CORBA

La Piattaforma Java, Standard Edition (JSE) 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 (Specifiche Ufficiali per il supporto CORBA 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 di 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

I Portable Interceptors sono degli hook posti in ORB che possono essere usati dai servizi ORB per intercettare il normale flusso esecutivo 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 un parametro ORBInitialPort, è cambiata da 900 a 2809, che è il numero di porta registrato con IANA (Internet Assigned Number Authority) per il Servizio 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 ugualmente e non hanno bisogno di essere ricompilati.

ORB supporta i parametri -ORBInitRef e -ORBDefaultInitRef definiti dalla specifica di Interoperable Naming Service, e l'operazione ORB::string_to_object adesso supporta i formati di stringa ObjectURL (corbaloc: e corbaname:) definiti dalla specifica di Interoperable Naming Service.

OMG specifica un metodo ORB::register_initial_reference per registrare un servizio con Interoperable Naming Service. Tuttavia questo metodo non è disponibile in Sun Java Core API in Versione 6. I programmi che hanno bisogno di registrare un servizio nella versione corrente devono richiamare questo metodo nella classe di implementazione ORB interna IBM . Per 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. Tale meccanismo è temporaneo e non è compatibile con le versioni future o portabile su ORB 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à di traccia

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

Esempio di traccia ORB

Ad esempio, per tracciare gli eventi e i messaggi formattati GIOP, digitare:

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 vengono riportati gli errori gravi. Se viene generato un file di output del debug, esaminarlo per verificare il problema. Per esempio, il server potrebbe essersi interrotto senza eseguire un ORB.shutdown().

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

Proprietà di sistema per ottimizzare ORB

L'ORB può essere ottimizzato per lavorare bene in una rete specifica. Di seguito si descrivono le proprietà richieste per l'ottimizzazione di ORB.

com.ibm.CORBA.FragmentSize=<size in bytes>
Usato per controllare la frammentazione GIOP 1.2. La dimensione predefinita è di 1024 byte.

Per disattivare la frammentazione impostare la dimensione del frammento su 0 byte:

java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
com.ibm.CORBA.RequestTimeout=<time in seconds>
Imposta il tempo massimo di attesa per una richiesta CORBA. Per impostazione predefinita ORB attende indefinitamente. Non impostare il timeout su un valore troppo basso, altrimenti le connessioni potrebbero terminare inutilmente.
com.ibm.CORBA.LocateRequestTimeout=<time in seconds>
Imposta il tempo massimo di attesa per una LocateRequest CORBA. Per impostazione predefinita ORB attende indefinitamente.
com.ibm.CORBA.ListenerPort=<port number>
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, inizia solo quando viene richiesto.

Autorizzazioni di sicurezza Java per l'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 risolvi
org.omg.CORBA.ORB connect ajava.net.SocketPermission ascolta
org.omg.CORBA.ORB resolve_initial_references java.net.SocketPermission connetti
org.omg.CORBA. portable.ObjectImpl _is_a java.net.SocketPermission connetti
org.omg.CORBA. portable.ObjectImpl _non_existent java.net.SocketPermission connetti
org.omg.CORBA. portable.ObjectImpl OutputStream _request (Stringa, booleano) java.net.SocketPermission connetti
org.omg.CORBA. portable.ObjectImpl _get_interface_def java.net.SocketPermission connetti
org.omg.CORBA. Request invoke java.net.SocketPermission connetti
org.omg.CORBA. Request send_deferred java.net.SocketPermission connetti
org.omg.CORBA. Request send_oneway java.net.SocketPermission connetti
javax.rmi. PortableRemoteObject narrow java.net.SocketPermission connetti

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 di fare riferimento direttamente alle classi di implementazione. Per la portabilità, fare riferimento alle classi API di CORBA API e non all'implementazione. Questi valori potrebbero essere modificati nei prossimi rilasci.

RMI 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), implementato in Java o in un altro linguaggio di programmazione.

È 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 alcuna impostazione che è possibile utilizzare per limitare il numero di thread nel pool delle connessioni.

BigDecimal migliorato

Da Java 5.0, la classe IBM 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 utilizzi java.math.BigDecimal.

La nuova java.math.BigDecimal utilizza gli stessi metodi di entrambe le precedenti java.math.BigDecimal e com.ibm.math.BigDecimal. Il codice esistente che utilizza java.math.BigDecimal continua a lavorare correttamente. Le due classi non serializzano.

Per migrare il codice Java esistente in modo che usi la classe java.math.BigDecimal , cambiare l'istruzione di importazione all'inizio del file .java da: import com.ibm.math.*; a import java.math.*;.

Plug-in, Applet Viewer e Web Start

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

Utilizzo di Java Plug-in

Java Plug-in è un plug-in del browser web. Per eseguire gli applet nel browser, si utilizza Java Plug-in.

È necessario consentire agli applet di terminare il caricamento, in modo da evitare che il browser si blocchi. Ad esempio, se si utilizza il pulsante Indietro e quindi quello Avanti mentre si sta caricando un'applet, è possibile che le pagine HTML non possano essere caricate.

Java Plug-in è documentato da Sun in: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.

Browser supportati

Il plug-in Java supporta Internet Explorer, Netscape, Mozilla, e Mozilla Firefox.

Tabella 9. Browser supportati dal plug-in Java
Browser Versioni supportate
Internet Explorer 6.0 SP1, 7.0
Netscape (Non supportato su Windows Vista) 7.2
Mozilla (Non supportato su Windows Vista) 1.7, 1.8
Firefox 2.0

Sono supportati anche rilasci minori successivi del browser.

Internet Explorer 5.01, il browser predefinito su Windows 2000, non è supportato.

Supporto SSV (Secure Static Versioning)

Static versioning consente alle applet di richiedere di essere eseguite con una specifica versione della JVM. Poiché tale capacità consente alle applicazioni anche di sfruttare vecchie vulnerabilità nella sicurezza di sistemi che sono stati aggiornati in una nuova JVM, SSV (Secure Static Versioning) viene ora utilizzato con Internet Explorer.

Per impostazione predefinita tutte le applet vengono eseguite con l'ultima JVM installata. Per disabilitare SSV, impostare la seguente chiave di registro a 0:

HKEY_LOCAL_MACHINE\Software\IBM\Java Deployment\Policy\EnableSecureStaticVersioning

Se la chiave di registro non è presente, SSV viene abilitato.

SSV non funziona se le estensioni dei browser di terze parti sono disabilitate su Internet Explorer. Per abilitare le estensioni dei browser di terze parti:

  1. Aprire Internet Explorer.
  2. Fare clic su Strumenti -> Opzioni Internet.
  3. Fare clic sulla tabella Avanzate .
  4. Selezionare la casella di controllo Abilita estensioni dei browser di terze parti .

Se le estensioni dei browser di terze parti vengono disabilitate dopo l'uso di SSV, SSV continuerà a funzionare.

Per dare protezione per i browser Mozilla e Firefox, il Plug-in di Internet Explorer rimuoverà automaticamente tutti i Plug-in Java dalle directory dei Plug-in Mozilla e Firefox. Ciò avviene ogni volta che viene eseguita un'applet con Internet Explorer.

Per installare di nuovo Java Plug-in per Mozilla o Firefox, utilizzare il Pannello di Controllo Java.

Supporto DOM (Document Object Model) comune

A causa di limitazioni in alcuni browser, potrebbe non essere possibile implementare tutte le funzioni del pacchetto org.w3c.dom.html .

Si verificherà uno dei seguenti errori:

Utilizzo dei parametri DBCS

Java Plug-in supporta i caratteri a doppio byte(ad esempio il cinese tradizionale BIG-5, coreano, giapponese) come parametri per le tag <APPLET>, <OBJECT>, e <EMBED>. È necessario selezionare la codifica di carattere corretta per il proprio documento HTML in modo che Java Plug-in possa effettuare l'analisi sintattica del parametro.

Specificare la codifica dei caratteri per il documento HTML utilizzando la tag <META> nella sezione <HEAD> come di seguito:

<meta http-equiv="Content-Type" content="text/html; charset=big5">

Questo esempio indica al browser di utilizzare la codifica caratteri Cinese BIG-5 per l'analisi sintattica del file HTML.

Operazioni con le 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, digitare:

   appletviewer <name>

dove <name> è uno dei seguenti:

Per esempio, per richiamare l'Applet Viewer su un file HTML che chiama un'applet, digitare su una richiesta comandi:

appletviewer <demo>\GraphLayout\example1.html

Dove la <demo> viene sostituito dal percorso completo in cui il pacchetto della demo è stato decompresso.

Per richiamare Applet Viewer su una pagina web, digitare in 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 dall'Applet Viewer non è codificato come predefinito del sistema, potrebbe verificarsi un'eccezione I/O. Per evitare l'eccezione, usare l'opzione -encoding quando si esegue appletviewer. Ad esempio:

appletviewer -encoding JISAutoDetect sample.html

CLSID unici

Un insieme unico di CLSID è stato aggiunto alla JVM IBM dalla Versione 6.

I nuovi CLSID sono i seguenti:

1ACECAFE-0016-0000-0000-ABCDEFFEDCBA
1ACECAFE-0016-0000-0000-ABCDEFFEDCBB
1ACECAFE-0016-0000-0000-ABCDEFFEDCBC

Si può fare riferimento ai CLSID sopramenzionati nella tag OBJECT per le vostre applet.

Inoltre, per motivi di compatibilità, sono supportati anche i seguenti CLSID già esistenti:

CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBB
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBC

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 trovano nel sito web della Sun: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.

Utilizzo di Web Start

Java Web Start è utilizzato per l'esecuzione di applicazioni Java .

Web Start consente agli utenti di lanciare e gestire le applicazioni direttamente dal Web. Le applicazioni vengono memorizzate nella cache per ridurre al minimo i tempi di installazione. Le applicazioni vengono aggiornate automaticamente quando nuove versioni sono disponibili.

Web Start supporta questi java-vm-args documentati su http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources:

IBM Web Start supporta inoltre -Xgcpolicy per impostare i criteri della raccolta di dati obsoleti.

Per informazioni sui browser che supportano Web Start, consultare Browser supportati.

Per ulteriori informazioni su Web Start, consultare:

Per ulteriori informazioni sulla distribuzione di applicazioni, consultare:

Esecuzione di Web Start

Web Start può funzionare da una pagina web o da riga comandi. Le applicazioni Web Start vengono memorizzate nella cache delle applicazioni Java.

Web Start può essere richiamato in diversi modi.

WebStart Secure Static Versioning

Static versioning consente alle applicazioni Web Start di richiedere di essere eseguiti da una specifica versione della JVM. Poiché tale capacità consente alle applicazioni anche di sfruttare vecchie vulnerabilità nella sicurezza di sistemi che sono stati aggiornati in una nuova JVM, SSV (Secure Static Versioning) viene ora utilizzato come predefinito.

Con SSV, l'utente sarà avvisato prima di eseguire qualsiasi applicazione Web Start non firmata che richieda l'utilizzo di una specifica JVM. Le applicazioni firmate e le applicazioni che richiedono l'ultima versione della JVM sono eseguite normalmente.

La SSV può essere disattivata impostando la proprietà deployment.javaws.ssv.enabled nel deployment.properties a false.

Invio di applicazioni Java

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

Quando si invia un'applicazione Java, il pacchetto software probabilmente è formato dalla parti seguenti:

Per eseguire l'applicazione, è necessario Runtime Environment per Windows. Il software SDK per Windows contiene un Runtime Environment. Tuttavia, non si può supporre che gli utenti abbiano installato il software SDK per Windows .

La licenza software SDK per Windows non consente di ridistribuire alcun file di SDK con l'applicazione. È necessario assicurarsi che una versione su licenza di SDK per Windows sia installata sulla macchina di destinazione.

Condivisione di dati delle classi tra 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 di memoria quando una cache è condivisa da più di una JVM. 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 delle classi

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 delle classi

Abilitare la condivisione dei dati delle classi usando l'opzione -Xshareclasses quando si avvia una JVM. La JVM si collegherà ad una cache esistente oppure creerà una nuova cache se non ne esiste una.

Tutte le classi 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 è 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 maggiori informazioni.

Aggiornamento dinamico della cache

Poiché la cache delle classi condivise permane oltre la durata di qualsiasi JVM, la cache viene aggiornata in modo dinamico per riflettere tutte le modifiche che potrebbero essere state apportate ai JAR o alle classi nel file system. 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 da quelle della 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 solo ad una cache contemporaneamente.

È 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 usare -Xshareclasses:help per visualizzare un elenco di 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<size>
Imposta il numero massimo di byte nella cache che possono essere utilizzati per i dati AOT. Utilizzare tale opzione per assicurarsi che ci sia una determinata quantità di spazio della cache disponibile per dati non-AOT. Come impostazione predefinita il limite massimo per i dati AOT è la quantità di spazio libero nella cache. Il valore di tale opzione non deve essere minore del valore di -Xscminaot e non deve essere maggiore del valore di -Xscmx.
-Xscminaot<size>
Imposta il numero massimo di byte nella cache che possono essere utilizzati per i dati AOT. Come impostazione predefinita non viene riservato alcuno spazio ai dati AOT, anche se i dati AOT vengono scritti nella cache fino a quando essa è piena o il limite -Xscmaxaot viene raggiunto. Il valore di tale opzione non deve superare il valore di -Xscmx o-Xscmaxaot. Il valore di -Xscminaot dovrebbe sempre essere molto inferiore alla dimensione totale della cache, poiché i dati AOT possono essere creati soltanto per le classi della cache. Se il valore di -Xscminaot è uguale al valore di -Xscmx, non vengono memorizzati né i dati della classe, né di dati AOT; questo perché è necessario che i dati AOT siano associati con una classe nella cache.
-Xscmx<size>
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. Si può scoprire il valore della dimensione utilizzata aggiungendo -verbose:sizes come argomento della riga dei comandi. La dimensione minima della cache è 4 KB. Inoltre, la dimensione massima della cache dipende dalla piattaforma. (Consultare Limiti di dimensioni della cache.)
-Xshareclasses:<suboption>[,<suboption>...]
Abilita la condivisione di classi. 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 della VM. È possibile combinare più opzioni secondarie, separate da virgole, ma i programmi di utilità della cache si escludono a vicenda. Quando si eseguono utilità di cache, è previsto il messaggio "Impossibile creare la virtual machine Java " . Le utilità di cache non creano la 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 "incompatibile".

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

help
Elenca tutte le opzioni secondarie da riga comandi.
name=<name>
Collega una cache di un nome specificato, creando una cache se non esiste già. Usato anche per indicare quale cache deve essere modificata dalle utilità della cache, per esempio, distruggere. Utilizzare l'utilità listAllCaches per visualizzare quali cache con nome sono attualmente disponibili. Se non si specifica un nome, viene utilizzato il nome predefinito "sharedcc_%u" . %u nel nome della cache inserirà il nome utente attuale.
|cacheDir=<directory>
|Imposta la directory nella quale verranno letti e scritti i dati di cache. Come 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 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. Come 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
|Abilita un output dettagliato quando il codice AOT compilato viene trovato o memorizzato |nella cache. Il codice AOT viene generato euristicamente. Per una piccola applicazione |potrebbe non essere generato alcun codice AOT. È possibile disabilitare le operazioni di cache AOT mediante l'opzione secondaria noaot.
verboseIO
Fornisce un output dettagliato sull'attività di I/O della cache, elencando le informazioni sulle classi che vengono memorizzate e individuate. 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 classloader principali una classe prima di poterla caricare. È normale che vi siano molte richieste non riuscite; questo comportamento è previsto per la gerarchia dei classloader.
verboseHelper
Abilita l'output dettagliato per l'API Java Helper . Tale output mostra come l'API Helper è utilizzata dal ClassLoader.
silent
Disattiva tutti i messaggi di classe condivisi, inclusi i messaggi di errore.
nonfatal
Consente alla JVM di avviarsi anche se la condivisione dei dati di classe non riesce. 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=<modified context>
Viene utilizzata se è installato un agente JVMTI, che potrebbe modificare il bytecode durante il runtime. 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. L'opzione <modified context> è 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. Per esempio se si esegue HelloWorld con un contesto di modifica e quindi lo si esegue nuovamente con un diverso contesto di modifica, si potranno visualizzare tutte le classi memorizzate due volte nella cache. Consultare Modifiche bytecode al runtime per maggiori 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 specificatecacheDir e nonpersistent. È possibile distruggere una cache solo se sono spente tutte le JVM che la utilizzano, e se l'utente dispone di autorizzazioni sufficienti.
expire=<time in minutes>
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. Nei file system NTFS l'opzione expire è approssimata 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 che sono state aggiornate nel file system e che la cache ha quindi marchiato come "stale". Le classi stale non vengono eliminate dalla cache e possono essere riutilizzate. Consultare il Manuale per la diagnostica per ulteriori informazioni.
printAllStats (Opzione 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 ]
|Come 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. Come impostazione predefinita, l'intestazione della cache non è protetta perché ciò comporta una piccola riduzione delle prestazioni. Specificando "all" garantisce che tutte le pagine della |cache siano protette, incluso 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 |maggiori informazioni sul filtro delle classi condivise.
|cacheRetransformed
|Abilita la memorizzazione della classi 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 di classi, aggiungere -Xshareclasses[:name=<name>] alla riga dei 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 avviate contemporaneamente due o più JVM popoleranno tutte contemporaneamente la cache.

Per verificare che la cache sia stata creata, eseguire java -Xshareclasses:listAllCaches. Per verificare quante classi sono e quanti dati delle classi sono stati condivisi, eseguire java -Xshareclasses:[name=<name>],printStats. (Tali utilità possono essere eseguire con la JVM dell'applicazione terminata o in un'altra finestra comandi.)

Per ulteriori commenti sull'uso della cache mentre la JVM è in esecuzione, usare l'opzione secondaria verbose . Per esempio, java -Xshareclasses:[name=<name>],verbose.

Per visualizzare le classi caricate dalla cache oppure memorizzate nella cache, aggiungere -Xshareclasses:[name=<name>],verboseIO alla riga dei 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 (usando -Xscmx), eseguire l'applicazione e quindi utilizzare printStats per stabilire la quantità di dati delle classi 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à delle JVM ad essa connesse, pertanto è legittimo 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. Tutte le JVM che condividono la cache piena caricheranno quindi ogni classe ulteriore nella propria memoria di elaborazione. 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 dei dati delle classi è particolarmente utile su sistemi che utilizzano più di una JVM con codici simili; il sistema trae vantaggio dal consumo ridotto di memoria virtuale. Inoltre, è utile su sistemi che avviano e chiudono frequentemente delle JVM, che traggono vantaggio dal miglioramento del tempo di avvio.

Il sovraccarico per creare e popolare una nuova cache è minimo. Il consumo di tempo per l'avvio di una singola JVM solitamente tra 0 e 5% più basso paragonato a un sistema che non utilizza la condivisione dei dati delle classi, a seconda di quante classi vengono caricate. Il miglioramento del tempo di avvio di una JVM con la cache popolata è solitamente tra il 10% e il 40% paragonato a un sistema che non utilizza la condivisione dei dati delle classi, a seconda del sistema operativo e del numero di classi caricate. Più JVM in esecuzione contemporaneamente mostrano maggiori vantaggi nel tempo di avvio generale.

Le classi duplicate sono consolidate entro la cache delle classi condivise. Per esempio, la classe A caricata da myClasses.jar e la classe A caricata da myOtherClasses.jar (con contenuti identici) sono memorizzate nella cache una volta sola. L'utilità printAllStats mostra diverse voci per le classi duplicate, dove tutte le voci fanno riferimento alla stessa classe.

Quando si esegue l'applicazione con la condivisione di classi, è possibile utilizzare gli strumenti del sistema operativo per visualizzare la riduzione nel consumo di 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 dimensione teorica massima della cache è 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 viene limitata dai seguenti fattori:

Modifiche bytecode al runtime

Ogni JVM che utilizza un agente JVMTI (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 contesto modificato partiziona la cache così che tutte le JVM eseguite nello stesso contesto condividano una partizione.

Tale partizione consente alle JVM che non usano bytecode modificati di condividere una cache in modo sicuro con quelle che usano 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'uso di un contesto modificato con un agente JVMTI evita che ci sia bisogno di controlli aggiuntivi e quindi non ha effetti sulla prestazione. Un ClassLoader personalizzato che estende java.net.URLClassLoader e modifica il bytecode durante il caricamento senza usare JVMTI memorizza automaticamente quel bytecode modificato nella cache, ma la cache non considera il bytecode come modificato. Ogni altra VM che condivide quella cache carica le classi modificate. L'opzione secondaria modificata=<modification_context> può essere usata come con gli agenti JVMTI per partizionare il bytecode modificato in the cache. Se un ClassLoader personalizzato necessita di effettuare modifiche non prevedibile del tempo di carico alle classe, tale ClassLoader non deve tentare di usare la condivisione di dati delle classi.

Consultare il Manuale 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 sia a 64 bit, la condivisione dei dati delle classi non è consentita tra JVM a 32-bit e a 64 bit. L'opzione secondaria listAllCaches elenca le cache a 32-bit o a 64 bit, a seconda della modalità 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 si trovano nella 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 usato insieme alla condivisione dei dati delle classi e l'applicazione in esecuzione utilizza i propri class loader, a tali class loader devono essere garantite le autorizzazioni prima che possano condividere le classi.

Si possono aggiungere le autorizzazioni al file java.policy usando il nome di classe ClassLoader (sono consentiti i caratteri jolly) e "read", "write", o "read,write" per determinare l'accesso garantito. Ad esempio:

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

Se un ClassLoader non ha le autorizzazioni corrette gli viene impedito di 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'utilizzo 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 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 1284 Institute of Electrical and Electronics Engineers (IEEE) ed è supportata da sistemi con IBM Versione 6 Runtime Environment.

Usando l'API Java Communications, è 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-i386.zip, nella directory in cui è stato installato l'SDK o Runtime Environment. Se è stato installato nella directory predefinita si tratta di C:\Program Files\IBM\Java60\.
  2. Estrarre il file compresso. Java Communications API viene estratto nelle sottodirectory all'interno della directory esistente.
  3. |Copiare i file javacomm nelle directory |corrette all'interno del proprio SDK. | |
      |
    1. Copiare il file lib\win32com.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 dell'API Java Communications

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

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 l'API Java Communications

Quando si stampa con l'API Java Communications, potrebbe essere necessario selezionare "Alimentazione fogli", "Continua", o un'opzione simile sulla stampante.

Disinstallazione dell'API Java Communications

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 Java Communications API

E' possibile trovare trovare la documentazione 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

Punti di contatto per i servizi:

Se si ha diritto ai servizi per il codice del programma conforme a IBM Solutions Developer Program, contattare IBM Solutions Developer Program attraverso il normale metodo di accesso oppure tramite il 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 utili per le applicazioni Swing si trova in Swing Key Bindings alla pagina 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.

Accessibilità di Web Start

Dalla Versione 5.0, Java Web Start contiene diversi miglioramenti nell'accessibilità e nell'utilizzo, compreso un migliore supporto per gli screen reader e una navigazione da tastiera migliorata.

È possibile utilizzare la riga dei comandi solo per lanciare un'applicazione Java abilitata per Web Start. Per cambiare le opzioni delle preferenze, editare il file di configurazione Application Data\IBM\Java\Deployment\deployment.properties nella directory principale dell'utente. Prima di modificare questo file farne una copia di riserva. Non tutte le preferenze che si possono impostare in Java Application Cache Viewer sono disponibili nel file di configurazione.

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 la crittografia hardware è disponibile anche in 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. Se si sceglie di inviare un messaggio a IBM, si accetta che tutte le informazioni contenute nel messaggio, compresi i dati di feedback quali domande, commenti, suggerimenti o simili non saranno ritenute riservate e IBM non avrà alcun tipo di obbligo rispetto a tali informazioni e le potrà riprodurre, utilizzare, diffondere e distribuire a terzi senza alcun limite. Inoltre IBM potrà utilizzare tutte le idee, i concetti, il know-how o le tecniche contenute in tali informazioni per qualsiasi scopo, incluso, ma non soltanto, lo sviluppo, fabbricazione e commercializzazione di prodotti che incorporano tali informazioni.

Appendice A. Opzioni non standard

Le opzioni -X sotto elencate non sono standard e sono 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 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 prevede la ricerca delle classi di bootstrap e delle risorse nelle directory interne delle VM e nei 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 prevede la ricerca delle classi di bootstrap e delle risorse nelle directory interne e nei 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 degli indirizzari VM interni e dei file .jar.
|-Xcheck:classpath
|Mostra un messaggio di avviso se viene scoperto un errore nel percorso della classe, |ad esempio una directory o un file JAR mancanti.
-Xcheck:gc[:<scan options>][:<verify options>][:<misc options>]
Esegue ulteriori verifiche sulla raccolta di dati obsoleti. Per impostazione predefinita, non viene effettuata alcuna verifica. Consultare l'output di -Xcheck:gc:help per ulteriori informazioni.
-Xcheck:jni
Esegue un'ulteriore verifica per le funzioni JNI. Per impostazione predefinita, non viene effettuata alcuna verifica.
|-Xcheck:memory[:<option>]
Identifica perdite della memoria all'interno della JVM tramite controlli severi che fanno in modo che la JVM esca in caso di errore. Se non viene specificata alcuna opzione viene usata l'impostazione predefinita tutti. Consultare l'output di -Xcheck:memory:help o il Manuale per la diagnostica per ulteriori informazioni.
-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. Tale opzione è abilitata per impostazione predefinita.
-Xcodecache<size>
Imposta la dimensione dell'unità di cui i blocchi di memoria vengono allocati per memorizzare il codice nativo dei metodi Java compilati. Si può scegliere una dimensione appropriata per l'applicazione in esecuzione. Per impostazione predefinita essa viene selezionata internamente secondo l'architettura e la capacità del vostro 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<number>
Specifica il numero di thread a bassa priorità in secondo piano allegati per assistere i thread mutator nel contrassegno simultaneo. L'impostazione predefinita è 1.
-Xconcurrentlevel<number>
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 misurato e quindi quali allocazioni vengono tassate durante il contrassegno simultaneo. La tassa di allocazione viene applicata all'area selezionata. Se -Xconmeter:dynamic è specificato, il programma di raccolta determina in modo dinamico quale area misurare sulla base di quale area si è esaurita prima. Per impostazione predefinita, l'opzione è impostata su -Xconmeter:soa.
-Xdbg:<options>
Carica le librerie di debug per il supporto del debug remoto delle applicazioni. Consultare Esecuzione del debug nelle applicazioni Java per maggiori 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
Questa opzione disabilita l'attivazione di OutOfMemoryError se viene impiegato un tempo eccessivo nel GC. Per impostazione predefinita tale opzione è off.
-Xdisableexplicitgc
I segnali alla VM che chiama System.gc() non devono avere effetto. Per impostazione predefinita, le chiamate a System.gc() attivano una raccolta di dati obsoleti.
-Xdisablestringconstantgc
Questa opzione impedisce alle stringhe nella tabella interna delle stringhe di essere raccolte. Per impostazione predefinita, tale opzione è disabilitata.
-Xdisablejavadump
Disattiva la generazione di Javadump in caso di errori e segnali. Per impostazione predefinita, la generazione di Javadump è abilitata.
-Xenableexcessivegc
Se viene impiegato un tempo eccessivo in GC, questa opzione restituisce NULL per una richiesta di allocazione, e pertanto causa l'attivazione di un OutOfMemoryError. Questa azione si verifica solo quando l'heap è stato espanso completamente e GC impiega il 95% del tempo a disposizione. Questo è il comportamento predefinito.
-Xenableexplicitgc
Segnala alla VM che le chiamate a System.gc() dovrebbero innescare una raccolta di dati obsoleti. Questo è il comportamento predefinito.
-Xenablestringconstantgc
Abilita la raccolta delle stringhe nella tabella interna delle stringhe. Tale opzione è abilitata per impostazione predefinita.
-Xfuture
Attiva i controlli del formato classe file severi. Utilizzare questo segnalatore durante lo sviluppo del nuovo codice, poiché i controlli severi diventeranno predefiniti nei rilasci successivi. 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 maggiori informazioni.
-Xgcthreads<number of threads>
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<number>
Specifica il numero totale di pacchetti di lavoro disponibili nel raccoglitore globale. Se non specificata, il programma di raccolta alloca il numero di pacchetti basato sulla dimensione massima di heap.
-Xint
Fa in modo che JVM utilizzi solo l'interprete, disabilitando il compilatore Just-In-Time (JIT). Il compilatore JIT è abilitato per impostazione predefinita.
-Xiss<size>
Imposta la dimensione di stack dei thread Java iniziale. 2 KB perimpostazione predefinita. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
|-Xjarversion
|Consultare Come ottenere informazioni sulla versione.
-Xjit[:<suboption>,<suboption>...]
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 large object area (LOA). 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. Consultare anche -Xnoloa.
-Xloainitial<percentage>
<percentage> è compreso tra 0 e 0.95, che specifica la percentuale iniziale dello spazio di possesso attuale allocato nella large object area (LOA). Il valore predefinito è 0,05 o 5%.
-Xloamaximum<percentage>
<percentage> è compreso tra 0 e 0.95, che specifica la percentuale massima dello spazio di possesso attuale allocato nella large object area (LOA). Il valore predefinito è 0,5 o 50%.
-Xlp (Windows 2003)
Richiede alla JVM di allocare l'heap Java con pagine grandi. Se le pagine grandi non sono disponibili, la JVM non verrà avviata,e verrà visualizzato il messaggio di errore GC: la configurazione di sistema non supporta l'opzione --> '-Xlp'. Le pagine grandi sono supportate dai sistemi che eseguono Windows 2003, in cui il sistema operativo è impostato per l'utilizzo di pagine grandi. Per impostazione predefinita, le pagine grandi non vengono utilizzate. Consultare Configurazione dell'allocazione di memoria di pagine grandi.
-Xmaxe<size>
Imposta la quantità massima su cui il programma di raccolta dei dati obsoleti espanderà la memoria riservata. Di solito, il programma di raccolta dei dati obsoleti espande la memoria riservata quando la quantità di spazio libero è 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; per esempio -Xmaxe10M limita l'espansione a 10 MB. Per impostazione predefinita, non esiste alcuna dimensione di espansione massima.
-Xmaxf<percentage>
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 l'heap. Il valore predefinito è 0,6 (60%).
-Xmca<size>
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 individuare i valori che VM sta utilizzando.
-Xmco<size>
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 individuare i valori che VM sta utilizzando.
-Xmine<size>
Imposta la quantità minima per cui il programma di raccolta dei dati obsoleti espanderà l'heap. Di solito, il programma di raccolta dati obsoleti, espande l'heap in base alla quantità richiesta per ripristinare lo spazio libero al 30% (o la quantità specificata utilizzando -Xminf). L'opzione -Xmine imposta l'espansione perché sia almeno uguale al valore specificato; per esempio, -Xmine50M imposta la dimensione dell'espansione a un minimo di 50 MB. Per impostazione predefinita, l' espansione minima è di 1 Mb.
-Xminf<percentage>
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<size>
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 individuare i valori che VM sta utilizzando.
-Xmns<size>
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 cercherete di utilizzarla con -Xmn. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-Xmnx<size>
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 cercherete di utilizzarla con -Xmn. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-Xmo<size>
Imposta la dimensione iniziale e massima dell'heap precedente (di possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Equivalente all'impostazione di -Xmos e -Xmox. Se si imposta -Xmos oppure -Xmox, non è possibile impostare -Xmo. Se si cerca di impostare -Xmo con -Xmos oppure con -Xmox, VM non verrà avviato e restituirà un errore. Per impostazione predefinita, -Xmo viene selezionato internamente in base alle caratteristiche del sistema. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-Xmoi<size>
Imposta la quantità di heap Java incrementata quando s i 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<size>
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 ritornerà un errore se cercherete di utilizzarla con -Xmo. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-Xmox<size>
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 ritornerà un errore se cercherete di utilizzarla con -Xmo. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-Xmr<size>
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 individuare i valori che VM sta utilizzando.
-Xmrx<size>
Imposta la massima dimensione di impostazione ricordata.
-Xms<size>
Imposta la dimensione iniziale dell'heap Java . Si può utilizzare inoltre -Xmo. L'impostazione predefinita viene selezionata internamente secondo la capacità del sistema. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-Xmso<size>
Imposta la dimensione dello stack C per i thread Java duplicati. Per impostazione predefinita, 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 individuare i valori che VM sta utilizzando.
-Xmx<size>
Imposta la dimensione massima dell'heap Java . Per impostazione predefinita questa opzione è selezionata internamente secondo la capacità del sistema. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-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 dalla 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. Il compilatore JIT è abilitato per impostazione predefinita.
-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. Consultare 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<size>
Imposta la dimensione di stack Java e di stack C per ogni 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>:<port>
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, la VM utilizza completamente i segnali del sistema operativo; per informazioni consultare Segnali usati da JVM.
-Xrun<library name>[:<options>]
Carica le librerie dell'helper. Per caricare più librerie, specificarle più volte nella riga comandi. Alcuni esempi di libreria sono:
-Xrunhprof[:help] | [:<option>=<value>, ...]
Esegue heap, CPU, profili di controllo. Per ulteriori informazioni, consultare il Manuale per la diagnostica.
-Xrunjdwp[:help] | [:<option>=< value>, ...]
Carica le librerie di debug per il supporto del debug remoto delle applicazioni. Consultare -Xdbg per ulteriori informazioni.
-Xrunjnichk[:help] | [:<option>=<value>, ...]
Sconsigliato, usare -Xcheck:jni.
-Xscmx<size>
Per informazioni dettagliate su -Xscmx, consultare Abilitazione e configurazione della condivisione dei dati delle classi.
-Xshareclasses:<options>
Per dettagli 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<number>
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<size>
Imposta la dimensione di stack Java massima per ogni thread. Per impostazione predefinita, questa opzione è impostata a 256 KB. Utilizzare l'opzione -verbose:sizes per individuare i valori che VM sta utilizzando.
-Xthr:<options>
Imposta le opzioni di thread.
-Xverbosegclog:<path to file>[X,Y]

Comporta che l'output della raccolta di dati obsoleti (GC) verbose 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 verbose viene indirizzato sul numero X di file, ciascuno contenente il numero Y di cicli gc valido per l'output GC verbose. Questi file hanno il formato nomefile1, nomefile2 e così via. Per impostazione predefinita non viene effettuato alcun log GC verbose.

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

-Xverify
Abilita il controllo classi severo per ciascuna classe caricata. Per impostazione predefinita, il controllo ristretto della classe ristretta viene disabilitato.
-Xverify:none
Disabilita il controllo classi severo. Per impostazione predefinita, il controllo ristretto della classe ristretta viene disabilitato.

Appendice B. Limiti noti

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

Problemi con i font nelle localizzazioni supportate

IBM SDK a 32 bit per Windows, v6 supporta le seguenti localizzazioni:

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

Utilizzo di socket con IPv6

IBM SDK a 32 bit per Windows, v6 supporta IPv6. Tuttavia, poiché il supporto IPv6 corrente in Windows non è dual-stack, SDK simula un comportamento dual-stack su un sistema abilitato IPv6. L'applicazione Java potrebbe utilizzare fino al doppio dei socket a causa della natura della simulazione. Per disabilitare questa simulazione è necessario disabilitare il supporto IPv6 in SDK impostando la proprietà del sistema java.net.preferIPv4Stack come true.

Tabella locale dello strumento di monitoraggio JConsole

Nello strumento JConsole IBM, la tabella Locale, che consente di connettersi ad altre Virtual Machine dello stesso sistema, non è disponibile. Non è inoltre supportata l'opzione pid della riga dei comandi. Si può usare invece la tabella Remote in JConsole per la connessione alla Virtual Machine che si vuole monitorare. In alternativa si può utilizzare l'opzione della riga dei comandi connection, specificando un host di localhost e un numero di porta. Quando si lancia l'applicazione da monitorare è necessario impostare le seguenti opzioni riga dei comandi:

-Dcom.sun.management.jmxremote.port=<value>
Specifica la porta a cui l'agente di gestione dovrebbe connettersi.
-Dcom.sun.management.jmxremote.authenticate=false
Disabilita l'autenticazione a meno che non sia stato creato un file nome utente.
-Dcom.sun.management.jmxremote.ssl=false
Disabilita la codifica SSL.

Il motore Rhino Javascript 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/.

IME (Input Method Editor)

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 inserisce del testo in un'Area di testo AWT mentre utilizza un IME (Input Method Editor), e quindi modifica la finestra dell'applicazione prima di eseguire il commit del testo, il commit del testo viene eseguito automaticamente.

Creazione lenta di coppie di chiavi DSA

La creazione di coppie di chiavi DSA di lunghezza insolita può richiedere molto tempo su macchine lente. Non interpretate il ritardo come un blocco, poiché il processo sarà completato se gli si concederà tempo a sufficienza. L'algoritmo di generazione delle chiavi DSA è 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 per il codice Windows NIO, portando al malfunzionamento di particolari operazioni. Ad esempio la chiamata del metodo Selector.open() può comportare un "java.io.IOException: Unable to establish loopback connection" con una causa di "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 la connessione, dopo ripetuti tentativi, non è ancora possibile, si verifica una 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 file handle

In Windows 2000 e XP, il valore predefinito del numero di file che si possono aprire contemporaneamente è troppo basso e provocherà problemi alle applicazioni che hanno un I/O intenso. Per correggere questo limite, modificare il file <windows>\system32\CONFIG.NT e impostare i seguenti valori:

files=200
buffers=60

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

Problemi con DirectDraw e il puntatore del mouse

In Windows 2000, con un'intensità di colore a 32 bit, il meccanismo DirectDraw di JVM non ridisegna l'area sottostante il puntatore del mouse. Il risultato è che appaiono riquadri grigi o neri sui menu dopo che il passaggio del mouse. Per risolvere il problema, è necessario disattivare Direct Draw (-Dsun.java2d.noddraw) oppure cambiare la risoluzione colori del video assegnando un altro valore, quale ad esempio 256 colori.

Problemi con la connessione NIO

La chiamata SocketChannel finishConnect() NIO può restituire true (il canale è connesso) oppure false (il processo di collegamento non è completato) oppure restituire un'eccezione. In Windows 2000, quando si utilizzano connessioni non bloccate, può essere restituito false anche dopo che una precedente chiamata Java select() implica che un canale è pronto per l'elaborazione.

Intervallo dello stack del thread principale

Non è possibile alterare l'intervallo dello stack del thread Java principale (noto anche come thread primordiale) durante l'esecuzione. Il thread principale ha una dimensione fissa di 256 KB, determinata come valore ottimale per le prestazioni. È possibile utilizzare l'opzione -Xss per modificare l'intervallo di stack solo sui thread diversi da quello principale. Non utilizzare il thread principale per calcoli ricorsivi pesanti perché il thread principale è più propenso all'overflow degli stack rispetto agli altri thread.

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 della lingua ceca

Per gli utenti cechi, si noti che il pannello di selezione della lingua di InstallShield offre una voce tradotta in un'installazione che al contrario non è tradotta. Tale limite è causato da InstallShield. La stringa viene richiamata dal sistema operativo basato sulla tabella codici. Poiché il polacco (per il quale è stata tradotta l'installazione) e il ceco hanno entrambi la tabella codici 1250, InstallShield tenta di richiamare un elenco di lingue dal sistema per entrambe le lingue, che risulta in questa stringa nell'elenco di lingue.

Cinese tradizionale e utilizzo del comando more

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

Modifiche agli accenti per utenti catalani

Per gli utenti catalani, utilizzare il carattere Lucida Console per evitare la visualizzazione errata delle lettere maiuscole accentate. Ciò riguarda soltanto gli utenti di Windows 2000.

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 della tabella codici Unicode Shift_JIS

Solamente utenti giapponesi

L'alias della tabella codici unicode "\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe" per Shift_JIS è stato rimosso. Se si utilizza tale tabella codici nelle vostre applicazioni, sostituirla con Shift_JIS.

Informazioni particolari

Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati Uniti d'America. IBM potrebbe non offrire i prodotti, i servizi o le funzioni trattate in questo documento in altri paesi. Consultare il rappresentante IBM locale per informazioni relative ai prodotti e ai servizi disponibili nella vostra area al momento.

Ogni riferimento a un prodotto, programma o servizio IBM, non significa né sottintende che possano essere usati soltanto tali prodotti, programmi o servizi IBM. 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 di IBM. Tuttavia, è responsabilità dell'utente valutare e verificare la possibilità di usare programmi, prodotti o servizi non IBM.

IBM potrebbe avere brevetti o domande di brevetto in corso relativamente a quanto trattato nel presente documento. 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:

Per richieste sulle licenze relative alle informazioni DBCS 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 informazioni vengono qui contenute vengono modificate periodicamente: le correzioni relative saranno incluse nelle nuove edizioni. 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 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 tali siti è a vostro rischio.

IBM potrebbe utilizzare o distribuire qualsiasi informazione voi forniate nel modo che ritiene più appropriato senza avere nessun obbligo nei vostri confronti.

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, sono pregati di contattare:

Queste informazioni possono essere rese disponibili secondo condizioni contrattuali appropriate, compreso, in alcuni casi, l'addebito di un canone.

Il programma su licenza descritto nel presente documento e tutto il materiale su licenza relativo ad esso sono forniti da IBM ai sensi del Customer Agreement di IBM dell'International Program License Agreement di IBM o altro accordo equivalente.

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 possono essere 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. IBM non ha verificato tali prodotti e non può garantire la precisione della prestazione, la compatibilità o altre questioni relative a prodotti non-IBM. Eventuali commenti relativi alle prestazioni dei prodotti non IBM devono essere indirizzati ai fornitori di tali prodotti.

Marchi

IBM, AIX, developerWorks, eServer, iSeries, MVS, POWER4, POWER5+, PowerPC, pSeries, System i, System p, System z, WebSphere, System z9, z/OS, e zSeries sono marchi o marchi registrati di International Business Machines Corporation negli Stati Uniti, in altre nazioni, o in entrambi.

Intel è un marchio della Intel Corporation negli Stati Uniti e/o in altre nazioni.

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.

Linux è un marchio della Linus Torvalds.

I nomi di altre società, prodotti e servizi potrebbero essere marchi di altre società.