SDK IBM SDK per piattaforme Linux, Java Technology Edition, Versione 6

Guida a SDK e Runtime Environment



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

Indice

Prefazione
Panoramica
Convenzioni
Compatibilità versione
Migrazione da altre JVM di IBM
Hardware supportato per System z
Contenuti del SDK e del Ambiente di Runtime
Classi e tool di Runtime Environment
Tool e informazioni di riferimento dell'SDK
Installazione e configurazione di SDK e Ambiente di Runtime
Aggiornamento dell'SDK
Installazione su Red Hat Enterprise Linux (RHEL) 4
Installazione su Red Hat Enterprise Linux (RHEL) 5
Esecuzione di Java con SELinux su RHEL 5
Installazione di un SDK a 32 bit su un'architettura a 64 bit
Installazione da un file RPM
Installazione da un file .tgz
Utilizzo di un formato compatibile JPackage
Configurazione di SDK e Runtime Environment per Linux
Impostazione del percorso
Impostare il percorso della classe
Disinstallazione di SDK e Ambiente di Runtime per Linux
Disinstallazione del pacchetto RMP (Red Hat Package Manager)
Disinstallazione del pacchetto compresso TAR (Tape Archive)
Esecuzione delle applicazioni Java
Comandi java e javaw
Come ottenere le informazioni di versione
Specificare le opzioni e le proprietà di sistema di Java.
Opzioni standard
Globalizzazione dei comandi java
Compilatore Just-In-Time (JIT)
Come disabilitare JIT
Come abilitare JIT
Come determinare se JIT è abilitato
Specifica della politica di raccolta dei dati obsoleti
Opzioni di Raccolta dei dati obsoleti
Tempo di pausa
Riduzione della pausa
Ambienti con heap molto pieni
Supporto del simbolo dell'Euro
File di configurazione font fallback
| |
Utilizzare metodi di input indiani e tailandesi
Utilizzo di SDK per lo sviluppo delle applicazioni Java
| |
Utilizzo di XML
| |
Migrazione verso XL-TXE-J
| |
Informazioni di riferimento XML
Esecuzione del debug nelle applicazioni Java
Java Debugger (JDB)
Determinare se la propria applicazione sta eseguendo un JVM a 32-bit o a 64-bit
Modalità di elaborazione dei segnali da parte della JVM
Segnali usati dalla JVM
Collegamento di un driver di codice nativo alla libreria del concatenamento dei segnali
Scrittura di applicazioni JNI
Supporto per il recupero di livello-thread dei connettori bloccati
Configurazione dell'allocazione di memoria di pagine grandi
Supporto CORBA
Proprietà di sistema per tracciare l'ORB
Proprietà di sistema per ottimizzare ORB
Autorizzazioni di sicurezza Java per l'ORB
Classi di implementazione ORB
RMI su IIOP
Implementazione di Connection Handler Pool per RMI
BigDecimal migliorato
Plug-in, Applet Viewer e Web Start
(Linux IA 32-bit e PPC32 soltanto) Utilizzo del plug-in di Java
Browser supportati
Installazione e configurazione del plug-in Java
Supporto DOM (Document Object Model) comune
Utilizzo dei parametri DBCS
Operazioni con le applet
Esecuzione delle applet con Applet Viewer
Esecuzione del debug delle applet con Applet Viewer
(Linux IA a 32-bit, PPC32, e PPC64 soltanto) Utilizzo del Web Start
Esecuzione di Web Start
(Linux IA a 32-bit soltanto) WebStart Secure Static Versioning
Invio delle applicazioni Java
Condivisione dei dati della classe fra le JVM
Panoramica sulla condivisione dei dati delle classi
Abilitazione e configurazione della condivisione dei dati delle classi
Creazione, popolamento ed eliminazione di una cache
Prestazioni e consumo della memoria
Limiti e considerazioni sull'utilizzo della condivisione dei dati delle classi
Limiti di dimensioni della cache
Modifiche bytecode al runtime
Limitazioni del sistema operativo
Utilizzo di SharedClassPermission
Adattamento dei class loader personalizzati per la condivisione di classi
Utilizzo dell'API Java Communications (JavaComm)
Installazione dell'API Java Communications da un file compresso
Installazione delle API Java Communications da un file RPM
Posizione dei file API di Java Communications
Configurazione dell'API Java Communications
Cambio della modalità di accesso delle porte seriali e parallele
Specifica dei dispositivi nel file javax.comm.properties
Abilitazione delle porte seriali su IBM ThinkPads
Limitazioni di stampa con le API Java Communications
Disinstallazione delle API Java Communications
Disinstallazione del pacchetto RMP (Red Hat Package Manager)
Disinstallazione del pacchetto TAR (Tape Archive) compresso
Documentazione delle API Java Communications
Servizio e supporto per fornitori di software indipendenti
Accessibilità
Tastiera trasversale di componenti JComboBox in Swing
Accessibilità del Web Start (Linux IA a 32-bit, PPC32, e PPC64 soltanto)
Inoltro dei commenti relativi a questa guida utente
Appendice A. Opzioni non standard
Appendice B. Limiti noti
Informazioni particolari
Marchi

Prefazione

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.

Panoramica

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.

Convenzioni

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.

Compatibilità versione

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.

Migrazione da altre JVM di IBM

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:

Hardware supportato per System z

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:

Contenuti del SDK e del Ambiente di Runtime

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.

Classi e tool di Runtime Environment

Una lista delle classi e dei tool che possono essere utilizzati con l'Ambiente di Runtime standard.

Tool e informazioni di riferimento dell'SDK

Un elenco dei tool e delle informazioni di riferimento inclusi nell'SDK standard.

I tool seguenti fanno parte dell'SDK e si trovano nella directory bin /opt/ibm/java-i386-60/:
appletviewer (Visualizzatore dell'Applet di Java)
Testa ed esegue applet al di fuori di un browser web.
apt (Tool di Elaborazione dell'Annotazione)
Trova ed esegue i processori di annotazione sulla base delle annotazioni nel gruppo di specifici file di origine in esame.
extcheck (programma di utilità Extcheck)
Rileva i conflitti di versione tra il file jar di destinazione e i file con estensione jar installati al momento.
(Linux IA a 32-bit, PPC32, e PPC64 soltanto) HtmlConverter ( Convertitore HTML del Plugin di Java)
Converte una pagina HTML che contiene delle applet in un formato che può utilizzare il Plugin di Java.
idlj (IDL su Java Compiler)
Genera i binding di Java da un dato file IDL.
ikeycmd (utility di riga comandi iKeyman)
Consente di gestire chiavi, certificati e richieste di certificazione dalla riga comandi. Per ulteriori informazioni consultare Security Guide e visitare il sito http://www.ibm.com/developerworks/java/jdk/security.
jar (Java Archive Tool)
Combina file multipli in un singolo file JAR (Java Archive).
jarsigner (Firma JAR e tool di verifica)
Genera le firme per i file JAR e verifica le firme dei file JAR firmati.
java-rmi.cgi (tool di inoltro richieste da HTT a CGI)
Accetta le richieste RMI su HTTP e le inoltra a un server RMI in attesa su una qualsiasi porta.
javac (Compilatore Java)
Compila i programmi scritti nel linguaggio di programmazione Java in bytecode. (codice Java compilato).
javadoc (Generatore della Documentazione Java)
Genera le pagine HTML della documentazione API dai file di origine Java .
javah (Intestazione in C e generatore di file matrice)
Consente di associare i metodi nativi con il codice scritto nel linguaggio di programmazione Java.
javap (Disassemblatore file di classe)
Disassembla i file compilati e può stampare una rappresentazione dei bytecode.
javaw (Java Interpreter)
Avvia le classi Java nello stesso modo del comando java, ma non utilizza una finestra della console.
(Linux IA 32-bit, PPC32, e PPC64 soltanto) javaws (Java Web Start)
Abilita la messa a punto e la manutenzione automatica delle applicazioni Java. Per ulteriori informazioni, fare riferimento a Esecuzione di Web Start.
jconsole (Tool di monitoraggio e gestione JConsole)
Controlla JVM locali e remote mediante una GUI. Compatibile JMX.
jdb (Debugger di Java )
Aiuta ad eseguire il debug dei programmi Java.
jdmpview (Programma di formattazione del dump di piattaforme incrociate)
Analizza i dump. Per ulteriori informazioni, consultare il manuale Guida alla Diagnostica.
native2ascii (Convertitore di Native-To-ASCII)
Converte un file con codifica nativa in un file ASCII contenente caratteri codificati in Latin-1 o in Unicode o in entrambi.
rmic (Java RMI (Remote Method Invocation) Stub Converter)
Genera matrici, strutture e congiunzioni per gli oggetti remoti. Include RMI oltre al supporto del protocollo RMI_IIOP (Internet Inter-ORB Protocol).
schemagen
Crea un file di schema per ciascun namespace a cui le proprie classi Java fanno riferimento.
serialver (Comando di versione seriale)
Restituisce il serialVersionUID per uno o più classi in un formato appropriato per la copia in una classe in evoluzione.
wsgen
Genera oggetti JAX-WS portabili usati nei servizi Web JAX-WS.
wsimport
Genera oggetti JAX-WS portabili da un file WSDL.
xjc
Compila file di schema XML.
File Include
Intestazione in C per programmi JNI.
Demo
La directory demo contiene una serie di sottodirectory contenenti esempi di codifica sorgente, demo, applicazioni, ed applet che è possibile utilizzare. |Dalla Versione 6, la demo RMI-IIOP non è inclusa nell'SDK.
copyright
L'informativa di copyright per l'SDK per il software Linux.
Licenza

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.

Installazione e configurazione di SDK e Ambiente di Runtime

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

Aggiornamento dell'SDK

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.

Installazione su Red Hat Enterprise Linux (RHEL) 4

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:

  1. Quando viene visualizzato il pannello Valori predefiniti del pacchetto, selezionare Personalizzare la serie di pacchetti da installare.
  2. Dal pannello Selezione gruppo pacchetti, in X Windows System, selezionare Dettagli e accertarsi di avere selezionato xorg-x11-deprecated-libs.
  3. Dalle opzioni Sviluppo selezionare Sviluppo software Legacy.

Installazione su Red Hat Enterprise Linux (RHEL) 5

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:

  1. Nella schermata di selezione software, selezionare Personalizza ora.
  2. Nella schermata successiva, nel pannello di sinistra, selezionare Sistema di base; nel pannello di sinistra, selezionare Supporto software legacy. Queste selezioni installeranno i pacchetti compat-libstdc++.
  3. Il pacchetto libXp è necessario, ma non è selezionabile per l'installazione dalla GUI di installazione. Una volta ultimata l'installazione, aprire una shell, localizzare il pacchetto libXp sul supporto di installazione di Red Hat, e installarlo. Per esempio, per l'installazione su una piattaforma Intel a 32 bit: rpm -i /media/cdrom/Server/libXp-1.0.0-8.i386.rpm

Esecuzione di Java con SELinux su 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.

Installazione di un SDK a 32 bit su un'architettura a 64 bit

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

Installazione da un file RPM

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.

  1. Aprire un prompt di shell, accertandosi che ci si trovi nella root.
  2. In un prompt di shell, immettere rpm -ivh <file RPM>. Ad esempio:
    rpm -ivh ibm-java2-<arch>-sdk-6.0-0.0.<arch>.rpm
    oppure
    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.

Installazione da un file .tgz

Procedura per l'installazione da un file .tgz.

  1. Creare una directory in cui memorizzare i file di pacchetto Java. Gli esempi in questa guida presuppongono che sia stato installato in /opt/ibm/java-i386-60/. Nel resto della guida, sostituire /opt/ibm/java-i386-60/ con la directory in cui è stato installato Java.
  2. In un prompt di shell, digitare tar -zxvf <file .tgz>.
    tar -zxvf ibm-java2-sdk-60-linux-<arch>.tgz
    oppure
    tar -zxvf ibm-java2-jre-60-linux-<arch>.tgz

    Dove <arch> rappresenta la propria architettura: i386, x86_64, ppc, ppc64, s390, o s390x.

  3. Se si sta usando Security-Enhanced Linux (SELinux), è necessario identificare le librerie condivise Java per il sistema. Digitare:
    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

Utilizzo di un formato compatibile JPackage

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.

Configurazione di SDK e Runtime Environment per Linux

Incongruenze nella codifica dei font su Red Hat Advanced Server

Nota: (Solo per gli utenti Linux IA a 32 bit di lingua cinese) A causa di incongruenze nelle codifiche dei font su Red Hat Advanced Server, quando si esegue l'installazione per un ambiente in cui si desidera che il cinese sia la lingua predefinita, è preferibile installare l'inglese come lingua predefinita e modificare quindi la lingua specificando il cinese dopo che l'installazione è stata completata. Altrimenti, è possibile che i font del cinese non vengano visualizzati.

Impostazione del percorso

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:

  1. Modificare il file di avvio della shell nella propria home directory (di norma, bashrc, a seconda della shell di cui si dispone) ed aggiungere i percorsi assoluti alla variabile di ambiente PATH; ad esempio:
    export PATH=/opt/ibm/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
  2. Collegarsi di nuovo oppure eseguire lo script aggiornato della shell per attivare le nuove impostazioni della variabile d'ambiente 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

Impostare il percorso della classe

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.

Disinstallazione di SDK e Ambiente di Runtime per Linux

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.

Disinstallazione del pacchetto RMP (Red Hat Package Manager)

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:

  1. Per verificare quali pacchetti RPM sono stati installati, digitare: rpm -qa | grep -i java

    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

  2. Rimuovere dall'istruzione PATH la directory in cui sono stati installati SDK e Ambiente di Runtime.
  3. (Solo per Linux IA a 32 bit e PPC32) Se è stato installato il plug-in Java, rimuovere il file del plug-in Java dalla directory del browser Web.

Disinstallazione del pacchetto compresso TAR (Tape Archive)

Elenco fdi istruzioni per la rimozione di SDK per Linux ,v6 di IBM estratto dal pacchetto compresso.

  1. Rimuovere i file Ambiente di Runtime o Ambiente di Runtime dalla directory in cui è stato installato SDK o Ambiente di Runtime.
  2. Rimuovere dall'istruzione PATH la directory in cui è stato installato SDK o Ambiente di Runtime.
  3. Collegarsi di nuovo oppure eseguire lo script aggiornato della shell per attivare le nuove impostazioni di PATH.
  4. (Solo per Linux IA a 32 bit e AMD64/EM64T) Se è stato installato il plug-in Java, timuovere i file del plug-in Java dalla directory del browser Web.

Esecuzione delle applicazioni Java

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

Comandi java e javaw

Breve rassegna dei comandi java e javaw.

Scopi

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.

Utilizzo

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

Parametri

[options]
Opzioni delle righe comandi da trasmettere all'ambiente di runtime.
<class>
Classe di avviamento. La classe deve contenere un metodo main().
<file.jar>
Il nome del file jar da richiamare. Viene utilizzato soltanto con l'opzione -jar. Il file jar nominato deve contenere file della classe e della risorsa dell'applicazione, con la classe di avviamento dal manifest header della Main-Class.
[arguments ...]
Gli argomenti della riga comandi da passare alla funzione main() della classe di avviamento.

Come ottenere le informazioni di versione

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.

  1. Aprire un shell prompt.
  2. Immettere il seguente comando:
    java -version
    Sarà 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.

Specificare le opzioni e le proprietà di sistema di Java.

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

  1. specificando l'opzione o la proprietà sulla riga comandi. Ad esempio:
    java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
  2. Creando un file contenente le opzioni, e specificandolo sulla riga comandi utilizzando -Xoptionsfile=<file>.
  3. Creando una variabile di ambiente chiamata IBM_JAVA_OPTIONS contenente le opzioni. Ad esempio:
    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.

Opzioni standard

Definizioni per opzioni standard.

-agentlib:<libname>[=<options>]
Carica la libreria dell'agent nativo <libname>; per esempio -agentlib:hprof. Per ulteriori informazioni specificare -agentlib:jdwp=help e -agentlib:hprof=help sulla riga comandi.
-agentpath:libname[=<options>]
Carica la libreria dell'agent nativo per nome percorso completo
-cp <le directory ed i file zip o jar separati da:>
Imposta il percorso di ricerca per risorse e classi dell'applicazione. Se -classpath e -cp non vengono usati e la variabile di ambiente CLASSPATH non viene impostata, il percorso classe utente è, per impostazione predefinita, la directory corrente..
-classpath <directory e file zip o jar separati da :>
Imposta il percorso di ricerca per risorse e classi dell'applicazione. Se -classpath e -cp non vengono usati e la variabile di ambiente CLASSPATH non viene impostata, il percorso classe utente è, per impostazione predefinita, la directory corrente..
-D<property name>=<value>
Imposta una proprietà di sistema.
-help or -?
Visualizza le informazioni relative all'utilizzo.
-javaagent:<jarpath>[=<options>]
Caricare un agente del linguaggio di programmazione Java. Per ulteriori informazioni, fare riferimento alla documentazione API java.lang.instrument.
-jre-restrict-search
Includere i JRE privati dell'utente nella ricerca della versione.
-no-jre-restrict-search
Escludere i JRE privati nella ricerca della versione.
-showversion
Visualizza la versione del prodotto e continua.
-verbose:<option>
Abilita l'output dettagliato. Le opzioni disponibili sono:
class
Scrive una voce in stderr per ciascuna classe che viene caricata.
gc
Scrive le informazioni sulla raccolta dettagliata di dati obsoleti a stderr. Utilizzare-Xverbosegclog per controllare l'output. Consultare Guida alla Diagnostica per ulteriori informazioni.
jni
Scrive le informazioni a stderr descrivendo i servizi JNI richiamati dall'applicazione e dalla JVM.
dimensioni
Scrive le informazioni a stderr descrivendo le impostazioni dell'uso della memoria attiva.
stack
Scrive le informazioni a stderr descrivendo l'uso degli stack di Java e di C per ciascun thread.
-version
Stampa la versione del prodotto.
-version:<value>
Richiede l'esecuzione della versione specificata, ad esempio la "1.5".
-X
Visualizza le istruzioni relative alle opzioni non standard.

Globalizzazione dei comandi java

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.

-Xargencoding
Utilizzare la codifica dell'argomento. Per specificare un carattere Unicode, utilizzare le sequenze di escape nel formato \u####, dove # è una cifra esadecimale (da 0 a 9, da A ad F).
-Xargencoding:utf8
Utilizzare la codifica UTF8.
-Xargencoding:latin
Utilizzare la codifica ISO8859_1.

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.

Compilatore Just-In-Time (JIT)

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.

Come disabilitare JIT

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.

Come abilitare JIT

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.

Come determinare se JIT è abilitato

 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.

Specifica della politica di raccolta dei dati obsoleti

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.

Opzioni di Raccolta dei dati obsoleti

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:

-Xgcpolicy:optthruput
(Valore predefinito e raccomandato.) Consente una velocità di trasmissione delle applicazioni elevatissima, ma comporta delle pause occasionali.
-Xgcpolicy:optavgpause
Riduce i tempi delle pause nella raccolta dei dati obsoleti e limita gli effetti derivanti dall'aumento della lunghezza della pausa della raccolta dei dati obsoleti. Utilizzare optavgpause se la configurazione ha una memoria riservata molto grande.
-Xgcpolicy:gencon
Richiede l'uso combinato della GC simultanea e generazionale per contribuire a minimizzare il tempo trascorso in una pausa di raccolta dei dati obsoleti.
-Xgcpolicy:subpool
(PPC e zSeries soltanto.) Utilizza un algoritmo di allocazione degli oggetti migliorato per una migliore prestazione quando vengono allocati degli oggetti sull'heap. Questa opzione potrebbe migliorare le prestazioni su sistemi SMP ampi.

Tempo di pausa

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.

Riduzione della pausa

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.

Ambienti con heap molto pieni

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.

Supporto del simbolo dell'Euro

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.

File di configurazione font fallback

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.

| | |

Utilizzare metodi di input indiani e tailandesi

|
|

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:

| |

|

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.

Utilizzo di SDK per lo sviluppo delle applicazioni Java

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.

| | |

Utilizzo di XML

|
|

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.

|

| |

Librerie XML disponibili

|

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

|
|
XML4J 4.5
|
|

XML4J è un parser validante che supporta i seguenti standard: |

|
    |
  • XML 1.0 (4th edition)
  • |
  • Namespace in XML 1.0 (2nd edition)
  • |
  • XML 1.1 (2nd edition)
  • |
  • Namespace in XML 1.1 (2nd edition)
  • |
  • W3C XML Schema 1.0 (2nd Edition)
  • |
  • XInclude 1.0 (2nd Edition)
  • |
  • OASIS XML Catalogs 1.0
  • |
  • SAX 2.0.2
  • |
  • DOM Level 3 Core, Load e Save
  • |
  • DOM Level 2 Core, Events, Traversal e Range
  • |
  • JAXP 1.4
| |

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

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.

|
|
XL TXE-J 1.0.1 Beta
|
|

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

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

| |

Selezione di un processore XML

|

La selezione del processore XML |viene eseguita utilizzando i service provider. Quando si utilizza un factory |finder, Java effettua una ricerca |nelle ubicazioni seguenti per individuare il tipo di service provider da utilizzare: |

|
    |
  1. nella proprietà di sistema con lo stesso nome del service provider.
  2. |
  3. Solo per XMLEventFactory, XMLInputFactory |e XMLOutputFactory. Nel valore del service |provider nel file /opt/ibm/java-i386-60/jre/lib/stax.properties.
  4. |
  5. Per altre factory. Nel valore del service provider nel file /opt/ibm/java-i386-60/jre/lib/jaxp.properties.
  6. |
  7. Nei contenuti del fileMETA-INF/services/<service.provider>
  8. |
  9. Nel service provider predefinito.
|

I seguenti service provider controllano le librerie di elaborazione XML utilizzate da Java: |

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

| |

Migrazione verso XL-TXE-J

|
|

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:

|
    |
  1. Utilizzare com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl per impostare il service provider javax.xml.transform.TransformerFactory.
  2. |
  3. Rigenera i file della classe generati dal compilatore XSLT4J. XL TXE-J non è in grado di eseguire i file della classe generati dal compilatore XSLT4J.
  4. |
  5. Alcuni metodi generati dal compilatore possono superare i limiti di grandezza per i metodi della JVM, nel qual caso il compilatore cercherà di suddividere tali metodi in metodi più piccoli. | |
      |
    • Se il compilatore suddivide correttamente il metodo, si riceverà l'avviso: "alcune funzioni generate hanno superato il limite della dimensione del metodo della JVM e sono state automaticamente suddivise in funzioni più piccole. Si potrebbero ottenere prestazioni migliori suddividendo manualmente template molto grandi in più piccoli, utilizzando l'opzione "splitmit" del comando Process o Compile, oppure impostando l'attributo della transformer factory 'http://www.ibm.com/xmlns/prod/xltxe-j/split-limit'."  possibile utilizzare le classi compilate, ma si potrebbe ottenere una prestazione migliore controllando il limite di suddivisione manualmente.
    • |
    • Se il compilatore non effettua correttamente la suddivisione del metodo, si riceverà una delle seguenti ecccezioni: "com.ibm.xtq.bcel.generic.ClassGenException: |Offset del branch di destinazione troppo grande per il tipo short" o "dimensione di array bytecode > 65535 |all'offset=#####". Cercare di impostare il limite di suddivisione manualmente, oppure usare un limite più basso.
    Per impostare il limite di suddivisione usare l'opzione -SPLITLIMIT quando si utilizzano i comandi Process o Compile, o l'attributo di transformer factory http://www.ibm.com/xmlns/prod/xltxe-j/split-limit quando si usa la transformer factory. Il limite di suddivisione può essere compreso fra 100 e 2000. Per impostare manualmente il limite di suddivisione, utilizzare il limite di suddivisione più alto possibile per una prestazione ottimale.
  6. |
  7. XL TXE-J potrebbe necessitare di più memoria del compilatore XSLT4J. Se la memoria si sta esaurendo o se la resa appare bassa, aumentare la dimensione dell'heap utilizzando l'opzione -Xmx.
  8. |
  9. Migrare la propria applicazione per utilizzare le nuove attribute key. Le vecchie attribute key del transformer factory sono disapprovate. I vecchi nomi verranno accettati con un avviso. | | |||||||||||||||||||||||||||||||||||||||||||||||||||
    Tabella 1. Variazioni nelle chiavi di attributo dal compilatore XSL4J al compilatore XL TXE-J
    Attributo del compilatore XSL4J Attributo del compilatore XL TXE-J
    translet-name http://www.ibm.com/xmlns/prod/xltxe-j/translet-name
    destination-directory http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory
    package-name http://www.ibm.com/xmlns/prod/xltxe-j/package-name
    jar-name http://www.ibm.com/xmlns/prod/xltxe-j/jar-name
    generate-translet http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet
    auto-translet http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet
    use-classpath http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath
    debug http://www.ibm.com/xmlns/prod/xltxe-j/debug
    indent-number http://www.ibm.com/xmlns/prod/xltxe-j/indent-number
    enable-inlining Obsoleto nel nuovo compilatore
  10. |
  11. Opzionale: Per avere massime prestazioni, assicurarsi di non ricompilare |le trasformazioni XSLT riusabili. Per riutilizzare le trasformazioni compilate, usare uno dei metodi |seguenti: | |
      |
    • Se il foglio di stile non cambia al runtime, compilarlo come parte |del processo di generazione e inserire le classi compilate nel proprio classpath. |Utilizzare il comando org.apache.xalan.xsltc.Compile per compilare |il foglio di stile e impostare l'attributo http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath del transformer factory |su true per caricare le classi dal |classpath.
    • |
    • Se l'applicazione utilizzerà lo stesso foglio di stile per più esecuzioni, |impostare l'attributo http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet del transformer factory |su true per salvare automaticamente il foglio di stile compilato |su disco e riutilizzarlo in futuro. Se è disponibile un foglio di stile compilato, il compilatore lo utilizzerà, |altrimenti, se il foglio di stile non è disponibile o è obsoleto, lo ricompilerà. |Per impostare la directory utilizzata per memorizzare i fogli di stile compilati, |utilizzare l'attributo http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory del transformer factory. |Per impostazione predefinita, i fogli di stile compilati sono memorizzati nella stessa directory del foglio di stile.
    • |
    • Se l'applicazione ha una lunga esecuzione nella quale lo stesso foglio di stile viene |utilizzato più di una volta, utilizzare il transformer factory per compilare il foglio di stile e |creare un oggetto Templates. È possibile utilizzare l'oggetto Templates |per creare oggetti Transformer senza ricompilare il foglio di stile. |Gli oggetti Transformer possono anche essere riutilizzati ma non sono |thread safe.
| |

Informazioni di riferimento XML

|
|

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

| | |

Informazioni di riferimento su XL XP-J

|
|

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.

|

| |

Funzioni non supportate
|

Le seguenti funzioni opzionali di StAX non sono supportate da XL XP-J: |

|

|

| |

Riferimento XMLInputFactory
|

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

| |||||||||||||||||||||||||||||||||||||||||||
Tabella 2.
Nome 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
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
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
javax.xml.stream.resolver
|

XL XP-J supporta inoltre il metodo opzionale createXMLStreamReader(javax.xml.transform.Source), |che consente di creare lettori StAX da sorgenti DOM e SAX.

|

| |

Riferimento XMLStreamReader
|

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

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

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.

|

| |

Riferimento XMLOutputFactory
|

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

| |||||||||||||||
Tabella 4.
Nome della proprietà Supportata
javax.xml.stream.isRepairingNamespaces
|

| |

Riferimento XMLStreamWriter
|

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

| |||||||||||||||
Tabella 5.
Nome della proprietà Supportata
javax.xml.stream.isRepairingNamespaces
|

Le proprietà degli oggetti XMLStreamWriter sono di sola lettura.

| | |

Informazioni di riferimento su XL TXE-J

|
|

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

|

| |

Tabella di raffronto delle funzioni

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tabella 6. Raffronto delle funzioni tra l'interprete XSLT4J, il compilatore XSLT4J e il compilatore XL TXE-J.
Funzione Interprete XSLT4J (incluso) Compilatore XSLT4J (non incluso) Compilatore XL TXE-J (incluso)
funzione http://javax.xml.transform.stream.StreamSource/feature
funzione http://javax.xml.transform.stream.StreamResult/feature
funzione http://javax.xml.transform.dom.DOMSource/feature
funzione http://javax.xml.transform.dom.DOMResult/feature
funzione http://javax.xml.transform.sax.SAXSource/feature
funzione http://javax.xml.transform.sax.SAXResult/feature
funzione http://javax.xml.transform.stax.StAXSource/feature No
funzione http://javax.xml.transform.stax.StAXResult/feature No
funzione http://javax.xml.transform.sax.SAXTransformerFactory/feature
funzione http://javax.xml.transform.sax.SAXTransformerFactory/feature/xmlfilter
funzione http://javax.xml.transform.dom.XMLConstants/feature/secure-processing
attributo incrementale http://xml.apache.org/xalan/features/ No No
ottimizzare attributo http://xml.apache.org/xalan/features/ No No
attributo http://xml.apache.org/xalan/properties/source-location No No
attributo translet-name N/D Sì (con un nuovo nome)
attributo destination-directory N/D Sì (con un nuovo nome)
attributo package-name N/D Sì (con un nuovo nome)
attributo jar-name N/D Sì (con un nuovo nome)
attributo generate-translet N/D Sì (con un nuovo nome)
attributo auto-translet N/D Sì (con un nuovo nome)
attributo use-classpath N/D Sì (con un nuovo nome)
attributo enable-inlining No No (obsoleto in TL TXE-J)
attributo indent-number No Sì (con un nuovo nome)
attributo di debug No Sì (con un nuovo nome)
Estensioni Java Sì (solo sintassi abbreviata, xalan:component/xalan:script |costruzioni non supportate)
Estensioni JavaScript No No
Elementi dell'estensione No No
Funzioni dell'estensione EXSLT Sì (escludendo la funzione dinamica) Sì (escludendo la funzione dinamica)
estensione redirect Sì (escludendo redirect:open and redirect:close)
estensione output No
estensione nodeset
funzioni dell'estensione NodeInfo No No
estensione della libreria SQL No No
estensione pipeDocument No No
estensione evaluate No No
estensione tokenize No No
XML 1.1
|

| |

Note
|

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.

| |

Utilizzo di una versione precedente di Xerces o Xalan

|
|

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

|

Esecuzione del debug nelle applicazioni Java

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.

Java Debugger (JDB)

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:

  1. Avviare JVM con le seguenti opzioni:
    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.
  2. In una sessione separata, è possibile collegare il programma di debug a JVM:
    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:

  1. Immettere jdb
  2. Nel prompt jdb, immettere help

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.

  1. Avviare JVM con le seguenti opzioni:
    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.
  2. Collegare il debugger alla JVM remota:
    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:

Determinare se la propria applicazione sta eseguendo un JVM a 32-bit o a 64-bit

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");

Modalità di elaborazione dei segnali da parte della JVM

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 informazioni su come scrivere un launcher che specifichi i ganci suindicati, fare riferimento a:http://www.ibm.com/developerworks/java/library/i-signalhandling/. Questo elemento è stato scritto per Java V1.3.1, ma si applica anche alle versioni successive.

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

  1. Richiama il gestore del segnale della propria applicazione per quel segnale.
  2. Esegue tutti i ganci di arresto dell'applicazione.
  3. Richiama tutti i ganci di uscita installati per l'applicazione.
  4. Esegue il necessario cleanup della JVM.

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.

Segnali usati dalla JVM

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:

Eccezioni
Il sistema operativo emette un idoneo segnale di eccezione in modo sincrono in caso di errore irreversibile.
Errori
La JVM emetterà un SIGABRT se rileva una condizione da cui non riesce ad effettuare il recupero.
Interruzioni
I segnali di interruzione vengono emessi in modo asincrono, dall'esterno di un processo della JVM, per richiedere l'arresto.
Controlli
Altri segnali utilizzati dalla JVM con finalità di controllo.

Tabella 7. Segnali usati dalla JVM
Nome segnale Tipo segnale Descrizione Disabilitato da -Xrs
SIGBUS (7) Eccezione Accesso errato alla memoria (allineamento errato di dati )
SIGSEGV (11) Eccezione Accesso alla memoria non corretto (scrittura su memoria non accessibile)
SIGILL (4) Eccezione Istruzione non valida (tentativo di richiamare un' istruzione macchina sconosciuta) No
SIGFPE (8) Eccezione Eccezione virgola mobile (dividere per zero)
SIGABRT (6) Errore Fine anomala. La JVM emette questo segnale quando rileva un problema alla JVM.
SIGINT (2) Interrotto Attenzione interattiva (CTRL-C). La JVM esce normalmente.
SIGTERM (15) Interrotto Richiesta termine. La JVM uscirà normalmente.
SIGHUP (1) Interrotto Disconnessione. La JVM esce normalmente.
SIGQUIT (3) Controllo Un segnale di uscita per un terminale. Per impostazione predefinita, questo segnale attiva un Javadump.
SIGTRAP (5) Controllo Utilizzato da JIT.
__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.

Collegamento di un driver di codice nativo alla libreria del concatenamento dei segnali

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:

La variabile d'ambiente JAVA_HOME deve essere impostata all'ubicazione dell'SDK, per esempio /opt/ibm/java-i386-60/.

Per utilizzare libjsig.a:

Scrittura di applicazioni JNI

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

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

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.

Supporto per il recupero di livello-thread dei connettori bloccati

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:

public interface InterruptibleContext
Definisce due metodi: isBlocked() e unblock(). Le altre tre classi implementanoInterruptibleContext.
public class InterruptibleLockContext
Una classe di utilità per interrompere le chiamate di sincronizzazione.
public class InterruptibleIOContext
Una classe di utilità per interrompere le chiamate di rete.
public class InterruptibleThread
Una classe di utilità che estende java.lang.Thread, per consentire il riciclo dei metodi che è possibile interrompere. Usa istanze di InterruptibleLockContext e InterruptibleIOContext per eseguire i metodi isBlocked() e unblock() necessari a seconda che l'operazione di sincronizzazione o di connessione alla rete stia bloccando o meno il thread..

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.

Configurazione dell'allocazione di memoria di pagine grandi

 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.

Supporto CORBA

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.

Supporto per GIOP 1.2

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.

Supporto per Portable Interceptors

Questo SDK supporta Portable Interceptors, come definito da OMG nel documento ptc/01-03-04, che è possibile ottenere da:

http://www.omg.org/cgi-bin/doc?ptc/01-03-04

I Portable Interceptors sono dei ganci posti nei servizi ORB che ORB può utilizzare per intercettare il normale flusso di esecuzione di ORB.

Supporto per Interoperable Naming Service

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.

Proprietà di sistema per tracciare l'ORB

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.

Tracciamento delle Proprietà

com.ibm.CORBA.Debug=true
Attiva il tracciamento sull'ORB.
com.ibm.CORBA.CommTrace=true
Aggiunge messaggi GIOP (inviati e ricevuti) alla traccia.
com.ibm.CORBA.Debug.Output=<file>
Specificare l'output di traccia del file. Per default, questo è del formato orbtrc.DDMMYYYY.HHmm.SS.txt.

Esempio di tracciamento ORB

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>

Limitazioni

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.

Proprietà di sistema per ottimizzare ORB

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.

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

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

java -Dcom.ibm.CORBA.FragmentSize=0 <myapp>
com.ibm.CORBA.RequestTimeout=<tempo in secondi>
Imposta il tempo massimo di attesa di una Richiesta CORBA. Per default, l'ORB attende all'infinito. Non impostare il timeout su un valore troppo basso, altrimenti le connessioni potrebbero terminare inutilmente.
com.ibm.CORBA.LocateRequestTimeout=<tempo in secondi>
Impostare il tempo massimo di attesa di una LocateRequest CORBA. Per default, l'ORB attende all'infinito.
com.ibm.CORBA.ListenerPort=<port number>
Impostare la porta di lettura delle richieste in entrata da parte dell'ORB. Se viene impostata questa proprietà, ORB si mette in ascolto appena viene inizializzato. Altrimenti, inizia solo quando viene richiesto.

Autorizzazioni di sicurezza Java per l'ORB

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

Tabella 8. Metodi interessati dall'utilizzo di Java SecurityManager
Classe/Interfaccia Metodo Autorizzazione richiesta
org.omg.CORBA.ORB init java.net.SocketPermission resolve
org.omg.CORBA.ORB connect java.net.SocketPermission listen
org.omg.CORBA.ORB resolve_initial_references java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl _is_a java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl _non_existent java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl OutputStream _request (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

Classi di implementazione ORB

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.

RMI su IIOP

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:

Implementazione di Connection Handler Pool per RMI

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

Per abilitare il 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.

BigDecimal migliorato

Da Java 5.0, la classe IBM BigDecimal è stata adottata da Sun come java.math.BigDecimal. La classe com.ibm.math.BigDecimal è riservata 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.*;.

Plug-in, Applet Viewer e Web Start

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.

(Linux IA 32-bit e PPC32 soltanto) Utilizzo del plug-in di Java

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

Browser supportati

Il plug-in Java supporta SeaMonkey, Mozilla, e Mozilla Firefox.

Tabella 9. Browser supportati dal plug-in Java su Linux IA32
Browser Versioni supportate
Mozilla 1.7.12, 1.8
Firefox 1.5, 2.0
Tabella 10. Browser supportati dal plug-in Java su Linux PPC32
Browser Versioni supportate
Mozilla 1.6
|SeaMonkey |1.0.8

Sono inoltre supportate release minori successive dei browser.

Installazione e configurazione del plug-in Java

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.

Mozilla

È supportato solo Mozilla 1.4 e versioni successive.

  1. Collegarsi come root.
  2. Cambiare nella propria directory dei Plugin di Mozilla (ciò potrebbe variare a seconda delle distribuzioni Linux).
  3. Creare un collegamento simbolico al plug-in.
     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.

Limitazione:  possibile avere soltanto una libreria condivisa di JavaPlugin in /usr/local/mozilla/plugins/. Mozilla tenta di caricare qualsiasi cosa si trovi in quella directory (o nelle sottodirectory al disotto di essa) come Plugin, ed i risultati sono imprevedibili se sono caricate le due versioni del Plug-in di Java.

Firefox

Queste istruzioni renderanno il plug-in di Java disponibile per tutti gli utenti

  1. Collegarsi come root.
  2. Accedere alla propria directory dei plug-in di Firefox (potrebbe variare a seconda delle distribuzioni di Linux).
    cd /usr/local/mozilla-firefox/plugins/
  3. Creare un collegamento simbolico al plug-in.
     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.

Supporto DOM (Document Object Model) comune

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:

Utilizzo dei parametri DBCS

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.

Operazioni con le applet

Con Applet Viewer, è possibile eseguire una o più applet chiamate come riferimento in una pagina web (file HTML) usando le tag APPLET. Applet Viewer individua le tag APPLET nel file HTML ed esegue le applet, in finestre separate, come specificato dalle tag.

Poiché l'Applet Viewer è solo per le applet di visualizzazione, non può visualizzare un'intera pagina web contenente molte tag HTML. Analizza solo le tag APPLET e nessun altro HTML nella pagina web.

Esecuzione delle applet con Applet Viewer

Utilizzare il seguente comando per 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

Esecuzione del debug delle applet con Applet Viewer

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

Ad esempio:

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

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

(Linux IA a 32-bit, PPC32, e PPC64 soltanto) Utilizzo del Web Start

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:

Esecuzione di Web Start

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.

(Linux IA a 32-bit soltanto) WebStart Secure Static Versioning

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.

Invio delle applicazioni Java

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.

Condivisione dei dati della classe fra le JVM

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:

Panoramica sulla condivisione dei dati delle classi

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.

Abilitazione della condivisione dei dati delle classi

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.

Accesso alla cache

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

Aggiornamento dinamico della cache

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.

Sicurezza della cache

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.

Intervallo di tempo valido della cache

Su un sistema possono esistere più cache e sono specificate per nome come un'opzione secondaria del comando -Xshareclasses. Una JVM è 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.

Programmi di utilità della 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.

Abilitazione e configurazione della condivisione dei dati delle classi

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.

-Xscmaxaot<size>
Imposta il numero massimo di byte nella cache che può essere utilizzato per i dati AOT. Utilizzare questa opzione per garantire che una certa quantità di spazio di cache sia disponibile per i dati non AOT. Per default, il limite massimo dei dati AOT corrisponde alla quantità di spazio libero nella cache. Il valore di questa opzione non dovrebbe essere inferiore a quello di -Xscminaot e non dovrebbe essere maggiore di quello di -Xscmx.
-Xscminaot<size>
Imposta il numero minimo di byte nella cache che possono essere utilizzati per i dati AOT. Per default, nessuno spazio è riservato ai dati AOT, sebbene questi siano scritti nella cache fino a quando questa non è piena o finché non viene raggiunto il limite di -Xscmaxaot. Il valore di questa opzione non dovrebbe superare quello di -Xscmx o -Xscmaxaot. Il valore di -Xscminaot dovrebbe essere sempre notevolmente inferiore alla dimensione totale della cache poiché i dati AOT possono essere creati solo per le classi dotate di cache. Se il valore di -Xscminaot è pari al valore di -Xscmx, non vengono memorizzati dati di classe o dati AOT in quanto i dati AOT devono essere associati a una classe nella cache.
-Xscmx<size>
Specifica la dimensione della cache. Questa opzione si applica solo se la cache viene creata e non esiste nessuna cache dello stesso nome. La dimensione predefinita della cache dipende dalla piattaforma. È possibile scoprire il valore della dimensione utilizzato aggiungendo -verbose:sizes come argomento della riga dei comandi. La dimensione minima della cache è 4 KB. La dimensione predefinita della cache dipende dalla piattaforma. (Consultare Limiti di dimensioni della cache.)
-Xshareclasses:<suboption>[,<suboption>...]
Abilita la condivisione dei dati della classe. Può avere una serie di opzioni secondarie, alcune delle quali sono programmi di utilità della cache. I programmi di utilità della cache effettuano l'operazione richiesta sulla cache specificata ma senza l'avvio del VM. È possibile combinare più opzioni secondarie, separate da virgole, ma i programmi di utilità della cache si escludono a vicenda. Quando si utilizzano le utility della cache il messaggio "Impossibile creare la virtual machine di Java dovrebbe comparire". Le utility della cache non creano la virtual machine.

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:

help
Visualizza un elenco di tutte le opzioni secondarie della riga comandi.
name=<name>
Collega una cache di un nome specificato, creando una cache se non esiste già. Utilizzato anche per indicare la cache che le cache utility come, ad esempio, destroy, devono utilizzare. Usare l'utility listAllCaches per visualizzare quali cache nominate sono disponibili al momento. Se non si specifica un nome, viene utilizzato il nome predefinito "sharedcc_%u". %u nel nome della cache inserirà il nome utente in uso.  possibile specificare %g nel nome della cache per inserire il nome del gruppo corrente.
|cacheDir=<directory>
|Imposta la directory in cui verranno letti e scritti i dati di cache. Per impostazione predefinita, <directory> è /tmp/javasharedresources. L' utente deve avere le autorizzazioni necessarie all'interno di <directory>. Per impostazione predefinita, la JVM scrive i file di cache persistenti direttamente nella directory specificata. I file di cache persistenti possono essere spostati ed eliminati dal file system senza problemi. Le cache non persistenti vengono memorizzate nella memoria condivisa e dispongono di file di controllo che descrivono l'ubicazione della memoria. I file di controllo vengono memorizzati nella sottodirectory javasharedresources della directory cacheDir specificata. |I file di controllo in questa directory non devono essere spostati o eliminati manualmente. L'utility listAllCaches, l'utility destroyAll e l'opzione secondaria expire agiscono solo entro l'ambito di una data cacheDir.
|readonly
|Apre una cache esistente con autorizzazioni di sola lettura. La JVM non creerà una nuova cache con questa opzione secondaria. L'apertura di una cache in sola lettura impedisce alla JVM di aggiornare tale cache. Inoltre consente alla JVM di connettersi a cache create da altri utenti o gruppi senza che sia necessario l'accesso in scrittura. Per impostazione predefinita, |questa opzione secondaria non viene specificata.
|nonpersistent
|Usa una cache non persistente. Per impostazione predefinita, la JVM crea un file di cache su disco che persiste anche dopo il riavvio del sistema operativo. La opzione secondaria nonpersistent crea la cache nella memoria condivisa che viene eliminata alla chiusura del sistema operativo. Cache persistenti e non persistenti possono avere lo stesso nome; l'opzione secondaria nonpersistent deve essere sempre utilizzata quando si eseguono utility come destroy su una cache non persistente. Per impostazione predefinita, |questa opzione secondaria non viene specificata.
groupAccess
Imposta le autorizzazioni del sistema operativo su una nuova cache per consentire l'accesso di gruppo alla cache. L'impostazione predefinita è l'accesso del solo utente.
verbose
Abilita l'output dettagliato, che fornisce lo stato generale della cache di classe condivisa e messaggi di errore più dettagliati.
|verboseAOT
|Abilita l'output verboso quando il codice AOT compilato viene trovato o memorizzato |nella cache. Il codice AOT viene generato euristicamente. Potrebbe accadere di non vedere alcun codice AOT |generato per una piccola applicazione. Le cache AOT possono essere disabilitate mediante l'opzione secondaria noaot.
verboseIO
Fornisce un output dettagliato sull'attività della cache I/O, elencando le informazioni sulle classi che vengono memorizzate e trovate. A ciascun classloader viene assegnato un ID univoco (il programma di caricamento di avvio è sempre 0) e l'output visualizza la gerarchia dei classloader attivi, dove i classloader devono chiedere ai parent una classe prima di poterla caricare. È normale che vi siano molte richieste non riuscite; questo comportamento è previsto per la gerarchia dei classloader.
verboseHelper
Abilita il verbose output per Java Helper API. Questo output mostra in che modo l'Helper API viene utilizzato dal proprio ClassLoader.
silent
Disattiva tutti i messaggi delle classi condivise, inclusi i messaggi di errore.
nonfatal
Consente alla JVM di avviarsi anche se la condivisione dei dati della classe non riesce. Il normale comportamento della JVM è di rifiutare di avviarsi se la condivisione dei dati della classe non riesce. Se viene selezionato nonfatal e la cache delle classi condivise non si inizializza, la JVM tenterà di connettersi alla cache in modalità di sola lettura. Se il tentativo non riesce, la JVM si avvia senza la condivisione dei dati della classe.
none
Può essere aggiunto alla fine di una riga comandi per disabilitare la condivisione dei dati della classe. Questa opzione secondaria sovrascrive gli argomenti della condivisione della classe trovati precedentemente sulla riga comandi.
modified=<modified context>
Utilizzato quando viene installato un agente della JVMTI che potrebbe modificare il bytecode in runtime. Se questa opzione secondaria non viene specificata ed è installato un agente di modifica del bytecode, le classi verranno condivise in sicurezza con un costo extra per le prestazioni. Il <modified context> è un descrittore scelto dall'utente, ad esempio, "myModification1". Questa opzione partiziona la cache in modo tale che solo le JVM che usano il contesto myModification1 possano condividere le stesse classi. Ad esempio, se si esegue HelloWorld con un contesto di modifica e poi lo si riesegue con un contesto di modifica diverso, sarà possibile vedere tutte le classi memorizzate due volte nella cache. Fare riferimento a Modifiche bytecode al runtime per ulteriori informazioni.
|reset
|Provoca la diistruzione e successiva creazione di una cache all'avvio della JVM. Può essere aggiunto alla fine di una riga comandi come -Xshareclasses:reset.
destroy (opzione di utilità)
Distrugge una cache specificata dalle opzioni secondarie name, cacheDir e nonpersistent. Una cache può essere distrutta solo se sono chiuse tutte le JVM che la utilizzano e l'utente ha un livello di autorizzazione sufficiente.
destroyAll (opzione di utilità)
Cerca di distruggere tutte le cache disponibili usando le opzioni secondarie cacheDir e nonpersistent. Una cache può essere distrutta solo se sono chiuse tutte le JVM che la utilizzano e l'utente ha un livello di autorizzazione sufficiente.
expire=<time in minutes>
Distrugge tutte le cache non utilizzate per il tempo specificato prima di caricare le classi condivise. Non è un'opzione di utility perché non provoca l'uscita della JVM.
listAllCaches (opzione di Utility)
Elenca tutte le cache compatibili e incompatibili esistenti nella directory cache specificata. Se cacheDir non viene specificato, viene usata la directory predefinita. Vengono visualizzate informazioni di riepilogo, per esempio la versione di Java e l'utilizzo attuale, per ciascuna cache.
printStats (opzione di Utility)
Visualizza informazioni di riepilogo sulla cache specificata dalle opzioni secondarie name, cacheDir e nonpersistent. Le informazioni più utili visualizzate sono relative a quanto è piena la cache e a quante classi contiene. Le classi "stale" sono classi che sono state aggiornate sul sistema file e che la cache ha quindi contrassegnato come "stale". Le classi "stale" non vengono epurate dalla cache e possono essere riutilizzate. Consultare Guida alla Diagnostica per ulteriori informazioni.
printAllStats (opzioni di Utility)

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.

|mprotect=[ all || default | none ]
|Per impostazione predefinita, le pagine di memoria che contengono la cache sono sempre protette, tranne quando viene aggiornata una pagina specifica. Questo contribuisce a proteggere la cache da alterazioni dei dati accidentali o volontarie. Per impostazione predefinita, l'header della cache non è protetto, in modo da avere un costo in prestazioni ridotto. Se si specifica "all" verranno protette tutte le pagine della cache, compreso l'header. Se si specifica "none" la protezione delle pagine verrà disabilitata.
|noBootclasspath
|Impedisce la memorizzazione delle classi caricate dal classloader di bootstrap nella |cache delle classi condivise. Può essere usato con l'API SharedClassURLFilter per controllare esattamente quali classi vengono conservate in cache. Consultare Guida alla Diagnostica per |ulteriori informazioni sulla filtrazione delle classi condivise.
|cacheRetransformed
|Abilita la creazione di cache per le classi che sono state trasformate utilizzando la funzione JVMTI RetransformClasses.
|noaot
|Disabilita la memorizzazione in cache e il caricamento del codice AOT.

Creazione, popolamento ed eliminazione di una cache

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.

Prestazioni e consumo della memoria

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.

Limiti e considerazioni sull'utilizzo della condivisione dei dati delle classi

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.

Limiti di dimensioni della cache

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.

Modifiche bytecode al runtime

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.

Limitazioni del sistema operativo

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.

Utilizzo di SharedClassPermission

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.

Adattamento dei class loader personalizzati per la condivisione di classi

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.

Utilizzo dell'API Java Communications (JavaComm)

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:

Installazione dell'API Java Communications da un file compresso

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:

  1. Inserire il file compresso dell'API Java Communications, ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz, nella directory in cui è stato installato l'SDK o Runtime Environment. Se l'installazione era stata eseguita nella directory predefinita, la directory sarà /opt/ibm/java-i386-60/.
  2. Da un shell prompt, nella directory contenente il file compresso, estrarre i contenuti:
    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.

  3. |Copiare i file javacomm nelle directory |corrette all'interno del proprio SDK. | |
      |
    1. Copiare il file lib/libLinuxSerialParallel.so nella |propria directory jre/bin/.
    2. |
    3. Copiare il file jar/comm.jar nella propria directory jre/lib/ext/.
    4. |
    5. Copiare il file lib/javax.comm.properties nella propria |directory jre/lib/.
    Per impostazione predefinita, SDK viene installato nella directory /opt/ibm/java-i386-60/.

Installazione delle API Java Communications da un file RPM

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.

  1. Aprire un prompt di shell, accertandosi che ci si trovi nella root.
  2. Utilizzare il comando rpm -ivh per installare il file RPM delle API Java Communications. Ad esempio:
    rpm -ivh ibm-javacomm-3.0-0.0.<arch>.rpm
    L'API Java Communications è installata all'interno della struttura della directory /opt/ibm/java-i386-60/.
  3. |Copiare i file javacomm nelle directory |corrette all'interno del proprio SDK. | |
      |
    1. Copiare il file lib/libLinuxSerialParallel.so nella |propria directory jre/bin/.
    2. |
    3. Copiare il file jar/comm.jar nella propria directory jre/lib/ext/.
    4. |
    5. Copiare il file lib/javax.comm.properties nella propria |directory jre/lib/.
    Per impostazione predefinita, SDK viene installato nella directory /opt/ibm/java-i386-60/.

Posizione dei file API di Java Communications

Per default, i file API di Java Communications sono installati nella directory /opt/ibm/java-i386-60/. I file e la loro struttura sono:

Configurazione dell'API Java Communications

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.

Cambio della modalità di accesso delle porte seriali e parallele

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

Specifica dei dispositivi nel file javax.comm.properties

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.

Abilitazione delle porte seriali su IBM ThinkPads

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.

Limitazioni di stampa con le API Java Communications

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

Disinstallazione delle API Java Communications

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 del pacchetto RMP (Red Hat Package Manager)

Disinstallazione delle API Java Communications utilizzando il pacchetto RPM.

  1. Usare il tool rpm per disinstallare il pacchetto Immettere il seguente comando in una shell prompt:
    rpm -e ibm-javacomm-3.0-0.0
    In alternativa, è possibile utilizzare un tool grafico, come per esempio kpackage oppure yast2
  2. Se la directory in cui è avvenuta l'installazione delle API Java Communications non contiene altri strumenti di cui si ha bisogno, rimuovere quella directory dalla propria istruzione PATH.
  3. |Se le librerie javacomm |sono state copiate nella directory di SDK, eliminare i file seguenti da tale directory. | |
      |
    • jre/bin/libLinuxSerialParallel.so
    • |
    • jre/lib/ext/comm.jar
    • |
    • jre/lib/javax.comm.properties
    Per impostazione predefinita, SDK viene installato nella directory /opt/ibm/java-i386-60/.

Disinstallazione del pacchetto TAR (Tape Archive) compresso

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:

Documentazione delle API Java Communications

 possibile trovare la documentazione sull API Java Communications nel sito Web di Sun.

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

Servizio e supporto per fornitori di software indipendenti

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.

Accessibilità

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

Tastiera trasversale di componenti JComboBox in Swing

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.

Accessibilità del Web Start (Linux IA a 32-bit, PPC32, e PPC64 soltanto)

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.

Inoltro dei commenti relativi a questa guida utente

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.

Appendice A. Opzioni non standard

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.

-Xargencoding
Consente di inserire le sequenze escape Unicode nell'elenco di argomenti. Questa opzione è impostata sull'impostazione predefinita off.
-Xbootclasspath:<directory e file zip o jar separati da:>
Imposta il percorso di ricerca per le risorse e le classi bootstrap. L'impostazione predefinita è di effettuare la ricerca delle classi di bootstrap e delle risorse all'interno degli indirizzari VM interni e dei file .jar.
-Xbootclasspath/a:<directory e file zip o jar separati da:>
Accoda le directory specificate, i file jar o zip alla fine del percorso di classe di bootstrap. L'impostazione predefinita è di effettuare la ricerca delle classi di bootstrap e delle risorse all'interno degli indirizzari VM interni e dei file .jar.
-Xbootclasspath/p:<directory e file zip o jar separati da:>
Inserisce le directory specificate, i file jar o zip all'inizio del percorso di classe di bootstrap. Evitare di distribuire le applicazioni che utilizzano l'opzione -Xbootclasspath: o l'opzione -Xbootclasspath/p: per sovrascrivere una classe nell'API standard, poiché tale distribuzione contravverrebbe alla licenza sul codice binario di Java Runtime Environment. L'impostazione predefinita è di effettuare la ricerca delle classi di bootstrap e delle risorse all'interno degli indirizzari VM interni e dei file .jar.
|-Xcheck:classpath
|Visualizza un messaggio di avviso se viene rilevato un errore nel percorso della classe, |ad esempio, una directory mancante o un file JAR.
-Xcheck:gc[:<scan options>][:<verify options>][:<misc options>]
Esegue controlli supplementari sulla raccolta di dati obsoleti. Per impostazione predefinita, non viene effettuata alcuna verifica. Fare riferimento all'output -Xcheck:gc:help per ulteriori informazioni.
-Xcheck:jni
Esegue un'ulteriore verifica per le funzioni JNI. Per impostazione predefinita, non viene effettuata alcuna verifica.
|-Xcheck:memory[:<option>]
Identifica le perdite di memoria all'interno della JVM facendo ricorso a severi controlli che determinano l'arresto della JVM in caso di errore. Se non viene specificata alcuna opzione, all viene utilizzato per impostazione predefinita. Fare riferimento all'output -Xcheck:memory:help oppure alla Guida alla Diagnostica per ulteriori informazioni.
-Xcheck:nabounds
Esegue un'ulteriore verifica per le funzioni JNI. Per impostazione predefinita, non viene effettuata alcuna verifica.
-Xclassgc
Abilita la raccolta degli oggetti della classe per ogni raccolta di dati obsoleti. Consultare anche -Xnoclassgc. Per impostazione predefinita, questa opzione è abilitata.
-Xcodecache<size>
Imposta la dimensione dell'unità i cui blocchi di memoria sono allocati per memorizzare il codice nativo dei metodi compilati di Java. Una misura appropriata può essere scelta per eseguire l'applicazione. Per impostazione predefinita, questa opzione viene selezionata internamente all'architettura del CPU ed alla capacità del proprio sistema.
-Xcompactexplicitgc
Esegue la compattazione ad ogni chiamata a System.gc(). Consultare anche -Xnocompactexplicitgc. Per impostazione predefinita, la compressione avviene solo quando viene attivata internamente.
-Xcompactgc
Esegue una compattazione per ogni garbage collection. Consultare anche -Xnocompactgc. Per impostazione predefinita, la compressione avviene solo quando viene attivata internamente.
-Xconcurrentbackground<number>
Specifica il numero di thread di background a bassa priorità attribuiti per assistere i thread mutator nel contrassegno simultaneo. L'impostazione predefinita è 1.
-Xconcurrentlevel<number>
Specifica la velocità della "tax" di allocazione. Indica il rapporto tra la quantità di heap allocati e la quantità di heap contrassegnati. L'impostazione predefinita è 8.
-Xconmeter:<soa|loa|dynamic>
Determina quale utilizzo dell'area, LOA (Large Object Area) o SOA (Small Object Area), viene misurata e quindi quali allocazioni vengono tassate durante il contrassegno simultaneo. La tassa di allocazione viene applicata all'area selezionata. Se viene specificato -Xconmeter:dynamic, il collettore determina dinamicamente l'area da misurare a seconda di quale area si è esaurita per prima. Per impostazione predefinita, l'opzione è impostata su -Xconmeter:soa.
-Xdbg:<options>
Carica le librerie di debug per il supporto del debug remoto delle applicazioni. Fare riferimento a Esecuzione del debug nelle applicazioni Java per ulteriori informazioni. Specificare -Xrunjdwp fornisce lo stesso supporto.
-Xdebug
Avvia JVM con il debugger abilitato. Per impostazione predefinita, il programma di debug viene disabilitato.
-Xdisableexcessivegc
Disabilita l'attivazione di OutOfMemoryError se viene impiegato un tempo eccessivo nel GC. Per impostazione predefinita, questa opzione è disattivata.
-Xdisableexplicitgc
Segnala alla VM che le chiamate System.gc() non devono avere effetto. Per impostazione predefinita, le chiamate a System.gc() attivano una raccolta di dati obsoleti.
-Xdisablestringconstantgc
Impedisce la raccolta delle stringhe nella tabella interna alle stringhe. Per impostazione predefinita, questa opzione viene disabilitata.
-Xdisablejavadump
Disattiva la generazione del Javadump sugli errori e sui segnali. Per impostazione predefinita, viene abilitata la generazione del Javadump.
-Xenableexcessivegc
Se viene impiegato un tempo eccessivo in GC, questa opzione restituisce NULL per una richiesta di allocazione causando pertanto l'attivazione di OutOfMemoryError. Questa azione si verifica solo quando l'heap è stato completamente espanso e GC sta occupando il 95% del tempo disponibile. Questo è il comportamento predefinito.
-Xenableexplicitgc
Segnala alla VM che le chiamate a System.gc() devono attivare una garbage collection. Questo è il compilatore predefinito.
-Xenablestringconstantgc
Abilita la raccolta delle stringhe dalla tabella interna alle stringhe. Per impostazione predefinita, questa opzione è abilitata.
-Xfuture
Attiva i controlli del formato classe file severi. Utilizzare questo segnalatore durante lo sviluppo del nuovo codice, poiché i controlli severi diventeranno predefiniti nelle versioni successive. Per impostazione predefinita, i controlli severi del formato vengono disabilitati.
-Xgcpolicy:<optthruput|optavgpause|gencon|subpool> (lotto secondario su PPC e zSeries)
Controlli del comportamento del Raccoglitore di Dati obsoleti. Fare riferimento a Opzioni di Raccolta dei dati obsoleti per maggiori informazioni.
-Xgcthreads<number of threads>
Imposta il numero di thread dell'helper utilizzati per le operazioni parallele durante la raccolta di dati obsoleti. Per impostazione predefinita, il numero di thread viene impostato sul numero di CPU fisiche esistenti -1, con un minimo di 1.
-Xgcworkpackets<number>
Specifica il numero totale di pacchetti di lavoro disponibili nella raccolta globale. Se non specificato, il programma di raccolta alloca il numero di pacchetti basato sulla dimensione massima di heap.
-Xint
Rende possibile l'utilizzo da parte della JVM solo dell'Interprete, disabilitando il compilatore JIT (Just-In-Time). Per impostazione predefinita, il compilatore JIT è abilitato.
-Xiss<size>
Imposta la dimensione stack del thread di Java. 2 KB per impostazione predefinita. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
|-Xjarversion
|Consultare Come ottenere le informazioni di versione.
-Xjit[:<suboption>,<suboption>...]
Abilita lo JIT. Per ulteriori informazioni sulle opzioni secondarie, consultare la Guida alla Diagnostica. Consultare anche -Xnojit. Per impostazione predefinita, JIT è abilitato.
-Xlinenumbers
Visualizza i numeri della riga nelle tracce di stack, per effettuare il debug. Consultare anche -Xnolinenumbers. Per impostazione predefinita, i numeri della riga sono impostati su on.
-Xloa
Alloca una LOA (Large Object Area). Gli oggetti saranno allocati in questa LOA anziché nella SOA. Per impostazione predefinita, la LOA è abilitata per tutte le normative GC eccetto per il lotto secondario, in cui la LOA non è disponibile. Vedere anche -Xnoloa.
-Xloainitial<percentage>
<percentage> è compreso fra 0 e 0,95, che specifica la percentuale iniziale dello spazio corrente di possesso allocato su una LOA (Large Object Area). Il valore predefinito è 0,05 o 5%.
-Xloamaximum<percentage>
<percentage> è compreso fra 0 e 0,95, che specifica la percentuale massima dello spazio corrente di possesso allocato su una LOA (Large Object Area). Il valore predefinito è 0,5 o 50%.
-Xlp
Richiede che la JVM allochi l'heap di Java con pagine ampie. Se non sono disponibili pagine ampie, la JVM non si avvia, mostrando il messaggio di errore GC: la configurazione del sistema non supporta l'opzione --> '-Xlp'. La JVM utilizza shmget() per allocare pagine grandi per l'heap. Le pagine ampie sono supportate da sistemi che eseguono i kernel in versione v2.6 o successive di Linux oppure dei kernel precedenti in cui per il supporto alla pagina ampia è stato effettuato il backport dalla distribuzione. Per impostazione predefinita, le pagine grandi non vengono utilizzate. Consultare Configurazione dell'allocazione di memoria di pagine grandi.
-Xmaxe<size>
Imposta la quantità massima su cui il programma di raccolta dei dati obsoleti espanderà la memoria riservata. Di solito, il programma di raccolta dei dati obsoleti espande la memoria riservata quando lo spazio libero è al disotto del 30% (o la quantità specificata utilizzando -Xminf), in base alla quantità richiesta per ripristinare lo spazio libero al 30%. L'opzione -Xmaxe limita l'espansione al valore specificato; ad esempio, -Xmaxe10M limita l'espansione a 10 MB. Per impostazione predefinita, non esiste alcuna dimensione di espansione massima.
-Xmaxf<percentage>
Specifica la percentuale massima di memoria riservata che deve essere libera in seguito ad una raccolta di dati obsoleti. Se lo spazio libero supera tale quantità, JVM tenta di restringere la memoria limitata. Il valore predefinito è 0,6 (60%).
-Xmca<size>
Imposta il passo di espansione per la memoria allocata per memorizzare la parte RAM delle classi caricate. Ogni volta che viene richiesta più memoria per memorizzare le classi nella RAM, la memoria allocata viene aumentata da questa quantità. Per impostazione predefinita, il passo di espansione è di 32 Kb. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmco<size>
Imposta il passo di espansione per la memoria allocata per memorizzare la parte ROM delle classi caricate. Ogni volta che viene richiesta più memoria per memorizzare le classi nella ROM, la memoria allocata viene aumentata da questa quantità. Per impostazione predefinita, il passo di espansione è di 128 Kb. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmine<size>
Imposta la quantità minima per cui il programma di raccolta dei dati obsoleti espanderà la memoria riservata. Di solito, il programma di raccolta dati obsoleti, espande la memoria riservata in base alla quantità richiesta per ripristinare lo spazio libero al 30% (o la quantità specificata utilizzando -Xminf). L'opzione -Xmine imposta l'espansione affinché sia almeno uguale al valore specificato, ad esempio -Xmine50M imposta la dimensione di espansione su un minimo di 50 MB. Per impostazione predefinita, il passo di espansione minimo è di 1 MB.
-Xminf<percentage>
Specifica la percentuale minima di memoria riservata che deve essere libera in seguito ad una raccolta di dati obsoleti. Se lo spazio libero non raggiunge tale quantità, JVM tenta di espandere la memoria limitata. Per impostazione predefinita, il valore minimo è di 0,3 (30%).
-Xmn<size>
Imposta la dimensione iniziale e massima del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Impostare -Xmn è equivalente a impostare -Xmns and -Xmnx. Se si imposta -Xmns oppure -Xmnx, non è possibile impostare -Xmn. Se si cerca di impostare -Xmn con -Xmns oppure con -Xmnx, VM non verrà avviato e restituirà un errore. Per impostazione predefinita, -Xmn viene selezionato internamente in base alle caratteristiche del sistema. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmns<size>
Imposta la dimensione iniziale del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se si cercherà di utilizzarla con -Xmn. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmnx<size>
Imposta la dimensione massima del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se si cercherà di utilizzarla con -Xmn. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmo<size>
Imposta la dimensione iniziale e massima dell'heap precedente (di possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon.  equivalente all'impostazione sia di -Xmos che di -Xmox. Se si imposta -Xmos oppure -Xmox, non è possibile impostare -Xmo. Se si cerca di impostare -Xmo con -Xmos oppure con -Xmox, VM non verrà avviato e restituirà un errore. Per impostazione predefinita, -Xmo viene selezionato internamente in base alle caratteristiche del sistema. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmoi<size>
Imposta la quantità di cui l'heap Java viene incrementata quando si utilizza -Xgcpolicy:gencon. Se è impostata su zero, non viene consentita alcuna espansione. Per impostazione predefinita, la dimensione di incremento viene calcolata sulla dimensione di espansione -Xmine e -Xminf.
-Xmos<size>
Imposta la dimensione iniziale dell'heap precedente (possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se si cercherà di utilizzarla con -Xmo. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmox<size>
Imposta la dimensione massima dell'heap precedente (possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. Questa opzione restituirà un errore se si cercherà di utilizzarla con -Xmo. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmr<size>
Imposta la dimensione dell'"impostazione ricordata" della raccolta dati inutili quando si utilizza -Xgcpolicy:gencon. Questo è un elenco di oggetti della vecchia memoria riservata (posseduta) che si riferiscono ad oggetti nella nuova memoria riservata (asilo). Per impostazione predefinita, questa opzione viene impostata a 16 kilobyte. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmrx<size>
Imposta la dimensione massima ricordata.
-Xms<size>
Imposta la dimensione iniziale dell'heap di Java.  inoltre possibile utilizzare -Xmo. L'impostazione predefinita viene selezionata internamente in base alla capacità del proprio sistema. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmso<size>
Imposta la dimensione dello stack C dei thread di Java. Per impostazione predefinita, questa opzione è impostata su 32 KB su piattaforme a 32-bit e su 256 KB su piattaforme a 64-bit. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xmx<size>
Imposta la dimensione massima dell'heap di Java. Per impostazione predefinita, questa opzione viene selezionata internamente, in base alla capacità del proprio sistema. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xnoclassgc
Disabilita la raccolta disordinata di classi. Questa opzione disattiva la raccolta dei dati obsoleti della memorizzazione associata alle classi Java che non vengono più adoperate dalla JVM. Consultare anche -Xclassgc. Per impostazione predefinita, viene effettuata la garbage collection per la classe.
-Xnocompactexplicitgc
Disabilita la compattazione su una chiamata a System.gc(). Consultare anche -Xcompactexplicitgc. Per impostazione predefinita, la compressione è abilitata sulle chiamate a System.gc().
-Xnocompactgc
Disabilita il compattamento per il Raccoglitore di dati obsoleti. Consultare anche -Xcompactgc. Per impostazione predefinita, la compressione è abilitata.
-Xnojit
Disabilita il compilatore JIT. Consultare anche -Xjit. Per impostazione predefinita, il compilatore JIT è abilitato.
-Xnolinenumbers
Disabilita i numeri di riga per il debug. Consultare anche -Xlinenumbers. Per impostazione predefinita, i numeri della riga sono impostati su on.
-Xnoloa
Impedisce l'allocazione di una LOA (Large Object Area). Tutti gli oggetti saranno allocati nella SOA. Per impostazione predefinita, la LOA è abilitata per tutte le normative GC eccetto per il lotto secondario, in cui la LOA non è disponibile. Vedere anche -Xloa.
-Xnopartialcompactgc
Disabilita la compressione incrementale. Consultare anche -Xpartialcompactgc.
-Xnosigcatch
Disabilita il codice di gestione del segnale JVM. Consultare anche -Xsigcatch. Per impostazione predefinita, la gestione del segnale è abilitata.
-Xnosigchain
Disabilita il concatenamento della gestione del segnale. Consultare anche -Xsigchain. Per impostazione predefinita, il concatenamento della gestione del segnale è abilitato.
-Xoptionsfile=<file>
Specifica un file che contiene le opzioni JVM e esegue la definizione. Per impostazione predefinita, non viene utilizzato alcun file di opzioni.
-Xoss<size>
Imposta la dimensione dello stack e dello stack C di Java per tutti i thread. Questa opzione viene fornita per motivi di compatibilità ed equivale ad impostare sia -Xss che -Xmso sul valore specificato.
-Xpartialcompactgc
Abilita la compressione parziale. Per impostazione predefinita, questa opzione non viene impostata, pertanto tutte le compressioni sono piene. Consultare anche -Xnopartialcompactgc.
-Xquickstart
Migliora il tempo di avvio ritardando la compilazione e le ottimizzazioni dello JIT. Per impostazione predefinita, viene disabilitato quickstart e non vi è alcun ritardo nella compilazione dello JIT.
-Xrdbginfo:<host>:<port>
Carica e passa le opzioni al server di informazioni di debug remoto. Per impostazione predefinita, il server delle informazioni di debug remoto viene disabilitato.
-Xrs
Riduce l'utilizzo dei segnali del sistema operativo. Per impostazione predefinita, VM utilizza completamente i segnali del sistema operativo; per informazioni consultare Segnali usati dalla JVM.
-Xrun<library name>[:<options>]
Carica le librerie dell'helper. Per caricare più librerie, specificarle più volte nella riga comandi. Alcuni esempi di libreria sono:
-Xrunhprof[:help] | [:<opzione>=<valore>, ...]
Esegue heap, CPU, profili di controllo. Per ulteriori informazioni, consultare il manuale Guida alla Diagnostica.
-Xrunjdwp[:help] | [:<option>=< value>, ...]
Carica le librerie di debug per il supporto del debug remoto delle applicazioni. Consultare -Xdbg per maggiori informazioni.
-Xrunjnichk[:help] | [:<option>=<value>, ...]
Disapprovato, utilizzare -Xcheck:jni.
-Xscmx<size>
Per informazioni dettagliate su -Xscmx, consultare Abilitazione e configurazione della condivisione dei dati delle classi.
-Xshareclasses:<options>
Per i dettagli sulle opzioni -Xshareclasses, consultare Abilitazione e configurazione della condivisione dei dati delle classi.
-Xsigcatch
Abilita il codice di gestione del segnale VM. Consultare anche -Xnosigcatch. Per impostazione predefinita, la gestione del segnale è abilitata.
-Xsigchain
Abilita il concatenamento della gestione del segnale. Consultare anche -Xnosigchain. Per impostazione predefinita, il concatenamento della gestione del segnale è abilitato.
-Xsoftrefthreshold<number>
Imposta il numero di GC dopo i quali un riferimento variabile verrà eliminato se il relativo referente non è stato contrassegnato. Il valore predefinito è 3, cioè, al terzo GC in cui non viene contrassegnato il referente, il riferimento variabile verrà eliminato.
-Xss<size>
Imposta la dimensione massima dello stack di Java per tutti i thread. Per impostazione predefinita, questa opzione è impostata su 256 KB. Utilizzare l'opzione -verbose:sizes per emettere il valore utilizzato dalla VM.
-Xthr:<options>
Imposta le opzioni di thread.
-Xverbosegclog:<path to file>[X,Y]

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.

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

Appendice B. Limiti noti

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

Impostazioni di BIOS sui sistemi AMD64 SMP

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.

Tabella della Locale del tool di controllo della JConsole

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:

-Dcom.sun.management.jmxremote.port=<value>
Specifica la porta che il management agent deve ascoltare.
-Dcom.sun.management.jmxremote.authenticate=false
Disabilita l'autenticazione, a meno che non sia stato creato un file di nomi utente.
-Dcom.sun.management.jmxremote.ssl=false
Disabilita la cifratura SSL.

Il motore Rhino Javascript non è disponibile

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

Generazione lenta di coppie di chiavi DSA

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.

Creazione di una JVM che utilizza JNI

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.

Window managers e shortcut della tastiera

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.

Descrittori di file di X Window System

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.

DBCS e appunti KDE

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

Limiti sui thread che utilizzano la libreria dei LinuxThreads

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.

Limitazione del ThreadMXBean Thread User CPU Time

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.

KeyEvents e window managers

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.

X Window System e tasto Meta

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.

SIGSEGV quando si crea una JVM che utilizza JNI

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.

Mancanza di risorse nella applicazioni con thread multipli

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.

Server X e problemi di carattere del client

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.

Codifica UTF-8 ed eccezioni MalformedInputException

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

Problemi con AMI e xcin quando si esportano le visualizzazioni

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.

RHEL4 ed XIM

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.

RHEL4 e IIIMF

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.

RHEL4 e la locale zh_CN.GB18030

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.

RHEL4 e xcin

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

Problemi al cambiamento di fuoco di RHEL4 e IIIMF

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:

XIM e Plugin di Java

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:

  1. aprire il pannello di controllo del Plugin di Java ed andare alla tabella Java.
  2. Fare clic sul pulsante Visualizza nelle Impostazioni di Runtime dell'Applet Java.
  3. Immettere -Dsun.awt.noxembed=true nei Parametri di Runtime diJava e fare clic su OK.
  4. Fare clic su Applica.
  5. Avviare un browser.

Questa limitazione viene risolta in RHEL4 U3 e SLES9 SP3.

Caratteri arabi e schede video Matrox

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.

SLES9 NPTL e driver della porta parallela

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.

JNI richiama oltre otto parametri sulle piattaforme PPC

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

Operazioni della porta parallela su SLES9 prima di SP2

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.

Compilazione di libFileStat.so sulle piattaforme PPC a 64-bit

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.

IPv6 su piattaforme zSeries

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.

xcin su piattaforme zSeries a 64-bit

Solo piattaforme zSeries a 64-bit

Il server del metodo di input Cinese e Taiwanese (xcin) non è stato testato.

API Desktop Java

L'API Desktop Java può non funzionare in quanto una o più librerie di GNOME non sono disponibili.

NullPointerException con il Look and Feel GTK

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.

Alias del codepage unicode Shift_JIS

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.

Informazioni particolari

Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati Uniti d'America. IBM potrebbe non offrire i prodotti, i servizi, o le funzioni 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.

Marchi

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