Prima di utilizzare queste informazioni e il prodotto che riguardano leggere le informazioni in Informazioni particolari.
Questa edizione del Manuale per l'utente si riferisce a IBM SDK a 32-bit e Runtime Environment per Windows, Java Technology Edition, Versione 6, ed a tutti i rilasci successivi, modifiche, e Aggiornamenti di Servizio, se non indicato diversamente nelle nuove edizioni.
(C) Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Tutti i diritti riservati.
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.
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).
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.
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:
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.
Lista di classi e strumenti che si possono utilizzare con il Runtime Environment standard.
Un elenco di strumenti e di informazioni di riferimento inclusi nell'SDK standard.
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.
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à.
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.
È 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.
Utilizzare l'installazione presidiata per installare l'SDK oppure JRE su un singolo client.
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.
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.
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
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.
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
È 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.
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).
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:
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
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.
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:
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.
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.
È 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à.
Breve sintesi dei comandi java e javaw .
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.
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 ... ]
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.
java -versionVisualizzerete 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 .
È 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:
java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
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.
Le definizioni per le opzioni standard.
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 .
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.
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''%*'
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.
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.
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 .
set JAVA_COMPILER=NONEÈ possibile impostare in modo permanente JAVA_COMPILER utilizzando la GUI. Aprire il Pannello di Controllo, selezionare Sistema e sulla scheda Avanzate, selezionare Variabili d'ambiente.
java -Djava.compiler=NONE <class>
java -Xint < class>
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.
impostare JAVA_COMPILER=jitcÈ possibile impostare in modo permanente JAVA_COMPILER utilizzando la GUI. Aprire il Pannello di Controllo, selezionare Sistema e sulla scheda Avanzate, selezionare Variabili d'ambiente. Se la variabile d'ambiente JAVA_COMPILER è una stringa vuota, il JIT rimane disabilitato. Per disabilitare la variabile d'ambiente, nella richiesta comandi, digitare:
imposta JAVA_COMPILER=
java -Djava.compiler=jitc <class>
java -Xjit <class>
È 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.
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.
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:
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.
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.
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.
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 .
| | |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:
|java -Djava.ext.dirs=C:\Program Files\IBM\Java60\jre\lib\ext;C:\Program Files\IBM\Java60\jre\lib\im <class>
|
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.
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.
| | |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.
|L'SDK IBM per Java contiene le seguenti librerie XML.
|XML4J è un parser di convalida che fornisce supporto ai seguenti standard: |
|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 è 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.
|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: |
|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: |
|I seguenti fornitori di servizi controllano le librerie per l'elaborazione XML utilizzate da Java: |
|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:
|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 | |
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.
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.
Le caratteristiche StAX facoltative seguenti |non sono supportate da XL XP-J: |
|Le seguenti proprietà sono supportate |dall'implementazione javax.xml.stream.XMLInputFactory, |come descritto nel Javadoc XMLInputFactory.
| |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 | |Sì | |
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 | |Sì | |
javax.xml.stream.supportDTD | |No. Le DTD sono sempre supportate. Impostare il valore a false non ha nessun effetto. | |
javax.xml.stream.reporter | |Sì | |
javax.xml.stream.resolver | |Sì | |
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.
|Le seguenti proprietà |sono supportate dall'implementazione javax.xml.stream.XMLStreamReader, |come descritto nel JavadocXMLStreamReader.
| |Nome proprietà | |Supportate | |
---|---|
javax.xml.stream.entities | |Sì | |
javax.xml.stream.notations | |Sì | |
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.
|Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLOutputFactory, come descritto nel Javadoc XMLOutputFactory.
| |Nome proprietà | |Supportate | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sì | |
Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLStreamWriter, come descritto nel Javadoc XMLStreamWriter.
| |Nome proprietà | |Supportate | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sì | |
Le proprietà degli oggetti XMLStreamWriter sono di sola lettura.
| | |XL TXE-J è una libreria XSLT contenente l'interprete XSLT4J 2.7.8 e un compilatore XSLT.
Caratteristica | |Interprete XSLT4J (incluso) | |Compilatore XSLT4J (non incluso) | |Compilatore XL TXE-J (incluso) | |
---|---|---|---|
caratteristica http://javax.xml.transform.stream.StreamSource/feature | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.transform.stream.StreamResult/feature | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.transform.dom.DOMSource/feature | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.transform.dom.DOMResult/feature | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.transform.sax.SAXSource/feature | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.transform.sax.SAXResult/feature | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.transform.stax.StAXSource/feature | |Sì | |No | |Sì | |
caratteristica http://javax.xml.transform.stax.StAXResult/feature | |Sì | |No | |Sì | |
caratteristica http://javax.xml.transform.sax.SAXTransformerFactory/feature | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.transform.sax.SAXTransformerFactory/feature/xmlfilter | |Sì | |Sì | |Sì | |
caratteristica http://javax.xml.XMLConstants/feature/secure-processing | |Sì | |Sì | |Sì | |
attributo http://xml.apache.org/xalan/features/incremental | |Sì | |No | |No | |
attributo http://xml.apache.org/xalan/features/optimize | |Sì | |No | |No | |
attributo http://xml.apache.org/xalan/properties/source-location | |Sì | |No | |No | |
attributo translet-name | |N/D | |Sì | |Sì (con nuovo nome) | |
attributo destination-directory | |N/D | |Sì | |Sì (con nuovo nome) | |
attributo package-name | |N/D | |Sì | |Sì (con nuovo nome) | |
attributo jar-name | |N/D | |Sì | |Sì (con nuovo nome) | |
attributo generate-translet | |N/D | |Sì | |Sì (con nuovo nome) | |
attributo auto-translet | |N/D | |Sì | |Sì (con nuovo nome) | |
attributo use-classpath | |N/D | |Sì | |Sì (con nuovo nome) | |
attributo enable-inlining | |No | |Sì | |No (obsoleto in TL TXE-J) | |
attributo indent-number | |No | |Sì | |Sì (con nuovo nome) | |
attributo debug | |No | |Sì | |Sì (con nuovo nome) | |
estensioni Java | |Sì | |Sì (solo sintassi abbreviata, costruzioni xalan:component/xalan:script |non supportate) | ||
estensioni JavaScript | |Sì | |No | |No | |
Elementi estensione | |Sì | |No | |No | |
funzioni estensione EXSLT | |Sì | |Sì (escluse le dinamiche) | |Sì (escluse le dinamiche) | |
estensione redirect | |Sì | |Sì (escluso redirect:open e redirect:close) | |Sì | |
estensione output | |No | |Sì | |Sì | |
estensione nodeset | |Sì | |Sì | |Sì | |
funzioni estensione NodeInfo | |Sì | |No | |No | |
estensione libreria SQL | |Sì | |No | |No | |
estensione pipeDocument | |Sì | |No | |No | |
estensione valutazione | |Sì | |No | |No | |
estensione tokenize | |Sì | |No | |No | |
XML 1.1 | |Sì | |Sì | |Sì | |
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.
| |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: |
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
oppure
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
oppure
|set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
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) è 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:
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.
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:
È 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.
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.
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:
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");
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 segnali di interruzione, JVM immette inoltre una sequenza di chiusura controllata, ma questa volta viene trattata come una normale chiusura che:
La chiusura è identica a quella iniziata da una chiamata al metodo Java System.exit().
Altri segnali usati da JVM servono per controlli interni e non causano la chiusura. L'unico segnale di controllo di interesse è SIGBREAK, che causa la generazione di un Javadump.
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:
Nome Segnale | Tipo Segnale | Descrizione | Disabilitato da -Xrs |
---|---|---|---|
SIGINT (2) | Interrotto | Attenzione interattiva (CTRL-C). JVM esce normalmente. | Sì |
SIGTERM (15) | Interrotto | Richiesta termine. JVM uscirà normalmente. | Sì |
SIGBREAK | Controllo | Segnale di interruzione per un terminale. Come impostazione predefinita, ciò innesca un Javadump. | Sì |
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.
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.
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).
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.
È 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".
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).
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.
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.
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.
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 .
Ad esempio, per tracciare gli eventi e i messaggi formattati GIOP, digitare:
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true <myapp>
Non attivare la traccia per le normali operazioni in quanto ciò potrebbe comportare un peggioramento delle prestazioni. Anche se la traccia è stata disattivata, FFDC (First Failure Data Capture) funziona comunque, per cui vengono riportati 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.
L'ORB può essere ottimizzato per lavorare bene in una rete specifica. Di seguito si descrivono le proprietà richieste per l'ottimizzazione di ORB.
Per disattivare la frammentazione impostare la dimensione del frammento su 0 byte:
java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
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.
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 |
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 (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:
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.
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.*;.
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.
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/.
Il plug-in Java supporta Internet Explorer, Netscape, Mozilla, e Mozilla Firefox.
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.
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:
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.
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:
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.
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.
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
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
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.
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:
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.
javaws <URL>Dove <URL> è l'ubicazione del file .jnlp .
C:\Program Files\IBM\Java60\jre\bin\javaws| -viewer
Tutte le applicazioni Java Web Start sono memorizzate nell'Application Cache Java . Le applicazioni vengono scaricate soltanto se l'ultima versione non è nella cache.
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.
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.
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:
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.
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.
|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.
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.
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.
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.
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.
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.
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 :
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.
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.
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.
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.
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:
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.
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.
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.
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.
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:
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:
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.
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.
Quando si stampa con l'API Java Communications, potrebbe essere necessario selezionare "Alimentazione fogli", "Continua", o un'opzione simile sulla stampante.
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\.
E' possibile trovare trovare la documentazione API ed esempi di Java Communications API sul sito Web della Sun.
http://java.sun.com/products/javacomm/.
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.
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/.
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.
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.
È 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.
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.
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.
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.
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.
IBM SDK a 32 bit per Windows, v6 supporta le seguenti localizzazioni:
Tuttavia, i font di queste localizzazioni potrebbero non funzionare sui componenti AWT.
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.
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:
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/.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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à.