Prima di utilizzare queste informazione ed il prodotto che supporta, leggere le informazioni in Informazioni particolari.
Questa edizione della guida utente si applica all'SDK e Runtime Environment IBM per Linux su diverse piattaforme.
Le piattaforme a cui si applica questa guida sono le seguenti:
e a tutte le successive release e modifiche se non diversamente specificato nelle nuove edizioni.
(C) Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Tutti i diritti riservati.
Questa guida utente fornisce informazioni di carattere generale su IBM per piattaforme Linux, Java Technology Edition, Versione 6 e informazioni specifiche sulle differenze nella implementazione IBM rispetto alla implementazione Sun.
Consultare questa guida utente assieme alla più completa documentazione dal sito Web di Sun: http://java.sun.com.
Per un elenco delle distribuzioni su cui sono stati testati SDK e Ambiente di Runtime per Linux, consultare http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html.
(Solo per piattaforme Intel a 32 bit) Sono supportati questi Virtualized Environment:
La Guida alla Diagnostica fornisce informazioni più dettagliate sulla Virtual Machine di IBM per Java.
La presente guida utente è parte di una release ed è applicabile solo a quella specifica release. Assicurarsi di avere la guida utente appropriata per la release che si sta utilizzando.
I termini "Runtime Environment" e "Java Virtual Machine" vengono utilizzati scambievolmente in tutta la presente guida utente.
|Le modifiche tecniche apportate a questa versione della Guida Utente, eccetto quelle di minore importanza o ovvie, sono indicate da simboli azzurri a V se visualizzate in un Information Center, in rosso se visualizzate in una copia HTML o in una stampa a colori e con barre verticali a sinistra delle modifiche se visualizzate in un PDF.
Il Program Code non è progettato né inteso ad essere utilizzato nelle applicazioni in real-time come (ma non limitato ad essi) il controllo on line dei velivoli, del traffico aereo, della navigazione aerea o delle comunicazioni aeree; ovvero nella progettazione, nella costruzione, nel funzionamento o nella manutenzione di un impianto nucleare.
L'SDK di IBM è un ambiente di sviluppo per scrivere ed eseguire applet ed applicazioni che si conformano alle API (Application Program Interface) Java 6 Core.
L'SDK include l'Ambiente di Runtime per Linux, che consente solo di eseguire le applicazioni Java. Se è installato l'SDK, l'Ambiente di Runtime è incluso.
L'Ambiente di Runtime contiene la Virtual Machine di Java ed i file di supporto inclusi i non-debuggable .so files ed i class files. L'Ambiente di Runtime contiene solo un sottogruppo delle classi trovate nell'SDK e consente di supportare un programma diJava in runtime ma non fornisce la compilazione dei programmi Java. L'Ambiente di Runtime per Linux non include alcuno dei tool di sviluppo, ad esempio appletviewer oppure il compilatore Java (javac), o le classi che sono solo per i sistemi di sviluppo.
Inoltre, per le piattaforme IA32, PPC32/PPC64, e AMD64/EM64T, il pacchetto Java Communications application programming interface (API) viene fornito per essere utilizzato in Ambiente di Runtime per Linux. Per informazioni, consultare la sezione Utilizzo dell'API Java Communications (JavaComm).
Il file license_xx.html contiene l'accordo di licenza per il software Runtime Environment per Linux, dove xx è l'abbreviazione della lingua. Per visualizzare o stampare l'accordo di licenza, aprire il file in un browser Web.
In questa guida utente, la directory di installazione predefinita di SDK è indicata come /opt/ibm/java-i386-60/. Se non si sta usando Linux IA a 32 bit, la directory di installazione predefinita sarà diversa.
Le piattaforme elencate qui hanno differenti directory di installazione; sostituire la directory della piattaforma utilizzata quando appare /opt/ibm/java-i386-60/:
Negli esempi di questa guida utente vengono utilizzati comandi di shell Korn.
In genere, qualsiasi applicazione applet o eseguita su una precedente versione del SDK dovrebbe funzionare correttamente con il SDK per Linux ,v6 di IBM. Non viene fornita alcuna garanzia che le classi compilate con questa versione funzionino sulle versioni precedenti.
Per informazioni su questioni di compatibilità fra le release, fare riferimento al sito Web Sun all'indirizzo:
|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 (per esempio, IBM WebSphere Application Server) e si esegue l'upgrade da un livello precedente dell'SDK, per esempio v5.0, le classi serializzate potrebbero non essere compatibili. Tuttavia, le classi sono compatibili fra un aggiornamento e l'altro del servizio.
Dalla Version 5.0, il Runtime Environment IBM per Linux contiene nuove versioni della Virtual Machine IBM per Java e il compilatore JIT (Just-In-Time).
Se si sta eseguendo la migrazione da una versione più vecchia dell'Ambiente di Runtime di IBM, occorre tenere presente che:
Gli SDK e Runtime Environment a 31 bit e 64 bit per System z possono essere eseguiti su hardware System z9 e zSeries.
Gli SDK e Runtime Environment possono essere eseguiti sui seguenti server o equivalenti:
Il SDK contiene numerosi tool di sviluppo ed un JRE (Java Runtime Environment). Questa sezione descrive i contenuti dei tool SDK e di Runtime Environment.
Le applicazioni scritte interamente in Java non devono avere alcuna dipendenza dalla struttura dell'SDK IBM, (né dai file in quelle directory). Qualsiasi dipendenza dalla struttura della directory dell'SDK (o dai file in quelle directory) potrebbe determinare problemi di trasportabilità dell'applicazione. Le applicazioni JNI (
Le guide utente, i Javadoc, nonché la licenza, i file di copyright, i javadoc, e la directory dimostrativa allegati costituiscono l'unica documentazione inclusa in questo SDK per Linux. 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.
Una lista delle classi e dei tool che possono essere utilizzati con l'Ambiente di Runtime standard.
Un elenco dei tool e delle informazioni di riferimento inclusi nell'SDK standard.
Il file di Licenza, /opt/ibm/java-i386-60/docs/content/<locale>/LA_<locale>, contiene il contratto di licenza per SDK del software Linux (dove <locale> è il nome della propria locale, ad esempio en). Per visualizzare o stampare l'accordo di licenza, aprire il file in un browser Web.
È possibile installare l'SDK e Ruintime Environment Java di IBM SDK da un RPM o da un file .tgz. Salvo il caso in cui si desideri consentire a tutti gli utenti sulla macchina di accedere a questa installazione Java, utilizzare il metodo di installazione .tgz. Se non si dispone dell'accesso root, utilizzare il file .tgz.
Se si effettua l'installazione utilizzando un file RPM, i file Java vengono installati in /opt/ibm/java-i386-60/. Gli esempi in questa guida presuppongono che Java sia stato installato in questa directory.
Se si sta aggiornando l'SDK rispetto ad una versione precedente, eseguire il back up di tutti i file di configurazione e dei file delle politiche di sicurezza prima di dare inizio all'aggiornamento.
Dopo l'aggiornamento, potrebbe essere necessario ripristinare o riconfigurare questi file perché potrebbero essere stati sovrascritti durante il processo di aggiornamento. Verificare la sintassi dei nuovi file prima di ripristinare quelli originali perché il formato o le opzioni dei file sono stati modificati.
SDK dipende da librerie condivise non installate per impostazione predefinita per Red Hat Enterprise Linux (RHEL).
In RHEL 4, gli RPM che contengono tali librerie sono:
Per includere tali librerie durante l'installazione di RHEL 4:
SDK dipende da librerie condivise non installate per impostazione predefinita per Red Hat Enterprise Linux (RHEL).
In RHEL 5, gli RPM che contengono tali librerie sono:
Per includere tali librerie durante l'installazione di RHEL 5:
Per eseguire SDK IBM per Java su Red Hat Enterprise Linux Versione 5 con SELinux abilitato, Java deve essere installato nella directory predefinita, oppure deve essere immesso un comando.
Se Java non è installato nella directory predefinita, immettere:
chcon -R -t texrel_shlib_t <percorso_di_sdk>
dove <percorso_di_sdk> è il percorso in cui è installato Java.
Per maggiori informazioni su SELinux, consultare Introduction to SELinux nella documentazione di Red Hat.
Per eseguire il SDK, è necessario installare le versioni corrette di tutte le librerie r richieste dal SDK, a 32 o 64 bit.
In RHEL4, le versioni a 64 bit dei pacchetti sono disponibili nel gruppo di pacchetti Compatibility Arch Support.
È possibile utilizzare il tool RPM per verificare quali versioni dei pacchetti sono state installate aggiungendo l'opzione --queryformat "%{NAME}.%{ARCH}\n" al comando RPM. Ad esempio:
/home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++ libstdc++.x86_64 libstdc++.i386
Procedura per l'installazione da un file RPM.
Per eseguire l'upgrade della JVM usando il tool rpm, è necessario disinstallare le versioni precedenti. Per installare due versioni della JVM in ubicazioni diverse, usare l'ozpione --force per ignorare il conflitto di versioni oppure installare la JVM dal file .tgz.
rpm -ivh ibm-java2-<arch>-sdk-6.0-0.0.<arch>.rpmoppure
rpm -ivh ibm-java2-<arch>-jre-6.0-0.0.<arch>.rpm
Dove <arch> rappresenta la propria architettura: i386, x86_64, ppc, ppc64, s390 o s390x.
Procedura per l'installazione da un file .tgz.
tar -zxvf ibm-java2-sdk-60-linux-<arch>.tgzoppure
tar -zxvf ibm-java2-jre-60-linux-<arch>.tgz
Dove <arch> rappresenta la propria architettura: i386, x86_64, ppc, ppc64, s390, o s390x.
chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/jre chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/bin chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/lib
Il pacchetto Java IBM è disponibile anche in formato compatibile JPackage.
Per semplificare la gestione di SDK, i suoi diversi componenti sono disponibili come RPM distinti: il Java Runtime Environment di base, Development Kit, Plug-in, JDBC, Demo, Sound, Source e Fonts. L'RPM "jpackage-utils" (scaricabile da http://jpackage.org), che consente di gestire più RPM Java sullo stesso sistema, è un prerequisito necessario anche per gli SDK IBM. Per maggiori informazioni sulla specifica JPackage, visitare http://jpackage.org.
Incongruenze nella codifica dei font su Red Hat Advanced Server
Se si altera la variabile d'ambiente PATH, verranno sostituiti tutti gli eventuali launcher Java esistenti nel proprio percorso.
La variabile d'ambiente PATH consente a Linux di trovare programmi e utility, come javac, java e javadoc, da qualsiasi directory corrente. Per visualizzare il valore corrente del proprio PATH, immettere quanto segue in un prompt dei comandi:
echo $PATH
Per aggiungere i launcher Java al proprio percorso:
export PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
Dopo aver impostato il percorso, è possibile avviare un tool digitandone il nome nel prompt dei comandi da qualsiasi directory. Per esempio, per compilare il file Myfile.Java, dal prompt dei comandi, digitare:
javac Myfile.Java
Il percorso della classe suggerisce gli strumenti SDK, come java, javac, e javadoc, in cui trovare le librerie Java della classe.
Occorre impostare il percorso della classe esplicitamente solo se:
Per visualizzare il valore corrente della propria variabile in ambiente CLASSPATH, immettere il comando seguente in una shell prompt:
echo $CLASSPATH
Se si sviluppano e si eseguono delle applicazioni che utilizzano differenti ambienti di runtime, che includono altre versioni che sono state installate separatamente, è necessario impostare il CLASSPATH ed il PATH esplicitamente per ciascuna applicazione. Se vengono eseguite applicazioni multiple simultaneamente ed utilizzati differenti ambienti di runtime, ciascuna applicazione deve funzionare nel proprio shell prompt.
Il processo utilizzato per rimuovere SDK e Ambiente di Runtime per Linux dipende dal tipo di installazione utilizzata.
Consultare Disinstallazione del pacchetto RMP (Red Hat Package Manager) o Disinstallazione del pacchetto TAR (Tape Archive) compresso per le istruzioni.
Procedura per la disinstallazione del pacchetto RMP (Red Hat Package Manager)
Per disinstallare SDK o Ambiente di Runtime per Linux con installato il pacchetto RMP installabile:
Verrà visualizzato un elenco di tutti i pacchetti Java IBM installati; per esempio:
ibm-java2-<arch>-jre-6.0-0.0.<arch> ibm-java2-<arch>-sdk-6.0-0.0.<arch>
Tale output indica quali pacchetti è possibile disinstallare utilizzando il comando rpm -e; ad esempio:
rpm -e ibm-java2-<arch>-jre-6.0-0.0.<arch> rpm -e ibm-java2-<arch>-sdk-6.0-0.0.<arch>
In alternativa, è possibile utilizzare un tool grafico, come per esempio kpackage oppure yast2
Elenco fdi istruzioni per la rimozione di SDK per Linux ,v6 di IBM estratto dal pacchetto compresso.
È possibile avviare le applicazioni Java utilizzando il launcher java o mediante JNI. Le impostazioni vengono trasmesse all'applicazione Java mediante argomenti di riga comandi, variabili d'ambiente e file delle proprietà.
Breve rassegna dei comandi java e javaw.
Gli strumenti java e javaw lanciano un'applicazione Java avviando un Ambiente di Runtime Java e caricando una classe specifica.
Il comando javaw è identico a java, tranne javaw che non ha alcuna finestra di console associata. Utilizzare javaw quando non si desidera che venga visualizzata una finestra di richiesta comandi. Il programma di avvio javaw visualizza una casella di dialogo con le informazioni sugli errore nel caso in cui l'avvio abbia esito negativo.
La JVM ricerca la classe iniziale (e le altre classi utilizzate) in tre gruppi di ubicazioni: il percorso della classe di bootstrap, le estensioni installate, ed il percorso delle classi utente. Gli argomenti che vengono specificati dopo il nome della classe o quello del file jar vengono trasmessi alla funzione principale.
I comandi java e javaw hanno la sintassi seguente:
java [ options ] <class> [ arguments ... ] java [ options ] -jar <file.jar> [ arguments ... ] javaw [ options ] <class> [ arguments ... ] javaw [ options ] -jar <file.jar> [ arguments ... ]
Il numero di versione e di build IBM della propria installazione Java possono essere ottenuti mediante l'opzione -version. |Inoltre è possibile ottenere informazioni di versione per tutti i file jar nel percorso della classe usando l'ozpione -Xjarversion.
java -versionSarà possibile vedere informazioni simili a:
versione java "1.6.0-internal" Java(TM) SE Runtime Environment (build 20070329_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20070326_12091 (JIT enabled) J9VM - 20070326_12091_lHdSMR JIT - dev_20070326_1800 GC - 20070319_AA)Le date esatte del build e le versioni cambieranno.
|
| Inoltre, è possibile consultare le informazioni di versione di tutti i file jar disponibili nel percorso della classe, nel percorso della classe di boot e nella directory delle estensioni immettendo il comando seguente:
java -Xjarversion|
Sarà possibile vedere informazioni simili a:
|... |/opt/ibm/java-i386-60/jre/lib/ext/ibmpkcs11impl.jar VERSION: 1.0 build_20070125 |/opt/ibm/java-i386-60/jre/lib/ext/dtfjview.jar |/opt/ibm/java-i386-60/jre/lib/ext/xmlencfw.jar VERSION: 1.00, 20061011 LEVEL: -20061011 | |...|
Le informazioni disponibili variano per ciascun file jar e |viene preso dalle proprietà Implementation-Version e Build-Level nel |manifesto file jar.
possibile specificare le opzioni e le proprietà di sistema di Java sulla riga comandi, oppure utilizzando un file delle opzioni, o ancora utilizzando una variabile di ambiente.
Questi metodi per specificare le opzioni Java sono elencati in ordine di priorità:
java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
export IBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"
Le opzioni più a destra sulla riga comandi hanno la priorità su quelle più a sinistra; ad esempio, se si specifica:
java -Xint -Xjit myClass
L'opzione -Xjit ha la precedenza.
Definizioni per opzioni standard.
I launcher java e javaw accettano argomenti e nomi di classe contenenti qualsiasi carattere che faccia parte del set di caratteri della localizzazione corrente. inoltre possibile specificare un qualsiasi carattere Unicode nel nome della classe e gli argomenti utilizzando le sequenze di escape Java.
Per fare ciò, utilizzare l'opzione della riga comandi -Xargencoding.
Ad esempio, per specificare una classe chiamata HelloWorld utilizzando una codifica Unicode per entrambe le lettere maiuscole, utilizzare il comando seguente:
java -Xargencoding '\u0048ello\u0057orld'
I comandi java e javaw forniscono messaggi tradotti. Tali messaggi differiscono a seconda della locale in cui Java sta funzionando. Le descrizioni dettagliate dell'errore ed altre informazioni di debug restituite da java sono in lingua inglese.
Il compilatore JIT (Just-in-Time) IBM effettua la generazione dinamica del codice macchina per sequenze di bytecode di frequente utilizzo nelle applicazioni e nelle applet Java durante la loro esecuzione. Il compilatore JIT v6 fornisce nuove ottimizzazioni come risultato della ricerca del compiler, migliora le ottimizzazioni implementate nelle versioni precedenti dello JIT, e fornisce un migliore utilizzo dell'hardware.
Sia l'SDK che l'Ambiente di Runtime IBM includono lo JIT, abilitato per default nelle applicazioni utente e nei tool SDK. Di norma, non occorre richiamare lo JIT esplicitamente; la compilazione di un bytecode Java in codice macchina avviene in maniera trasparente. È possibile disabilitare JIT per aiutare a isolare un problema. Se si verifica un problema durante l'esecuzione di un applet o applicazione Java, è possibile disabilitare JIT per facilitare l'isolamento del problema. Disabilitare lo JIT deve essere solo una misura temporanea; lo JIT è necessario per ottimizzare le prestazioni.
Per ulteriori informazioni su JIT, consultare Guida alla Diagnostica.
Lo JIT può essere disabilitato in una serie di modi diversi. Entrambe le opzioni di riga comandi sovrascrivono la variabile d'ambiente JAVA_COMPILER.
La disattivazione dello JIT è una misura temporanea che aiuta ad isolare i problemi quando si effettua il debugging delle applicazioni Java.
export JAVA_COMPILER=NONE
java -Djava.compiler=NONE <class>
java -Xint < class>
JIT è abilitato per impostazione predefinita. È possibile abilitare JIT in molti modi diversi. Entrambe le opzioni di riga comandi sovrascrivono la variabile d'ambiente JAVA_COMPILER.
export JAVA_COMPILER=jitcSe la variabile dell'ambiente JAVA_COMPILER è una stringa vuota, lo JIT resta disabilitato. Per disabilitare la variabile dell'ambiente, immettere quanto segue in shell prompt:
unset JAVA_COMPILER
java -Djava.compiler=jitc <class>
java -Xjit <class>
possibile determinare lo stato del JIT utilizzando l'opzione -version.
Avviare il launcher di java con l'opzione -version. Immettere quanto segue in shell prompt:
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 maggiori informazioni su JIT, consultare la Guida alla Diagnostica.
Il Garbage Collector gestisce la memoria utilizzata da Java e dalle applicazioni che funzionano all'interno della JVM.
Quando il Garbage Collector riceve una richiesta di memorizzazione, la memoria inutilizzata nell'heap viene accantonata in un processo denominato "allocazione". Il Garbage Collector controlla anche le aree della memoria non più referenziate, e le rilascia per il riutilizzo. Questa funzione è nota come "raccolta".
La fase di raccolta può scattare in seguito ad un errore di allocazione della memoria, che si verifica quando non resta spazio per una richiesta di memoria, o ad una chiamataSystem.gc() esplicita.
La raccolta dei dati obsoleti può incidere significativamente sulla prestazione dell'applicazione, per cui la macchina virtuale della IBM fornisce vari metodi di ottimizzazione della raccolta dei dati obsoleti, riducendo potenzialmente gli effetti sull'applicazione.
Per ulteriori dettagliate informazioni sulla raccolta dei dati obsoleti, consultare la Guida alla Diagnostica.
Le opzioni -Xgcpolicy controllano il comportamento del Garbage Collector. Esse effettuano delle compensazioni fra la velocità di trasmissione dell'applicazione e del sistema complessivo, ed i tempi di pausa causati dalla raccolta dei dati obsoleti.
Il formato dell'opzione ed i suoi valori sono:
Quando il tentativo di un'applicazione di creare un oggetto non può essere soddisfatto immediatamente dallo spazio disponibile in un heap, il Garbage Collector è responsabile della identificazione degli oggetti non referenziati (garbage), della loro eliminazione, e del ritorno dell'heap ad uno stato in cui le richieste di allocazione immediate e successive 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 di file obsoleti simultanea e la raccolta di file obsoleti generazionale.
L'opzione della riga comandi -Xgcpolicy:optavgpause richiede l'utilizzo della raccolta dati obsoleti simultanea per ridurre in modo significativo il tempo utilizzato nelle pause della raccolta dei dati obsoleti. La raccolta dati obsoleti simultanea riduce il tempo di pausa eseguendo alcune attività di raccolta dei dati obsoleti contemporaneamente all'esecuzione normale del programma per ridurre le interruzioni causate dalla raccolta della memoria riservata. L'opzione -Xgcpolicy:optavgpause limita inoltre l'effetto dell'incremento della dimensione della memoria riservata nella lunghezza della pausa della raccolta dei dati obsoleti. L'opzione -Xgcpolicy:optavgpause è molto utile per configurazioni che hanno grandi memorie riservate. Con il tempo di pausa ridotto, è possibile che si verifichi una riduzione nella capacità di elaborazione delle applicazioni.
Durante la raccolta dei dati obsoleti simultanea, una notevole quantità di tempo viene persa per identificare gli oggetti relativamente duraturi che non possono essere raccolti. Se la raccolta dei dati obsoleti si concentra solo sugli oggetti che molto probabilmente sono riciclabili, è possibile ridurre ulteriormente i tempi di pausa per alcune applicazioni. La Raccolta dei Dati Obsoleti Generazionale riduce i tempi di pausa dividendo la memoria riservata in due "generazioni": le aree "asilo" e "possesso". Gli oggetti sono ubicati in una di queste aree a seconda della loro età. L'asilo è il più piccolo del due e contiene oggetti più giovani; il possesso è più grande e contiene oggetti più vecchi. Gli oggetti vengono prima assegnati all'asilo; se sopravvivono abbastanza a lungo, vengono infine promossi nell'area di possesso.
La raccolta dati obsoleti generazionale si basa su una maggioranza di oggetti che non durano a lungo. La raccolta dati obsoleti generazionale, riduce i tempi di pausa concentrandosi sul reclamo memoria nell'asilo in quanto questa area, dispone di più spazio riciclabile. Invece di utilizzare tempi di pausa lunghi per la raccolta dell'intera memoria riservata, i dati nell'asilo vengono raccolti più spesso e, se l'asilo è sufficientemente piccolo, i tempi di pausa sono conseguentemente brevi. Il lato negativo della raccolta dati generazionale consiste nel fatto che, nel tempo, l'area di possesso potrebbe diventare piena se molti oggetti durano troppo a lungo. Per ridurre il tempo di pausa quando si verifica tale situazione, utilizzare una combinazione di raccolte dati obsoleti generazionali e simultanee. L'opzione -Xgcpolicy:gencon richiede l'uso combinato della raccolta dati simultanea e generazionale per ridurre il tempo impiegato nella pausa della raccolta dei dati obsoleti.
Se l'heap Java diventa quasi pieno, ed i dati obsoleti da eliminare sono pochi, le richieste dei nuovi oggetti potrebbero non essere soddisfatte rapidamente, in quanto non vi è spazio immediatamente disponibile.
Se uno heap viene utilizzato quando è quasi pieno, le prestazioni dell'applicazione potrebbero soffrirne, a prescindere da quale delle opzioni di garbage collection viene utilizzata; inoltre, se continuano ad essere inoltrate richieste di altro spazio dell'heap, l'applicazione potrebbe ricevere un OutOfMemoryError, determinando la chiusura della JVM se l'eccezione non viene rilevata e risolta. A questo punto, la JVM produce un file Javadump da utilizzare durante la diagnostica. In tali condizioni, si consiglia o di aumentare la dimensione dell'heap utilizzando l'opzione -Xmx o di ridurre il numero di oggetti in uso.
Per ulteriori informazioni, consultare il manuale Guida alla Diagnostica.
IBM SDK e Ambiente di Runtime impostano l'Euro come valuta predefinita per quei paesi dell'UME (Unione Monetaria Europea) per le date a partire dal 1 gennaio 2002. Dall'1 gennaio 2008, anche Cipro e Malta avranno l'Euro come principale valuta.
Per utilizzare la vecchia valuta nazionale, specificare -Duser.variant=PREEURO sulla riga comandi Java.
Se si sta lavorando con le locali del Regno Unito, della Danimarca o della Svezia e si desidera utilizzare l'Euro, specificare -Duser.variant=EURO sulla riga comandi Java.
I file di configurazione font fallback di Linux (fontconfig.RedHat.bfc e fontconfig.SuSE.bfc) sono installati per fornire impostazioni font adatte per le nuove distribuzioni enterprise di Linux.
Questi file sono presenti solo per comodità. La loro presenza non implica che la nuova distribuzione di Linux è una piattaforma supportata per IBM per piattaforme Linux, Java Technology Edition, Versione 6.
| | |Dalla versione 6, i metodi di input indiano e tailandese non sono disponibili |in modalità predefinita. necessario includere manualmente il metodo di input dei file jar |nel proprio percorso delle estensioni Java per utilizzare i metodi di input indiano e tailandese.
Nella Versione 5.0 i file del metodo di input jar sono stati |inclusi nella directory jre/lib/ext ed automaticamente caricati dal JVM. Nella Versione 6, i file del metodo di input jar |sono inclusi nella directory jre/lib/im e devono essere aggiunti manualmente al percorso delle estensioni Java per consentire l'abilitazione dei metodi di input |indiano e tailandese. possibile conseguire ciò utilizzando uno dei metodi seguenti:
|java -Djava.ext.dirs=/opt/ibm/java-i386-60/jre/lib/ext:/opt/ibm/java-i386-60/jre/lib/im <class>
|
Se sono stati installati SDK o Ambiente di Runtime in una directory differente, |sostituire /opt/ibm/java-i386-60/ con |la directory in cui SDK o Ambiente di Runtime sono stati installati.
SDK per Linux contiene molti strumenti e librerie necessari allo sviluppo di software Java.
Consultare Tool e informazioni di riferimento dell'SDK per informazioni dettagliate sugli strumenti disponibili.
| | |L'SDK IBM contiene i parser XML4J e |XL XP-J, il compilatore XSLT XL TXE-J 1.0 e l'interprete XSLT XSLT4J. |Tali strumenti consentono di analizzare, convalidare e trasformare documenti XML indipendentemente da qualsiasi implementazione di elaborazione XML fornita.
|
Usare i factory finder per localizzare le implementazioni delle classi astratte di factory, come descritto in Selezione di un processore XML. |Usando i factory finder, è possibile selezionare una diversa libreria XML senza modificare il codice Java.
|L'SDK di IBM per Java contiene le seguenti |librerie XML.
|XML4J è un parser validante che supporta i seguenti standard: |
|XML4J 4.5 è basato su Apache Xerces-J 2.9.0. Consultare http://xerces.apache.org/xerces2-j/ per maggiori informazioni.
|XL XP-J 1.1 è un parser non validante ad alte prestazioni che fornisce supporto per StAX 1.0 (JSR 173); una API bidirezionale per il pull-parsing e la serializzazione in streaming di documenti XML 1.0 e XML 1.1. Consultare la sezione Informazioni di riferimento su XL XP-J per maggiori dettagli su quanto supportato da XL XP-J 1.1.
|Nella Versione 5.0, l'SDK di IBM per Java includeva compilatore e interprete XSLT4J. |L'interprete XSLT4J veniva usato per impostazione predefinita.
| |Nella Versione 6, l'SDK di IBM per Java include XL TXE-J. XL TXE-J include l'interprete XSLT4J 2.7.8 e un nuovo compilatore XSLT. |Il nuovo compilatore viene utilizzato per impostazione predefinita. Il compilatore XSLT4J non è più incluso nell'SDK di IBM per Java, |consultare Migrazione verso XL-TXE-J per informazioni sulla migrazione a XL TXE-J.
| |XL TXE-J supporta i seguenti standard: |
|La selezione del processore XML |viene eseguita utilizzando i service provider. Quando si utilizza un factory |finder, Java effettua una ricerca |nelle ubicazioni seguenti per individuare il tipo di service provider da utilizzare: |
|I seguenti service provider controllano le librerie di elaborazione XML utilizzate da Java: |
|Il compilatore XL TXE-J ha sostituito l'interprete XSLT4J come processore XSLT predefinito. Seguire queste istruzioni 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 ad utilizzare l'interprete XSLT4J come proprio processore XSLT, impostare il service provider javax.xml.transform.TransformerFactory |su org.apache.xalan.processor.TransformerFactoryImpl.
|Per migrare al compilatore XL-TXE-J, seguire queste istruzioni:
|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 XML XL XP-J e XL TXE-J sono nuove nella Versione 6 dell'SDK. Queste informazioni di riferimento descrivono le funzioni supportate da queste librerie.
XL XP-J 1.1 è un parser non validante ad alte prestazioni che fornisce supporto per StAX 1.0 (JSR 173); una API bidirezionale per il pull-parsing e la serializzazione in streaming di documenti XML 1.0 e XML 1.1.
Le seguenti funzioni opzionali di StAX non sono supportate da XL XP-J: |
|Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLInputFactory, come descritto nel Javadoc XMLInputFactory.
| |Nome della proprietà | |Supportata | |
---|---|
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 dei namespace dipende dai metodi usati per creare l'albero dei DOM, e questo valore non ha effetto. | |
javax.xml.stream.isCoalescing | |Sì | |
javax.xml.stream.isReplacingEntityReferences | |Sì. Per gli XMLStreamReader creati da DOMSource, se le entità sono già state sostituite nell'albero dei DOM, l'impostazione di questo parametro non ha effetto. | |
javax.xml.stream.isSupportingExternalEntities | |Sì | |
javax.xml.stream.supportDTD | |No. I DTD sono sempre supportati. L'impostazione di questo valore a false non ha alcun effetto. | |
javax.xml.stream.reporter | |Sì | |
javax.xml.stream.resolver | |Sì | |
XL XP-J supporta inoltre il metodo opzionale createXMLStreamReader(javax.xml.transform.Source), |che consente di creare lettori StAX da sorgenti DOM e SAX.
|Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLStreamReader, come descritto nel Javadoc XMLStreamReader.
| |Nome della proprietà | |Supportata | |
---|---|
javax.xml.stream.entities | |Sì | |
javax.xml.stream.notations | |Sì | |
XL XP-J supporta inoltre la proprietà javax.xml.stream.isInterning, che restituisce un valore booleano che indica se i nomi XML e gli URI dei namespace restituiti dalle chiamate API sono stati internalizzati dal parser.
|Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLOutputFactory, come descritto nel Javadoc XMLOutputFactory.
| |Nome della proprietà | |Supportata | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sì | |
Le seguenti proprietà sono supportate dall'implementazione javax.xml.stream.XMLStreamWriter, come descritto nel Javadoc XMLStreamWriter.
| |Nome della proprietà | |Supportata | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sì | |
Le proprietà degli oggetti XMLStreamWriter sono di sola lettura.
| | |XL TXE-J è una libreria XSLT che contiene l'interprete XSLT4J 2.7.8 e un compilatore XSLT.
Funzione | |Interprete XSLT4J (incluso) | |Compilatore XSLT4J (non incluso) | |Compilatore XL TXE-J (incluso) | |
---|---|---|---|
funzione http://javax.xml.transform.stream.StreamSource/feature | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.stream.StreamResult/feature | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.dom.DOMSource/feature | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.dom.DOMResult/feature | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.sax.SAXSource/feature | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.sax.SAXResult/feature | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.stax.StAXSource/feature | |Sì | |No | |Sì | |
funzione http://javax.xml.transform.stax.StAXResult/feature | |Sì | |No | |Sì | |
funzione http://javax.xml.transform.sax.SAXTransformerFactory/feature | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.sax.SAXTransformerFactory/feature/xmlfilter | |Sì | |Sì | |Sì | |
funzione http://javax.xml.transform.dom.XMLConstants/feature/secure-processing | |Sì | |Sì | |Sì | |
attributo incrementale http://xml.apache.org/xalan/features/ | |Sì | |No | |No | |
ottimizzare attributo http://xml.apache.org/xalan/features/ | |Sì | |No | |No | |
attributo http://xml.apache.org/xalan/properties/source-location | |Sì | |No | |No | |
attributo translet-name | |N/D | |Sì | |Sì (con un nuovo nome) | |
attributo destination-directory | |N/D | |Sì | |Sì (con un nuovo nome) | |
attributo package-name | |N/D | |Sì | |Sì (con un nuovo nome) | |
attributo jar-name | |N/D | |Sì | |Sì (con un nuovo nome) | |
attributo generate-translet | |N/D | |Sì | |Sì (con un nuovo nome) | |
attributo auto-translet | |N/D | |Sì | |Sì (con un nuovo nome) | |
attributo use-classpath | |N/D | |Sì | |Sì (con un nuovo nome) | |
attributo enable-inlining | |No | |Sì | |No (obsoleto in TL TXE-J) | |
attributo indent-number | |No | |Sì | |Sì (con un nuovo nome) | |
attributo di debug | |No | |Sì | |Sì (con un nuovo nome) | |
Estensioni Java | |Sì | |Sì (solo sintassi abbreviata, xalan:component/xalan:script |costruzioni non supportate) | ||
Estensioni JavaScript | |Sì | |No | |No | |
Elementi dell'estensione | |Sì | |No | |No | |
Funzioni dell'estensione EXSLT | |Sì | |Sì (escludendo la funzione dinamica) | |Sì (escludendo la funzione dinamica) | |
estensione redirect | |Sì | |Sì (escludendo redirect:open and redirect:close) | |Sì | |
estensione output | |No | |Sì | |Sì | |
estensione nodeset | |Sì | |Sì | |Sì | |
funzioni dell'estensione NodeInfo | |Sì | |No | |No | |
estensione della libreria SQL | |Sì | |No | |No | |
estensione pipeDocument | |Sì | |No | |No | |
estensione evaluate | |Sì | |No | |No | |
estensione tokenize | |Sì | |No | |No | |
XML 1.1 | |Sì | |Sì | |Sì | |
Con il comando Process, utilizzare -FLAVOR |sr2sw per trasformare utilizzando lo StAX stream processing, e -FLAVOR |er2ew per lo StAX event processing.
|Il nuovo compilatore non effettua la |ricerca del service provider org.apache.xalan.xsltc.dom.XSLTCDTMManager service. Invece, se viene utilizzato StreamSource il compilatore |effettua la commutazione ad un parser XML ad alta resa.
|L'inlining è obsoleto in XL |TXE-J. |
|La classe org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl non |è più supportata.
| |Se si sta utilizzando una versione più vecchia di Xerces (precedente alla 2.0) o di Xalan (precedente alla 2.3) nella sovrascrittura approvata,si potrebbe ricevere una NullPointerException all'avvio dell'applicazione. Tale eccezione si verifica perché le versioni più vecchie non gestiscono il file jaxp.properties in modo corretto.
|
Per evitare questa situazione, usare una delle seguenti soluzioni alternative: |
|export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
oppure
|export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
oppure
|export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
Per effettuare il debug dei programmi Java, è possibile utilizzare l'applicazione del Debugger JBD di Java, o altri debugger che comunicano utilizzando la JPDA (Java Platform Debugger Architecture) di Java fornita da SDK per Linux.
Ulteriori informazioni sulla diagnostica dei problemi rilevati con l'uso di Java possono essere reperite nella Guida alla Diagnostica.
Il JDB (Java Debugger) è incluso nel SDK di Linux. Il debugger viene richiamato dal comando jdb; esso si collega alla JVM che sta utilizzando JPDA.
Per eseguire il debug di un'applicazione Java:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>La JVM si avvia, ma sospende l'esecuzione prima di avviare l'applicazione Java.
jdb -attach<port>Il debugger si collegherà alla JVM, e sarà possibile emettere una serie di comandi per esaminare e controllare l'applicazione Java; ad esempio, immettere run per consentire all'applicazione Java di avviarsi.
Per ulteriori informazioni sulle opzioni JDB, immettere:
jdb -help
Per ulteriori informazioni sui comandi JDB, immettere:
E' possibile inoltre utilizzare il JDB per effettuare il debug di applicazioni Java operanti su macchine remote. JPDA utilizza un socket TCP/IP per connettersi alla JVM remota.
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>La JVM si avvia, ma sospende l'esecuzione prima di avviare l'applicazione Java.
jdb -attach <host>:<port>
La JVMDI (Java Virtual Machine Debugging Interface) non è supportata in questa versione. Essa è stata sostituita dalla JVMTI (Java Virtual Machine Tool Interface).
Per ulteriori informazioni su JDB e JPDA e sul loro utilizzo, consultare i seguenti siti Web:
Alcune applicazioni Java devono essere in grado di determinare se stanno eseguendo un JVM a 32-bit o un JVM 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 il JVM di cui si dispone. Vengono restituiti i seguenti valori:
possibile ispezionare la proprietà com.ibm.vm.bitmode dall'interno del proprio codice dell'applicazione utilizzando la chiamata:
System.getProperty("com.ibm.vm.bitmode");
Quando viene generato un segnale che possa essere di interesse per la JVM, viene richiamato un programma di gestione segnali. Questo segnale determina se è stato chiamato per un un thread Java o non Java.
Se il segnale è per un thread Java, la JVM assume il controllo della gestione del segnale. Se è installato un gestore dell'applicazione di questo segnale e non è stata specificata l'opzione -Xnosigchain della riga dei comandi, il gestore dell'applicazione di questo segnale viene richiamato dopo che la JVM ha ultimato l'elaborazione.
Se il segnale è per un thread non-Java, e l'applicazione che installava JVM aveva precedentemente installato il proprio gestore segnali, il controllo viene passato a tale gestore. Altrimenti, se il segnale viene richiesto dalla JVM oppure dall'applicazione Java il segnale viene ignorato oppure viene intrapresa l'azione predefinita.
Per i segnali di errore e eccezione, la JVM esegue quanto segue:
Per segnali di interruzione, la JVM immette inoltre una sequenza di chiusura controllata, ma questa volta viene trattata come una normale chiusura che:
L'arresto è identico a quello inizializzato da un richiamo 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 è SIGQUIT, che genera un Javadump.
I tipi di segnali sono Eccezioni, Errori, Interruzioni e Controlli.
Nel Tabella 7 che segue 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 |
---|---|---|---|
SIGBUS (7) | Eccezione | Accesso errato alla memoria (allineamento errato di dati ) | Sì |
SIGSEGV (11) | Eccezione | Accesso alla memoria non corretto (scrittura su memoria non accessibile) | Sì |
SIGILL (4) | Eccezione | Istruzione non valida (tentativo di richiamare un' istruzione macchina sconosciuta) | No |
SIGFPE (8) | Eccezione | Eccezione virgola mobile (dividere per zero) | Sì |
SIGABRT (6) | Errore | Fine anomala. La JVM emette questo segnale quando rileva un problema alla JVM. | Sì |
SIGINT (2) | Interrotto | Attenzione interattiva (CTRL-C). La JVM esce normalmente. | Sì |
SIGTERM (15) | Interrotto | Richiesta termine. La JVM uscirà normalmente. | Sì |
SIGHUP (1) | Interrotto | Disconnessione. La JVM esce normalmente. | Sì |
SIGQUIT (3) | Controllo | Un segnale di uscita per un terminale. Per impostazione predefinita, questo segnale attiva un Javadump. | Sì |
SIGTRAP (5) | Controllo | Utilizzato da JIT. | Sì |
__SIGRTMAX - 2 | Controllo | Utilizzato da SDK. | No |
SIGCHLD (17) | Controllo | Utilizzato da SDK per il controllo interno. | No |
Usare l'opzione -Xrs (riduce uso segnale) per evitare che JVM gestisca la maggior parte dei segnali. Per ulteriori informazioni, fare riferimento alla pagina del launcher delle applicazioni Sun di Java .
I segnali 1 (SIGHUP), 2 (SIGINT), 4 (SIGILL), 7 (SIGBUS), 8 (SIGFPE), 11 (SIGSEGV) e 15 (SIGTERM) sui thread JVM causano l'arresto della JVM; pertanto, il gestore segnali di applicazione non deve tentare il ripristino da questi segnali se richiede la JVM.
Runtime Environment contiene il concatenamento dei segnali. Questa 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 libjsig.so prima delle librerie di sistema. La libreria libjsig.so assicura che le chiamate come signal(), sigset(), e sigaction() vengano intercettate in modo tale che i loro gestori non sostituiscano i gestori del segnale della JVM. Al contrario, tali chiamate salvano i nuovi gestori di segnale o li concatenano ai gestori installati dalla JVM. Successivamente, quando uno di tali segnali viene attivato e viene rilevato come non destinato alla JVM, vengono richiamati i gestori pre-installati.
Se si installano gestori di segnale che utilizzano sigaction() , alcuni sa_flags non vengono rispettati quando la JVM utilizza il segnale. Essi sono:
La libreria libjsig.so nasconde inoltre i gestori dei segnali della JVM all'applicazione. Per questo motivo, chiamate come signal(), sigset() e sigaction() eseguite dopo l'avvio della JVM non restituiscono un riferimento al gestore di segnale della JVM ma restituiscono i gestori installati prima dell'avvio della JVM.
Per utilizzare libjsig.so:
5gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.coppure
export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash e ksh) setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)
La variabile d'ambiente JAVA_HOME deve essere impostata all'ubicazione dell'SDK, per esempio /opt/ibm/java-i386-60/.
Per utilizzare libjsig.a:
cc_r -q64 <other compile/link parameter> -L/opt/ibm/java-i386-60/jre/bin -ljsig -L/opt/ibm/java-i386-60/jre/bin/j9vm -ljvm java_application.c
Numeri validi della versione di JNI che i programmi nativi possono specificare sulla chiamata dell'API JNI_CreateJavaVM() 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 effettivo della JVM che viene creato viene specificato dalle librerie JSE (ossia, v6). L'API interfaccia JNI non influisce sulla specifica del lingua implementata da JVM, le API delle librerie delle classi oppure qualsiasi altra area di azione di JVM. Per ulteriori informazioni, fare riferimento a http://java.sun.com/javase/6/docs/technotes/guides/jni/.
Se la propria applicazione necessita di due librerie JNI, una costruita per 32 bit e l'altra per 64 bit, utilizzare la proprietà di sistema com.ibm.vm.bitmode per determinare se si sta eseguendo una JVM a 32 o a 64 bit JVM e scegliere la libreria appropriata.
Per compilare e collegare un'applicazione nativa con SDK, utilizzare il comando seguente:
gcc -I/opt/ibm/java-i386-60/include -L/opt/ibm/java-i386-60/jre/lib/<arch>/j9vm -ljvm -ldl -lpthread <JNI program filename>
L'opzione -ljvm specifica che libjvm.so sia la libreria condivisa che implementa la JVM. L'opzione -lpthread indica che si sta utilizzando il supporto pthread nativo. Se non ci si collega con la libreria pthread, potrebbe essere dovuto ad un errore di segmentazione (segnale SIGSEGV) quando si esegue il programma JNI.
Quattro nuove classi SDK specifiche di IBM sono state aggiunte al pacchetto com.ibm.jvm per supportare il livello di thread del recupero dei connettori bloccati. Le nuove classi sono impacchettate in core.jar.
Tali classi consentono di sbloccare i thread che si erano bloccati nelle chiamate di rete o di sincronizzazione. Se l'applicazione non usa queste classi, deve terminare l'intero processo piuttosto che interrompere un thread individuale bloccato.
Le classi sono:
Sia InterruptibleLockContext che InterruptibleIOContext lavorano facendo riferimento al thread corrente. Quindi, se non si utilizza InterruptibleThread, è necessario fornire la propria classe che estende java.lang.Thread, per utilizzare queste nuove classi.
Il Javadoc per queste classi viene fornito con l'SDK nella directory docs/content/apidoc.zip.
possibile abilitare un supporto per le pagine ampie, su sistemi che le supportano, avviando Java tramite l'opzione -Xlp.
L'utilizzo di pagine grandi serve principalmente a fornire dei miglioramenti delle prestazioni alle applicazioni che allocano molta memoria e che accedono ad essa frequentemente. I miglioramenti delle prestazioni delle pagine grandi sono principalmente causati dal numero ridotto di mancati riscontri nel TLB (Translation Lookaside Buffer). TLB mappa un intervallo più ampio di memoria virtuale e così effettua questo miglioramento.
Il supporto di pagine ampie deve essere disponibile nel kernel, ed abilitato, per consentire a Java ad utilizzare le pagine ampie.
Per configurare l'allocazione di memoria di pagine grandi, accertarsi prima che il kernel in esecuzione supporti le pagine grandi. Verificare che il file/proc/meminfo contenga le righe seguenti:
HugePages_Total: <numero di pagine> HugePages_Free: <numero di pagine> Hugepagesize: <dimensione pagina, in kB>
Il numero di pagine disponibile e la relativa dimensione varia tra le distribuzioni.
Se non è disponibile un supporto per pagine ampie nel kernel, tali righe non esisteranno nel file /proc/meminfo. In tal caso, occorre installare un nuovo kernel che contiene il supporto per pagine grandi.
Se il supporto per pagine grandi è disponibile, ma non abilitato, HugePages_Total sarà uguale a 0. In tal caso, l'amministratore deve abilitare il supporto per pagine grandi. Verificare il manuale del sistema operativo per ulteriori informazioni.
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. Se si configura il numero di pagine grandi all'avvio, verranno create in modo contiguo.
Le allocazioni di pagine grandi avrà esito positivo se JVM ha le autorizzazioni di accesso di root. Per utilizzare pagine ampie, lanciare Java come root oppure impostare il bit suid del launcher Java.
La Piattaforma Java, Standard Edition (JSE) supporta, come minimo, le specifiche definite nel documento di conformità prodotto da Sun. In alcuni casi, l'IBM JSE ORB supporta versioni più recenti delle specifiche.
Le specifiche minime supportate vengono definite nelleSpecifiche Ufficiali del supporto CORBA in Java SE 6.
Tale SDK supporta tutte le versioni di GIOP, come definito nei capitoli 13 e 15 delle specifiche CORBA 2.3.1, documento OMG formal/99-10-07.
http://www.omg.org/cgi-bin/doc?formal/99-10-07
GIOP bidirezionale non è supportato.
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 dei ganci posti nei servizi ORB che ORB può utilizzare per intercettare il normale flusso di esecuzione di ORB.
Tale 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 che viene utilizzata dal Transient Name Server ( il comando tnameserv), quando non viene fornito alcun parametro ORBInitialPort, è cambiato da 900 a 2809, ossia il numero della porta registrato con la IANA (Internet Assigned Number Authority) per il Servizio di Assegnazione Nomi di CORBA. I programmi dipendenti da questi valori predefiniti, per lavorare con questa versione, potrebbero aver bisogno di essere aggiornati.
Il contesto iniziale che viene restituito dal Transient Name Server è ora un org.omg.CosNaming.NamingContextExt. I programmi esistenti che riducono il riferimento ad un contesto org.omg.CosNaming.NamingContext funzionano comunque e non hanno bisogno di essere ricompilati.
L'ORB supporta i parametri -ORBInitRef e -ORBDefaultInitRef definiti dalla specifica dell'Interoperable Naming Service, e l'operazione ORB::string_to_object ora supporta i formati di stringa ObjectURL (corbaloc: e corbaname:) definiti dalla specifica dell'Interoperable Naming Service.
L' OMG specifica un metodo ORB::register_initial_reference per registrare un servizio con l'Interoperable Naming Service. Tuttavia, questo metodo non è disponibile in Sun Java Core API suVersione 6. I programmi che necessitano di registrare un servizio nella versione attuale devono richiamare questo metodo sulla classe di implementazione interna ORB di IBM. Ad esempio, per registrare un servizio "MyService":
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MyService", serviceRef);
Dove orb è un'istanza di org.omg.CORBA.ORB, che viene restituita da ORB.init(), e serviceRef è un oggetto CORBA, che viene connesso a ORB. Questo meccanismo è temporaneo, e non è compatibile con future versioni né trasportabile su ORB non IBM.
Una funzione di debug al momento dell'esecuzione fornisce funzionalità potenziate. Potrebbe accadere di rilevare problemi diagnostici po potrebbe essere richiesto dal personale di assistenza IBM.
Ad esempio, per rintracciare degli eventi e dei messaggi dalla riga di comando, 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 il tracciamento è stato disattivato, FFDC (First Failure Data Capture) sta ancora lavorando, per cui gli errori gravi vengono riferiti. Se viene generato un file di output del debug, esaminarlo per verificare il problema. Ad esempio, il server potrebbe essersi fermato senza eseguire unORB.shutdown().
Il contenuto e il formato dell'output di traccia potrebbero variare da versione a versione.
L'ORB può essere messo a punto in modo da lavorare bene con il proprio specifico network. Le proprietà necessarie per mettere a punto l'ORB vengono qui descritte.
Per disabilitare la frammentazione, impostare la dimensione del frammento su 0 byte:
java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
Quando si esegue un Java SecurityManager, richiamare alcuni metodi nelle classi CORBA API potrebbe determinare l'esecuzione di controlli delle autorizzazioni, che possono comportare una 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 resolve |
org.omg.CORBA.ORB | connect | java.net.SocketPermission listen |
org.omg.CORBA.ORB | resolve_initial_references | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | _is_a | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | _non_existent | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | OutputStream _request (Stringa, boolean) | java.net.SocketPermission connect |
org.omg.CORBA. portable.ObjectImpl | _get_interface_def | java.net.SocketPermission connect |
org.omg.CORBA. Request | invoke | java.net.SocketPermission connect |
org.omg.CORBA. Request | send_deferred | java.net.SocketPermission connect |
org.omg.CORBA. Request | send_oneway | java.net.SocketPermission connect |
javax.rmi. PortableRemoteObject | narrow | java.net.SocketPermission connect |
Lista delle classi delle implementazioni ORB.
Le classi di implementazione ORB in questa versione 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 nelle prossime versioni.
La RMI (Remote Method Invocation) di Java fornisce un meccanismo semplice per la programmazione distribuita di Java. RMI over IIOP (RMI-IIOP) utilizza il Protocollo IIOP (Internet Inter-ORB Protocol) standard del CORBA (Common Object Request Broker Architecture) per estendere la base della RMI di Java per eseguire la comunicazione. Ciò consente una interazione diretta con qualsiasi altro ORB (Object Request Broker) di CORBA, sia che sia 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 pooling delle connessioni implementato a livello RMI TCPTransport, impostare l'opzione
-Dsun.rmi.transport.tcp.connectionPool=true
Questa versione dell'Ambiente di Runtime 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 per possibili futuri utilizzi da IBM ed è attualmente considerata disapprovata. Migrare il codice Java esistente in modo da usare java.math.BigDecimal.
Il nuovo java.math.BigDecimal utilizza gli stessi metodi sia del java.math.BigDecimal che del com.ibm.math.BigDecimal precedenti. Il codice esistente che utilizza java.math.BigDecimal continua a lavorare correttamente. Le due classi non serializzano.
Per migrare il codice Java esistente perché utilizzi la classe java.math.BigDecimal, modificare l'istruzione di importazione in alto nel proprio file .java da: import com.ibm.math.*; a import java.math.*;.
Il plug-in Java viene utilizzato per eseguire applicazioni Java all'interno del browser. L'appletviewer viene utilizzato per testare le applicazioni progettate per l'esecuzione in un browser. Java Web Start consente di distribuire le applicazioni desktop Java in rete e fornisce un meccanismo per mantenerle aggiornate.
Il plug-in Java è un plug-in per browser Web. Il plug-in Java consente l'esecuzione di applet nel browser.
È necessario consentire agli applet di terminare il caricamento per impedire al browser di rimanere bloccato. Ad esempio, se si utilizza il pulsante Indietro e quindi quello Avanti mentre si sta caricando un applet, è possibile che le pagine HTML non possano essere caricate.
Il plug-in Java Plug-in è documentato da Sun all'indirizzo: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.
Il plug-in Java supporta SeaMonkey, Mozilla, e Mozilla Firefox.
Browser | Versioni supportate |
---|---|
Mozilla | 1.7.12, 1.8 |
Firefox | 1.5, 2.0 |
Browser | Versioni supportate |
---|---|
Mozilla | 1.6 |
|SeaMonkey | |1.0.8 |
Sono inoltre supportate release minori successive dei browser.
Per installare il plug-in Java, stabilire un collegamento simbolico con la directory dei plug-in del proprio browser.
Il plug-in Java è basato sull'iniziativa Open JVM Integration di Mozilla, utilizzata con la maggior parte dei prodotti Mozilla e derivati, incluso Firefox.
Di seguito vengono fornite istruzioni sull'installazione del plug-in su alcuni browser comuni.
È necessario collegare simbolicamente il plug-in, anziché copiarlo, per consentirgli di individuare la JVM.
È supportato solo Mozilla 1.4 e versioni successive.
cd /usr/local/mozilla/plugins/
cd $HOME/.mozilla/plugins
ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .Dove <arch> è l'architettura del proprio sistema.
Per verificare che il Plug-in di Java sia disponibile ed abilitato, selezionare Help -> About Plug-ins in Mozilla.
È necessario collegare simbolicamente il Plug-in, anziché copiarlo, per consentirgli di individuare la JVM.
Queste istruzioni renderanno il plug-in di Java disponibile per tutti gli utenti
cd /usr/local/mozilla-firefox/plugins/
ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .Dove <arch> è l'architettura del proprio sistema.
È necessario collegare simbolicamente il plug-in, anziché copiarlo, per consentirgli di individuare la JVM.
A causa delle limitazioni in particolari browser, si potrebbe non riuscire ad implementare tutte le funzioni del pacchetto org.w3c.dom.html.
Verrà lanciato uno degli errori seguenti:
Il plug-in di Java supporta caratteri a doppio byte (per esempio, il cinese tradizionale BIG-5, il coreano, il giapponese) come parametri per le tag <APPLET>, <OBJECT> e <EMBED>. necessario selezionare la corretta codifica del carattere per il proprio documento HTML, in modo che il plug-in Java possa analizzare il parametro.
Specificare la codifica dei caratteri per il documento HTML utilizzando la tag <META> nella sezione <HEAD>, come riportato di seguito:
<meta http-equiv="Content-Type" content="text/html; charset=big5">
Questo esempio indica al browser di utilizzare la codifica caratteri cinese BIG-5 per l'analisi del file HTML.
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 avviare un applet con l'Applet Viewer.
Da un shell prompt, immettere:
appletviewer <name>
dove <name> è uno dei seguenti:
Ad esempio, per richiamare l'Applet Viewer su un file HTML che richiama un'applet, digitare su una shell prompt:
appletviewer $HOME/<filename>.html
Dove filename è il nome del file HTML.
Per richiamare l'Applet Viewer su una pagina Web, digitare in un shell prompt:
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 viene codificato come predefinito del sistema, potrebbe verificarsi un'eccezione I/O. Per evitare l'eccezione, utilizzare l'opzione -encoding quando viene avviato l'appletviewer. Ad esempio:
appletviewer -encoding JISAutoDetect sample.html
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 su come eseguire il debug delle applet usando Applet Viewer si trova sul sito Web di Sun: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.
Java Web Start viene utilizzato per il deployment dell'applicazione di Java.
Web Start consente di lanciare e gestire le applicazioni direttamente dal Web. Le applicazioni vengono dotate di cache per ridurre al minimo i tempi di installazione. Le applicazioni vengono aggiornate automaticamente quando le nuove versioni diventano 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 la politica di raccolta dei dati obsoleti.
Per informazioni sui browser che supportano il Web Start, consultare Browser Supportati.
Per ulteriori informazioni su Web Start, consultare:
Per ulteriori informazioni sulle applicazioni di deploying, consultare:
Web Start può essere eseguito da una pagina Web o dalla riga comandi. Le applicazioni Web Start sono memorizzate nella cache delle applicazioni Java.
Java Web Start Versione 6 viene installato automaticamente quando si installa Java utilizzando i pacchetti .rpm o .tgz. Se si estrae Java dal pacchetto .tgz avviare lo shell script jre/lib/javaws/updateSettings.sh, per aggiornare i file .mailcap e .mime.types sul proprio sistema.
possibile richiamare il Web Start in una serie di modi diversi.
javaws <URL>Dove <URL> è la posizione di un file .jnlp.
/opt/ibm/java-i386-60/jre/bin/javaws| -viewer
Tutte le applicazioni di Web Start Java sono memorizzate nell'Application Cache Java. Un'applicazione viene scaricata soltanto se la versione più recente non si trova nella cache.
Il versioning statico consente alle applicazioni Web Start di richiedere una versione della JVM specifica in cui eseguire. Poiché tale capacità consente alle applicazioni anche di sfruttare i punti deboli della vecchia security su sistemi che sono stati aggiornati ad una nuova JVM, l'SSV (Secure Static Versioning) viene ora usato per impostazione predefinita.
Con l'SSV, l'utente verrà avvisato prima di eseguire qualsiasi applicazione Web Start non firmata che richieda l'uso di una specifica JVM. Le applicazioni firmate e le applicazioni che richiedono l'ultima versione della JVM vengono eseguite come normali.
possibile disabilitare l'SSV impostando la proprietà deployment.javaws.ssv.enabled nel deployment.properties su false.
Le applicazioni Java si compongono tipicamente di file di classi, di risorse e di dati.
Quando viene inviata un'applicazione Java, il proprio pacchetto software consiste probabilmente delle parti seguenti:
Per eseguire l'applicazione, occorre Ambiente di Runtime per Linux. Il software SDK per Linux contiene un Ambiente di Runtime. Tuttavia, non si può presumere che i propri utenti abbiano il SDK del software Linux installato.
La propria SDK della licenza softwareLinux non consente di redistribuire alcuno dei file di SDK con la propria applicazione. Occorre assicurarsi che sia installata una versione su licenza di SDK per Linux sulla macchina di destinazione.
La condivisione dei dati delle classi consente a più JVM di condividere un singolo spazio nella memoria.
La Java Virtual Machine (JVM) consente di condividere i dati delle classi fra le JVM memorizzandoli in un file di cache su disco mappato in memoria. La condivisione riduce il consumo della memoria virtuale complessiva quando una cache viene condivisa da più di una JVM. La condivisione riduce inoltre il tempo di avviamento di una JVM dopo che è stata creata la cache. La cache della classe condivisa è indipendente da qualsiasi JVM attiva e persiste finché non viene distrutta.
Una cache condivisa può contenere:
La condivisione dei dati delle classi offre un metodo trasparente per ridurre lo spazio di memoria occupato e migliorare il tempo di avvio della JVM. |Java 6 |offre funzioni nuove e migliorate di gestione cache, isolamento e prestazioni.
Abilitare la condivisione dei dati della classe utilizzando l'opzione -Xshareclasses all'avvio di una JVM. La JVM si connetterà ad una cache esistente o creerà una nuova cache se non ne esiste una.
Tutte le classi del bootsptrap e dell'applicazione caricate dalla JVM vengono condivise per default. I classloader personalizzati condividono le classi automaticamente se estendono il classloader dell'applicazione; altrimenti, devono utilizzare l'API Helper di Java fornita con la JVM per accedere alla cache. (Consultare Adattamento dei class loader personalizzati per la condivisione di classi.)
|Inoltre la JVM può memorizzare in cache codice compilato in anticipo (AOT "ahead-of-time") per alcuni metodi, per migliorare il tempo di avvio delle successive JVM. Il codice compilato AOT non viene effettivamente condiviso tra le JVM, ma viene memorizzato in cache per ridurre il tempo di compilazione all'avvio della JVM. La quantità di codice AOT memorizzato nella cache viene determinata in modo euristico. Non è possibile determinare quali metodi verranno memorizzati in cache, ma è possibile impostare limiti superiori e inferiori per la quantità di spazio di cache utilizzato per il codice AOT, oppure scegliere di disabilitare completamente l'AOT. |Consultare Abilitazione e configurazione della condivisione dei dati delle classi per maggiori informazioni.
|Una JVM può accedere alla cache in lettura e scrittura oppure in sola lettura. Qualsiasi JVM connessa a una cache con accesso in lettura e scrittura può aggiornare la cache. Qualsiasi numero di JVM può leggere dalla cache contemporaneamente, anche quando un'altra JVM sta scrivendo sulla cache.
Prestare molta attenzione se viene utilizzata la modifica del bytecode di avvio. Fare riferimento a Modifiche bytecode al runtime per ulteriori informazioni.
Poiché la cache della classe condivisa persiste oltre il ciclo vitale di qualsiasi JVM, essa viene aggiornata dinamicamente per riflettere le modifiche eventualmente apportate alle JAR o alle classi nel file system. L'aggiornamento dinamico rende la cache trasparente all'applicazione che la utilizza.
L'accesso alla cache della classe condivisa è limitato ai permessi del sistema operativo ed ai permessi di sicurezza di Java. La cache della classe condivisa viene creata per impostazione definitiva a meno che non venga utilizzata l'opzione secondaria groupAccess della riga comandi. Solo un classloader che si sia registrato per condividere i dati della classe può aggiornare la cache della classe condivisa.
|La memoria di cache è protetta contro l'alterazione accidentale o volontaria dei dati grazie alla protezione delle pagine di memoria. Non si tratta di una garanzia assoluta contro l'alterazione dei dati, in quanto la JVM deve togliere la protezione alle pagine per scrivere nella cache. L'unico modo per garantire che una cache non possa essere modificata è aprirla in sola lettura.
Se è stato installato un Java SecurityManager, i classloader, ad esclusione dei classloader predefiniti di bootstrap, dell'applicazione e dell'estensione, devono avere il permesso di condividere le classi aggiungendo righe di SharedClassPermission al file java.policy. (Consultare Utilizzo di SharedClassPermission.) La RuntimePermission "createClassLoader" pone restrizioni alla creazione di nuovi classloader e quindi limita 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 è in grado di connettersi ad una sola cache alla volta.
È possibile sostituire le dimensioni predefinite della cache all'avvio utilizzando -Xscmx<n><size>; tali dimensione saranno quindi fissate per l'intera durata della cache. Le cache esistono finché non vengono distrutte esplicitamente utilizzando un'opzione secondaria del comando -Xshareclasses oppure eliminando manualmente il file di cache.
Tutti i programmi di utilità della cache sono opzioni secondarie del comando -Xshareclasses. Fare riferimento a Abilitazione e configurazione della condivisione dei dati delle classi, o utilizzare -Xshareclasses:help per visualizzare una lista di opzioni secondarie disponibili.
La condivisione dei dati delle classi e le utility di gestione cache vengono controllate mediante opzioni di riga comandi del launcher java.
Per le opzioni che assumono un parametro <size>, aggiungere come suffisso al numero il carattere "k" o "K" per indicare i kilobyte, "m" o "M" per indicare i megabyte, oppure "g" o "G" per indicare i gigabyte.
Alcune utility cache possono interagire con versioni precedenti di Java o con cache create da JVM con larghezze in bit diverse. Queste cache vengono dettecache "incompatibili".
possibile utilizzare le seguenti opzioni secondarie con l'opzione -Xshareclasses:
Visualizza informazioni dettagliate sulla 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 inoltre elencato il codice AOT per i metodi di classe.
Guida alla Diagnostica per ulteriori informazioni.
Panoramica del ciclo vitale di una cache di dati delle classi condivise, comprensiva di esempi delle utility di gestione cache.
Per abilitare la condivisione dei dati della classe, aggiungere -Xshareclasses[:name=<name>] alla riga di comandi della propria 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ù VM, tutte popoleranno contemporaneamente la cache.
Per verificare che la cache sia stata creata, eseguire java -Xshareclasses:listAllCaches. Per visualizzare quante classi e quanti dati delle classi vengono condivisi, eseguire java -Xshareclasses:[name=<name>],printStats. (Tali utility possono essere eseguite dopo che la JVM dell'applicazione è terminata, oppure in un'altra finestra dei comandi.)
Per maggiori feedback sull'utilizzo della cache mentre la JVM è in esecuzione, utilizzare l'opzione secondaria verbose. Ad esempio, java -Xshareclasses:[name=<name>],verbose.
Per visualizzare le classi caricate dalla cache o memorizzate nella cache, aggiungere -Xshareclasses:[name=<name>],verboseIO alla riga comandi della propria 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 della cache è quello di specificare una cache ampia (utilizzando -Xscmx), di eseguire l'applicazione e quindi di utilizzare printStats per determinare la quantità di dati della classe che è stata memorizzata. Aggiungere una piccola quantità al valore mostrato in printStats. Da notare che, poiché le classi possono essere caricate in qualsiasi momento nel corso della vita della JVM, la cosa migliore è eseguire tale analisi dopo che l'applicazione è terminata. Tuttavia, una cache completa non ha un impatto negativo sulle prestazioni o sulla capacità delle JVM connesse, per cui è assolutamente legittimo decidere sulla dimensione di una cache più piccola di quella richiesta.
Se una cache si riempie, viene emesso un messaggio sulla riga comandi delle JVM che utilizzano l'opzione secondaria verbose. Tutte le JVM che condividono la cache completa caricheranno tutte le altre classi nella loro memoria di processo. Le classi in una cache piena possono essere condivise, ma una cache piena è di sola lettura e non può essere aggiornata con nuove classi.
La condivisione dei dati della classe è particolarmente utile per i sistemi che utilizzano più di una JVM che esegue un codice simile; il sistema beneficia del ridotto consumo della memoria virtuale. utile inoltre per i sistemi che frequentemente avviano ed arrestano le JVM, che beneficiano del miglioramento dei tempi di avviamento.
Il sovraccarico per creare e popolare una nuova cache è minimo. I tempi di avvio della JVM per una singola JVM sono di norma dallo 0 al 5% più lenti rispetto a quelli di un sistema che non utilizza la condivisione dei dati della classe, a seconda del numero di classi che viene caricato. Il miglioramento dei tempi di avvio della JVM tramite una cache popolata di norma accelera i tempi dal 10% al 40% rispetto ad un sistema che non utilizza la condivisione dei dati della classe, a seconda del sistema operativo e del numero di classi caricate. Più JVM in esecuzione contemporanea mostreranno benefici complessivi maggiori nei tempi di avvio.
Le classi duplicate vengono consolidate all'interno della cache delle classi condivise. Ad esempio, la classe A caricata da myClasses.jar e la classe A caricata da myOtherClasses.jar (con contenuto identico) vengono memorizzate una sola volta nella cache. L'utility printAllStats mostra voci multiple per le classi duplicate, con ciascuna voce che punta alla stessa classe.
Quando si esegue un'applicazione con la condivisione dei dati della classe, è possibile utilizzare gli strumenti del sistema operativo per visualizzare la riduzione del consumo della memoria virtuale.
Fattori da considerare quando si distribuisce la condivisione dei dati delle classi in un prodotto e si utilizza la condivisione dei dati delle classi in un ambiente di sviluppo.
La dimensione teorica massima della cache è di 2 GB. La dimensione della cache che è possibile specificare è limitata dalla quantità di memoria fisica e dallo spazio di paging disponibile nel sistema.
La cache per la condivisione delle classi viene allocata con il meccanismo System V IPC Shared Memory.
Poiché lo spazio di indirizzamento virtuale di un processo viene condiviso fra la cache delle classi condivise e l'heap Java, aumentando la dimensione massima dell'heap Java è possibile che venga ridotta la dimensione della cache delle classi condivise che è possibile creare.
La dimensione della cache è limitata dall'impostazione SHMMAX, che limita la quantità di memoria condivisa che è possibile allocare. possibile reperire tali impostazioni nel file /proc/sys/kernel/shmmax. SHMMAX è di solito impostato a 30 MB.
Qualsiasi JVM che utilizzi un agent JVMTI (JVM Tool Interface) in grado di modificare i dati del bytecode deve usare l'opzione secondaria modified=<modified_context> se vuole 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 effettua la partizione della cache, così che tutte le JVM che funzionano nello stesso contesto condividono una partizione.
Tale partizionamento consente alle JVM che non usano il bytecode modificato di condividere in sicurezza una cache con quelle che usano il bytecode modificato. Tutte le JVM che utilizzano un dato contesto modificato devono modificare il bytecode in modo prevedibile e ripetibile per ciascuna classe, in modo che che le classi modificate memorizzate nella cache abbiano le modifiche previste quando vengono caricate da un'altra JVM. Qualsiasi modifica deve essere prevedibile, in quanto le classi caricate dalla cache della classe condivisa non possono essere modificate nuovamente dall'agente.
Se un agent JVMTI viene utilizzato senza un contesto di modifica, le classi sono ancora condivise in sicurezza dalla JVM, ma con un impatto minimo sulle prestazioni. Utilizzare un contesto di modifica con un agente JMVTI evita la necessità di controlli extra e quindi non incide sulla prestazione. Un ClassLoader personalizzato che estende java.net.URLClassLoader e modifica il bytecode in load-time senza usare la JVMTI memorizza automaticamente quel bytecode modificato nella cache, ma la cache non tratta il bytecode come modificato. Qualsiasi altra VM che condivide quella cache carica le classi modificate. L'opzione secondaria modificata=<modification_context> può essere utilizzata nello stesso modo in cui si utilizza con gli agenti JVMTI per effettuare la partizione del bytecode modificato nella cache. Se un ClassLoader personalizzato necessita di effettuare modifiche in load-time imprevedibili alle classi, quel ClassLoader non deve tentare di utilizzare la condivisione dei dati della classe.
Consultare Guida alla Diagnostica per ulteriori informazioni su questo argomento.
Non è possibile condividere classi tra JVM a 32 e 64 bit. Deve essere disponibile spazio temporaneo su disco sufficiente a contenere le informazioni di cache. Le autorizzazioni relative alle cache vengono applicate dal sistema operativo.
Per sistemi operativi che possono eseguire applicazioni sia a 32 bit che a 64 bit, non è consentita la condivisione di classi tra le JVM a 32 bit e quelle a 64 bit. L'opzione secondaria listAllCaches elencherà le cache a 31 bit e quelle a 64 bit, a seconda del modo di indirizzo della JVM utilizzata.
La cache delle classi condivise richiede spazio su disco per memorizzare le informazioni di identificazione relative alle cache esistenti sul sistema. Queste informazioni vengono memorizzate in /tmp/javasharedresources. Se la directory delle informazioni sulla identificazione, la JVM non è in grado di identificare le classi condivise sul sistema e deve ricreare la cache. Utilizzare il comando ipcs per visualizzare i segmenti utilizzati da una JVM o da un'applicazione.
Gli utenti che eseguono una JVM devono trovarsi nello stesso gruppo per utilizzare una cache di classi condivise. Le autorizzazioni per l'accesso a una cache delle classi condivise vengono applicate dal sistema operativo. Se un nome della cache non è specificato, il nome utente viene aggiunto al nome predefinito così che più utenti sullo stesso sistema creino la loro cache per impostazione predefinita.
Se un SecurityManager viene utilizzato con la condivisione dei dati della classe e l'applicazione in esecuzione utilizza i propri class loader, a tali class loader devono essere concessi i permessi della classe condivisa prima che possano condividere le classi.
Occorre aggiungere i permessi della classe condivisa al file java.policy utilizzando il nome della classe ClassLoader (sono permessi i metacaratteri) e "read", "write", oppure "read,write" per determinare l'accesso consentito. Ad esempio:
permission com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", "read,write";
Se un ClassLoader non ha le giuste autorizzazioni, non gli sarà concesso di condividere le classi. Non è possibile modificare le autorizzazioni dei classloader di bootstrap, dell'applicazione, o dell'estensione.
Tutti i classloader che estendono java.net.URLClassLoader possono condividere le classi senza modifiche. I classloader che non estendono java.net.URLClassLoader devono essere adattati per condividere i dati di classe.
A tutti i classloader personalizzati devono essere assegnate autorizzazioni per le classi se viene utilizzato un SecurityManager; consultare Utilizzo di SharedClassPermission. IBM fornisce numerose interfacce Java per diversi tipi di classloader personalizzati, che consentono ai classloader di individuare e memorizzare classi nella cache di classi condivise. Queste classi si trovano nel pacchetto com.ibm.oti.shared.
Il Javadoc per questo pacchetto viene fornito con l'SDK nella directory docs/content/apidoc.zip.
Consultare la Guida alla Diagnostica per ulteriori informazioni sull'utilizzo di queste interfacce.
Il pacchetto API Java Communications (JavaComm) è un pacchetto opzionale fornito per l'uso con Runtime Environment per Linux sulle piattaforme IA32, PPC32/PPC64 e AMD64/EM64T. JavaComm viene installato indipendentemente da SDK o da Runtime Environment.
L'API di JavaComm dà alle applicazioni Java un modo indipendente dalle piattaforme di eseguire le comunicazioni tra porte seriali e parallele per tecnologie come voice mail, fax e smartcard.
L'API Java Communications supporta le porte seriali dell'EIA (Electronic Industries Association) -232 (RS232) e le porte parallele dell'IEEE (Institute of Electrical and Electronics Engineers) 1284 ed è supportata sui sistemi con l'Ambiente di Runtime IBM Versione 6.
Utilizzando l'API Java Communications, è possibile:
Accertarsi che una copia di SDK o di Runtime Environment sia installata prima di installare l'API Java Communications.
Se si utilizza inizialmente il pacchetto RPM per installare Java, occorre installare l'API Java Communications dal file RPM. Per installare l'API Java Communications da un pacchetto RPM, consultare Installazione delle API Java Communications da un file RPM.
Per installare l'API Java Communications da un file compresso:
tar -xvzf ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz
Dove <arch> indica la propria architettura: i386, x86_64, ppc o ppc64.
Assicurarsi di aver installato una copia dell'SDK o dell'Ambiente di Runtime prima di installare le API Java Communications.
Se si utilizza inizialmente il pacchetto RPM per installare Java, occorre installare le API Java Communications dal file RPM.
rpm -ivh ibm-javacomm-3.0-0.0.<arch>.rpmL'API Java Communications è installata all'interno della struttura della directory /opt/ibm/java-i386-60/.
Per default, i file API di Java Communications sono installati nella directory /opt/ibm/java-i386-60/. I file e la loro struttura sono:
Per usare l'API Java Communications, è necessario modificare la modalità di accesso delle porte seriali e parallele, e impostare la variabile PATH se non è stata impostata all'installazione di Java.
Consultare Impostazione del percorso.
Dopo aver installato le API Java Communications, è necessario modificare la modalità di accesso delle porte seriali e parallele, in modo che gli utenti possano accedere a tali dispositivi.
necessario fornire all'utente un accesso in lettura e scrittura ai dispositivi richiesti. Collegarsi come root ed usare i seguenti comandi, dove applicabili:
chmod 660 /dev/ttyS0 (conosciuto anche come porta seriale COM1) chmod 660 /dev/lp0 (conosciuto anche come porta parallela LPT1) chmod 660 /dev/ttyS1 (conosciuto anche come porta seriale COM2) chmod 660 /dev/ttyS2 (conosciuto anche come porta seriale COM3) chmod 660 /dev/ttyS3 (conosciuto anche come porta seriale COM4)
Aggiungere utenti specifici al gruppo a cui appartiene il dispositivo. Su un sistema SUSE, ad esempio, i dispositivi sono nel gruppo uucp. In tal modo, gli utenti possono essere aggiunti al gruppo uucp per acquisire l'accesso ai dispositivi.
Cambiare la modalità di accesso di una qualunque porta secondo la necessità.
Il file javax.comm.properties consente di specificare i prefissi dei dispositivi disponibili per le API Java API e se 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 i dispositivi /dev/ttyS0 e/dev/ttyS1 esistono, saranno allocati come COM1 e COM2.
Per utilizzare i connettori seriali USB, eliminare il commento dalla riga /dev/ttyUSB=PORT_SERIAL 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.
La maggior parte dei ThinkPads hanno le porte seriali disabilitate come impostazione predefinita nel BIOS. Attualmente, non esiste un modo per abilitare le porte con Linux (il pacchetto tpctl non abilita le porte se queste sono disabilitate nel BIOS).
Per abilitare le porte nel BIOS, è necessario utilizzare la versione DOS della Utility di Configurazione di ThinkPad disponibile sul sito IBM ThinkPad Download. Per usare ThinkPad Configuration Utility, è necessario un dischetto DOS riavviabile. Da notare che l'Utility di Configurazione di ThinkPad potrebbe essere stata installata come parte delle Utility di Configurazione di ThinkPad sotto Windows, a seconda delle opzioni di installazione di cui si dispone, ed è possibile avviarla da un prompt dei comandi in Windows.
L'applicazione della Configurazione ThinkPad fornita con Windows ha le opzioni per abilitare o disabilitare le porte seriali e parallele, ma ciò non modifica anche le impostazioni nel BIOS. Per cui, se si utilizza questa applicazione con Windows, le porte sono disponibili; tuttavia, se si riavvia il sistema con Linux, le porte non saranno abilitate.
Quando si stampa con le API Java Communications, potrebbe essere necessario selezionare "Alimentazione fogli", "Continua", o un'opzione similare sulla stampante.
Il processo utilizzato per disinstallare le API Java Communications dipende dall'avvenuta installazione o meno del pacchetto RPM (Red Hat Package Manager) installabile oppure del pacchetto compresso TAR (Tape Archive).
Disinstallazione delle API Java Communications utilizzando il pacchetto RPM.
rpm -e ibm-javacomm-3.0-0.0In alternativa, è possibile utilizzare un tool grafico, come per esempio kpackage oppure yast2
Disinstallazione delle API Java Communications in caso di avvenuta installazione del pacchetto TAR compresso.
Eliminare i seguenti file dalla directory in cui sono stati installati:
possibile trovare la documentazione sull API Java Communications nel sito Web di Sun.
http://java.sun.com/products/javacomm/.
Punti di riferimento per l'assistenza:
se si ha diritto a ricevere assistenza per il codice del Programma in conformità al Solutions Developer Program di IBM, contattare il Solutions Developer Program di IBM attraverso i propri usuali canali di accesso o sul seguente sito Web:http://www.ibm.com/partnerworld/.
Se è stato acquistato un contratto di servizio (cioè Personal Systems Support Line IBM oppure un servizio equivalente nel vostro paese), i termini e le condizioni di tale contratto di servizio determinano a quali servizi si ha diritto, se disponibili, rispetto al programma.
Le guide per l'utente fornite con SDK e Ambiente di Runtime sono state testate usando degli screen reader.
Per modificare le dimensioni dei font nelle guide utente, utilizzare la funzione fornita con il browser, presente di norma nella opzione del menu Visualizza.
Per gli utenti che necessitano di navigare dalla tastiera, una descrizione dei tasti utili allo scopo per le applicazioni Swing può essere reperita in Swing Key Bindings su http://www.ibm.com/developerworks/java/jdk/additional/.
Se ci si sposta lateralmente nella lista a discesa di una componente JComboBox con i tasti del cursore, il pulsante o il campo modificabile della JComboBox non cambia di valore fino a quando non si seleziona un elemento. Questo è il corretto comportamento per questa versione, che migliora l'accessibilità e l'usabilità, assicurando che il comportamento della tastiera sia coerente con quello del mouse.
Dalla Versione 5.0, il Java Web Start contiene numerosi miglioramenti all'accessibilità ed all'usabilità, incluso un migliore supporto per screen reader ed una migliorata navigazione della tastiera.
possibile usare la riga dei comandi solo per lanciare un'applicazione Java abilitata per il Web Start. Per cambiare le opzioni delle preferenze, editare il file di configurazione, .java/.deployment/.deployment.properties nella directory principale dell'utente. Prima di modificare questo file farne una copia di riserva. Non tutte le preferenze che è possibile impostare in Java Application Cache Viewer sono disponibili nel file di configurazione.
In caso di commenti relativi a questa guida utente, è possibile contattarci attraverso uno dei seguenti canali. Si noti che tali canali non sono predisposti a rispondere a domande tecniche ma sono intesi solo per i commenti relativi alla documentazione.
Inviare i commenti a:
Annotazioni. Scegliendo di inviare un messaggio alla IBM, si riconosce che tutte le informazioni contenute nel messaggio, compresi i dati di feedback, quali domande, commenti, suggerimenti o simili, saranno considerate non confidenziali e la IBM non avrà obblighi di alcun genere in merito a tali informazioni e sarà libera di riprodurre, utilizzare, rivelare, e distribuire le informazioni a terzi senza limitazioni. Inoltre, la IBM sarà libera di utilizzare idee, concetti, know-how o tecniche contenute in tali informazioni a qualsiasi scopo, inclusi, ma non limitati ad essi, lo sviluppo, la fabbricazione e la commercializzazione dei prodotti che incorporano tali informazioni.
Le opzioni -X sotto elencate sono non standard e soggette a modifica senza preavviso.
Per le opzioni che assumono un parametro <size>, aggiungere come suffisso al numero il carattere "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 un parametro <percentage>, utilizzare un numero da 0 a 1. Per esempio, 50% è 0.5.
Comporta che l'output verbose GC (garbage collection) 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 verbose GC viene indirizzato sul numero X di file, ciascuno contenente il numero Y di cicli gc valido per l'output verbose GC. Questi file hanno il formato nomefile1, nomefile2 e così via. Per impostazione predefinita, non viene eseguito alcun logging di verbose GC.
Consultare la Guida alla Diagnostica per maggiori informazioni sull'output verbose GC.
Limiti conosciuti su SDK e sull'Ambiente di Runtime per Linux.
È possibile avere un aiuto maggiore con la diagnostica dei problemi nella Diagnostics Guide all'indirizzo http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.
L'impostazione BIOS Node memory interleaving deve essere impostata su DISABLED. Altrimenti, potrebbero verificarsi esiti imprevedibili, compresi blocchi ed interruzioni di Java. Questa istruzione è conforme alle raccomandazioni di AMD.
Nel tool della JConsole di IBM, la tabella Locale, che consente di connettersi ad altre Virtual Machines sullo stesso sistema, non è disponibile. Inoltre l'opzione della riga comandi corrispondente pid non è supportata. Utilizzare invece la scheda Remoto di JConsole per collegarsi alla Virtual Machine da controllare. In alternativa, utilizzare l'opzione della riga comandi connection, specificando un host di localhost ed un numero di porta. Quando viene avviata l'applicazione da controllare, impostare le seguenti opzioni di riga comandi:
Il motore Mozilla Rhino Javascript non è incluso nell'SDK IBM per Java a causa di problemi di licenza. Per utilizzare il motore Rhino Javascript con l'SDK di 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/.
La creazione di coppie di chiavi DSA di lunghezza insolita può richiedere molto tempo su macchine lente. Non interpretare il ritardo come un blocco, in quanto il processo verrà completato se viene consentito un tempo sufficiente. 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 programmi nativi non possono creare una VM con interfacce JNI_VERSION_1_1(0x00010001). Non è possibile richiamare JNI_CreateJavaVM() e trasferirle una versione di JNI_VERSION_1_1(0x00010001). Le versioni che possono essere passate sono:
La VM creata viene determinata dalle librerie Java presenti (ossia, 1.2.2, 1.3.x, 1.4.x, 5.x, 6.x), e non da quella determinata dalla versione dell'interfaccia JNI trasferita.
La versione dell'interfaccia non influenza alcuna area della funzionalità della VM se non le funzioni disponibili sul codice nativo.
Il proprio window manager potrebbe sovrascrivere alcune delle shortcut Java della tastiera. Se si ha necessità di utilizzare una shortcut Java della tastiera sovrascritta, consultare il manuale del proprio sistema operativo e modificare le shortcut della tastiera del window manager.
X Window System non può utilizzare descrittori di file superiori a 255. Poiché la JVM conserva i descrittori di file per i file jar aperti, X può esaurire i descrittori di file. Per rimediare a questo inconveniente, è possibile impostare la variabile d'ambiente JAVA_HIGH_ZIPFDS per indicare alla JVM di utilizzare descrittori di file superiori per i file jar.
Per utilizzare la variabile d'ambiente JAVA_HIGH_ZIPFDS, impostarla su un valore compreso tra 0 e 512. La JVM aprirà quindi i primi file jar utilizzando i descrittori di file fino a 1024. Ad esempio, se il programma deve caricare 300 file jar:
export JAVA_HIGH_ZIPFDS=300
I primi 300 file saranno caricati utilizzando i descrittori di file da 724 a 1023. I file jar aperti successivamente saranno aperti nell'intervallo normale.
Si potrebbe non riuscire ad utilizzare gli Appunti del sistema con i caratteri DBCS (double byte character set) per copiare le informazioni fra le applicazioni Linux e le applicazioni Java se si sta usando il KDE (K Desktop Environment).
Su SLES9 e sulle distribuzioni più recenti, la libreria predefinita del threading è NPTL, che implementa i thread Java come thread nativi. Su distribuzioni precedenti, la libreria di threading predefinita è LinuxThreads, che implementa i thread come nuovi processi. Se il numero dei thread Java supera il numero massimo di processi consentiti, il programma potrebbe bloccarsi.
Il numero massimo dei sottoprocessi disponibili viene stabilito in base al minimo di quanto riportato di seguito:
Tuttavia, la memoria virtuale potrebbe esaurirsi prima di raggiungere il numero massimo di thread.
In questa piattaforma non è possibile in alcun modo distinguere tra tempo di CPU in modalità utente e tempo di CPU in modalità sistema. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() e ThreadMXBean.getCurrentThreadCpuTime() restituiscono tutti il tempo totale di CPU per il thread richiesto.
I risultati KeyEvent che includono la chiave Alt potrebbero variare in base ai window managers in Linux. Inoltre, variano anche dai risultati di altri sistemi operativi. Quando si utilizzano le impostazioni predefinite, Ctrl+Alt+A nel window manager KWin produce un KeyEvent, mentre Ctrl+Alt+A nel window manager Metacity non produce un evento chiave.
In Linux X Window System, la tastiera è impostata su: 64 0xffe9 (Alt_L) 0xffe7 (Meta_L), e 113 0xffea (Alt_R) 0xffe8 (Meta_R). Per abilitare tale funzione, immettere quanto segue ad una richiesta comandi shell:
xmodmap -pk
Ecco perché ilSDK considera che Meta ed Alt vengono premuti contemporaneamente. Per evitare tale problema, è possibile eliminare Meta_x, immettendo quanto riportato di seguito ad una richiesta comandi shell:
xmodmap -e "keysym Alt_L = Alt_L" -e "keysym Alt_R = Alt_R"
Tale operazione potrebbe influire su altre applicazioni X-Window in esecuzione nello stesso schermo se utilizzano il tasto Meta eliminato.
Una chiamata a JNI_CreateJavaVM() da un'applicazione JNI potrebbe causare un errore di segmentazione (segnale SIGSEGV); per evitare tale errore, ricostruire il programma JNI specificando l'opzione -lpthread.
Se si sta lavorando con una serie di thread concorrenti, si potrebbe ricevere un messaggio di avviso:
java.lang.OutOfMemoryError
Tale messaggio indica che le risorse di sistema della macchina sono in esaurimento; i messaggi possono essere determinati dalle seguenti cause:
Provare a regolare il sistema in modo da incrementare le risorse di sistema corrispondenti.
Quando si utilizza un'applicazione AWT o SwingJava su una macchina Linux e si esporta la visualizzazione su una seconda macchina, si potrebbero avere problemi di visualizzazione di alcune finestre di dialogo se il gruppo di caratteri caricati sulla client machine X è diversa dal gruppo caricato sulla macchina server X. Per evitare questo problema, installare gli stessi font su entrambe le macchine.
Se la locale del sistema sta utilizzando la decodifica UTF-8, alcuni tool dell'SDK potrebbero lanciare una sun.io.MalformedInputException. Per scoprire se il sistema sta utilizzando una decodifica UTF-8, esaminare le variabili di ambiente specifiche per la locale, come LANG o LC_ALL per vedere se terminano con il suffisso ".UTF-8". Se si riceve questa sun.io.MalformedInputException, modificare i caratteri che non si trovano all'interno del range ASCII a 7-bit (0x00 - 0x7f) e che non sono rappresentati come valori letterali di caratteri Unicode in valori letterali di caratteri Unicode di Java in valori letterali di caratteri Unicode diJava (ad esempio: '\u0080'). inoltre possibile aggirare questo problema rimuovendo il suffisso ".UTF-8" dalle variabili di ambiente specifiche della locale; ad esempio, se la propria macchina ha una locale predefinita di "en_US.UTF-8", impostare LANG su "en_US".
Se si sta utilizzando AMI e xcin in un ambiente tra varie piattaforme (ad esempio, se si tenta di esportare la visualizzazione tra un sistema a 32 bit ed un sistema a 64 bit o tra un sistema big-endian ed un sistema little-endian) si potrebbero verificare dei problemi. Se si verifica questo tipo di problema, eseguire l'upgrade all'ultima versione di AMI e xcin.
Solo per gli utenti di lingua cinese, coreana e giapponese di RHEL4.
Nessun server XIM è installato per default. Per immettere caratteri DBCS in un'applicazione Java, si prega di installare un pacchetto del server XIM come iiimf-x o kinput2.
Solo per gli utenti di lingua cinese, coreana e giapponese di RHEL4.
Se si sta utilizzando l'IIMF (Internet/Intranet Input Method Framework), utilizzare pacchetti IIIMF contenuti in Red Hat Enterprise Linux 4 Update 2 o successivi. Contattare Red Hat, all'indirizzo http://www.redhat.com.
(Solo per zSeries a 64 bit) Possono verificarsi errori IIIMF o errori di avvio. Per risolvere il problema, eseguire l'upgrade ai pacchetti IIIMF più recenti.
(Solo per cinese tradizionale su PPC, s390 o s390x) È possibile che IIIMF non funzioni. Per risolvere il problema, usare iiimf-le-xcin-0.1.7-13.EL4 o successivo.
(Solo per cinese semplificato su PPC, s390 o s390x) È possibile che IIIMF non funzioni correttamente. Per risolvere il problema, usare i pacchetti IIIMF presenti in RHEL4 Update 5 o successivo.
Solo per gli utenti in cinese semplificato RHEL4.
La locale zh_CN.GB18030 non è supportata da xlib in RHEL4. xterm non può attivare l'Input Method Server per l'immissione dei caratteri GB18030. Utilizzare invece la locale zh_CN.UTF8. Se si possiedono programmi legacy o dati codificati con GB2312, GBK, o GB18030, e si desidera migrarli a RHEL4, è necessario pre-elaborarli con iconv per convertirli in codifica UTF-8 così che i programmi possano funzionare ed i dati essere visualizzati correttamente in RHEL4 con la locale zh_CN.UTF8.
Questa limitazione viene risolta in RHEL4 U3.
È possibile che il sistema si blocchi con xcin su RHEL4. Per risolvere il problema, impostare ICCHECK_DISABLE a YES nel file /etc/chinese/xcin/xcinrc.
solo ambienti a 64-bit
Su RHEL4 con xcin (Server XIM del Cinese Tradizionale, potrebbe verificarsi un comportamento imprevisto come un errore di segmentazione con Java su ambienti a 64-bit (quali AMD64 o piattaforme zSeries a 64-bit). Per risolvere il problema, eseguire l'upgrade al pacchetto xcin più recente.
Solo RHEL4.
Quando si utilizza IIIMF (Internet Intranet Input Method Framework) per immettere caratteri DBCS, è possibile trovare problemi di cambiamento del fuoco. Il problema si verifica quando si minimizzano le componenti di input attive. Dopo aver ripristinato la componente, il metodo di immissione torna all'SBCS. I DBCS devono quindi essere riattivati manualmente.
Le seguenti componenti presentano questo problema di cambiamento di fuoco:
Solo per RHEL4 e SLES9 only
Per gli utenti di lingua Giapponese, Cinese e Coreano, non è possibile utilizzare XIM per immettere i propri caratteri in componenti di testo su un'applet Java in un browser Web. Questa limitazione avviene perché XEmbed richiede una fix per il file di libreria X11. Per aggirare la situazione, specificare il parametro del sistema -Dsun.awt.noxembed=true per disabilitare XEmbed. È possibile impostare questa opzione utilizzando il pannello di controllo:
Questa limitazione viene risolta in RHEL4 U3 e SLES9 SP3.
Solo piattaforme Intel a 32-bit
Per gli utilizzatori di testi in arabo, quando si utilizza Linux con una scheda video Matrox e l'accelerazione è abilitata, la distorsione dei caratteri può essere possibile quando si utilizza drawString per visualizzare caratteri grandi. Questo problema è causato dal driver per queste schede. Il metodo consigliato per aggirare questo problema è la disabilitazione dell'accelerazione per la periferica.
Solo piattaforme Intel a 32-bit
Su SLES 9 NPTL, il driver della porta parallela causa un blocco del kernel e l'arresto di un thread di Java. La JVM rileva questo blocco nel tentativo di sospendere il thread della Garbage Collection e poi si blocca in modo anomalo, producendo un file di base ed il messaggio "JVMLH030: i thread scompaiono quando si tenta di sospenderli".
Il prospetto SUSE Bugzilla 47947 viene emesso rispetto a questo problema. Tale bug viene corretto in SLES 9 Service Pack 1.
Solo piattaforme PPC
Se il proprio codice Java utilizza le chiamate JNI, e tutte le chiamate specifiche hanno più di otto parametri mobili o doppi, il proprio codice C deve essere compilato con il livello gcc-2.95.3 Free Software Foundation (FSF) del Compilatore GNU C (GCC).
Solo piattaforme PPC
Il pacchetto JavaComm non supporta le operazioni della porta parallela sui kernel SLES 9 GA e SP1. Tale limitazione viene risolta nel kernel SP2. Il numero SUSE Bugzilla è 50028.
Solo piattaforme PPC a 64-bit
Il compilatore gcc cross predefinito (versione 3.2-49) causa vari errori. Per generare la libreria condivisa libFileStat.so, avviare:
/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<SDK_PATH>/include FileStat.c
dove <SDK_PATH> è il percorso verso la directory installata dell'SDK.
Solo piattaforme zSeries
Sebbene il kernel Linux nelle distribuzioni attuali fornisca il supporto per l' IPv6 (Internet Protocol version 6), potrebbero verificarsi problemi quando lo si utilizza. Il supporto per l'IPv6 di Java è incluso in questa versione, ma è consigliabile disattivarlo con l'opzione -Djava.net.preferIPv4Stack=true sul comando java. Se viene installato un kernel che supporta completamente l'IPv6, questa opzione non è necessaria.
Solo piattaforme zSeries a 64-bit
Il server del metodo di input Cinese e Taiwanese (xcin) non è stato testato.
L'API Desktop Java può non funzionare in quanto una o più librerie di GNOME non sono disponibili.
Solo ambienti DBCS
Se un'applicazione riporta un errore con eccezione NullPointerException quando si utilizza il Look and Feel GTK, disabilitare la variabile d'ambiente GNOME_DESKTOP_SESSION_ID.
Solo utenti Giapponesi
L'alias del codepage unicode "\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe" per Shift_JIS è stato rimosso. Se si utilizza tale codepage nelle proprie applicazioni, sostituirlo 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 discusse in questo documento in altri paesi. Consultare il proprio rappresentante IBM locale per avere informazioni sui prodotti ed i servizi disponibili nel proprio paese.
Qualsiasi riferimento a prodotti, programmi o servizi IBM non è inteso a dichiarare o sottintendere che è consentito utilizzare solo prodotti, programmi o servizi IBM. possibile utilizzare qualsiasi prodotto, programma o servizio equivalente dal punto di vista delle funzioni, a condizione che non violi i diritti di proprietà intellettuale della IBM. Tuttavia, è responsabilità dell'utente valutare e verificare la possibilità di usare programmi, prodotti o servizi non IBM.
La IBM ha facoltà di avere brevetti o applicazioni in attesa di brevetto relativi a quanto trattato in questo 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 di delucidazioni sulla licenza relativa al double-byte (DBCS), si prega di contattare l'IBM Intellectual Property Department nel proprio paese o di inviare richieste scritte a:
Il seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui leggi nazionali siano in contrasto con le disposizioni in esso contenute:
L'IBM FORNISCE QUESTA PUBBLICAZIONE SENZA ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI GARANZIE DI COMMERCIABILITÀ' ED IDONEITÀ' AD UNO SCOPO PARTICOLARE. Alcune nazioni non escludono le garanzie implicite; di conseguenza la suddetta esclusione potrebbe, in questo caso, non essere applicabile.
Queste informazioni potrebbero contenere imprecisioni tecniche o errori tipografici. Le correzioni relative saranno incluse nelle nuove edizioni. IBM si riserva il diritto di apportare miglioramenti e/o modifiche ai prodotti e/o ai programmi descritti in questa informativa in qualsiasi momento e senza preavviso.
Tutti i riferimenti a pubblicazioni e a siti Web non dell'IBM contenuti in questo documento sono forniti solo per consultazione. I materiali in tali siti Web non fanno parte dei materiali di questo prodotto IBM e l'uso di tali siti è a proprio rischio.
L'IBM si riserva il diritto di utilizzare o distribuire qualsiasi informazione fornita in qualsiasi modo lo ritenga opportuno senza incorrere in alcuna obbligazione verso terzi.
Coloro che detengono la licenza su questo programma e desiderano avere informazioni su di esso allo scopo di consentire: (i) uno scambio di informazioni tra programmi indipendenti ed altri (compreso questo) e (ii) l'uso reciproco di tali informazioni, dovrebbero rivolgersi a:
Queste informazioni possono essere rese disponibili secondo condizioni contrattuali appropriate, compreso, in alcuni casi, l'addebito di un canone.
Il programma su licenza descritto in questo documento e tutto il materiale su licenza disponibile sono forniti dalla IBM in base ai termini dell'IBM Customer Agreement, dell'IBM International Program License Agreement o di qualsiasi 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 non state effettuate tramite estrapolazione. Pertanto, i risultati effettivi possono essere differenti. Gli utenti devono verificare l'applicabilità dei dati negli specifici ambienti operativi.
Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di tali prodotti, dai loro annunci al pubblico o da altre fonti disponibili pubblicamente. La IBM non ha testato tali prodotti e non è in grado di confermare l'accuratezza delle prestazioni, la compatibilità o qualsiasi altro reclamo relativo a prodotti non IBM. Eventuali commenti relativi alle prestazioni dei prodotti non IBM devono essere indirizzati ai fornitori di tali prodotti.
IBM, iSeries, pSeries e zSeries sono marchi della International Business Machines Corporation.
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.
Linux è un marchio della Linus Torvalds.
I nomi di altre società, prodotti e servizi potrebbero essere marchi di altre società.