Date: 2005-10-17

# IBM SDK e Runtime Environment per piattaforme Linux, Java 2 Technology Edition, Versione 5.0

# Guida per l'utente

# Informazioni sul copyright

Nota: Prima di usare questo prodotto e le relative informazioni, leggere le informazioni contenute nella sezione Informazioni particolari.

Questa edizione del manuale User Guide si applica a quanto segue:

- IBM 32-bit SDK e Runtime Environment per Linux su architettura Intel, Java 2 Technology Edition, Versione 5.0
- IBM 64-bit SDK e Runtime Environment per Linux su architettura AMD64/EM64T, Java 2 Technology Edition, Versione 5.0
- IBM 32-bit SDK e Runtime Environment per Linux su iSeries e pSeries, Java 2 Technology Edition, Versione 5.0
- IBM 64-bit SDK e Runtime Environment per Linux su iSeries e pSeries, Java 2 Technology Edition, Versione 5.0
- IBM 31-bit SDK e Runtime Environment per Linux su zSeries, Java 2 Technology Edition, Versione 5.0
- IBM 64-bit SDK e Runtime Environment per Linux su zSeries, Java 2 Technology Edition, Versione 5.0

e a tutti i successivi rilasci, versioni e modifiche se non diversamente specificato nelle nuove edizioni.

(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 USA. Tutti i diritti riservati.

(c) Copyright International Business Machines Corporation, 1999, 2005. Tutti i diritti riservati.

Limitazioni per gli utenti degli Stati Uniti d'America. L'uso, la duplicazione o la divulgazione sono limitati dal GSA ADP Schedule Contract con l'IBM Corporation.

# Prefazione

La Guida per l'utente fornisce informazioni generali su IBM(R) SDK e Runtime Environment per piattaforme Linux(TM), Java(TM) 2 Technology Edition, Versione 5.0 e informazioni specifiche sulle differenze dell'implementazione IBM confrontata con quella della Sun. Consultare questa Guida utente e l'altra documentazione dal sito Web di Sun: http://java.sun.com.

Per un elenco delle distribuzioni su cui sono stati testati SDK e Runtime Environment per Linux, consultare http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html.

Il manuale Diagnostics Guide fornisce informazioni più dettagliate sulla JVM IBM.

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

Le modifiche tecniche per questa Guida per l'utente versione 5.0, escluse quelle ovvie o di minor importanza, come l'aggiornamento da "1.4.2" a "5.0", vengono indicate in rosso durante la visualizzazione nella copia HTML o nella stampa a colori e tramite barre verticali nella parte sinistra delle modifiche.

# Indice

Informazioni sul copyright
Prefazione
Panoramica
Convenzioni
Compatibilità versione
Aggiornamento di SDK
Migrazione da altri IBM JVM
| |
Hardware supportato per zSeries
Contenuti di SDK e Runtime Environment
Tool Runtime Environment
Tool SDK
Installazione e configurazione di SDK e di Runtime Environment
Installazione su Red Hat Enterprise Linux (RHEL) 4
| |
Installazione di un SDK a 32 bit su un'architettura a 64 bit
Installazione da un file RPM
Installazione da un file .tgz
Configurazione di SDK e Runtime Environment per Linux
Impostazione di PATH
Impostazione di CLASSPATH
Disinstallazione di SDK e Runtime Environment per Linux
Disinstallazione del pacchetto RMP (Red Hat Package Manager) installabile
Disinstallazione del pacchetto TAR (Tape Archive) compresso
Utilizzo di Runtime Environment
Opzioni
Specifica di opzioni Java e proprietà del sistema
Opzioni standard
Opzioni non standard
Ricerca del numero di build IBM e del numero della versione
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 memorie riservate molto piene
Modalità di elaborazione di JVM dei segnali
Segnali usati da JVM
Collegamento di un driver di codice nativo alla libreria di segnale a catena
Gestione degli stack mobili
Trasformazione di documenti XML
Utilizzo di una versione precedente di Xerces o Xalan
Utilizzo di SDK per lo sviluppo di applicazioni Java
Esecuzione del debug nelle applicazioni Java
Java Debugger (JDB)
Come stabilire se l'applicazione esegue una JVM a 32 o 64 bit
Scrittura di applicazioni JNI
| |
Supporto per il recupero di livello-thread dei connettori bloccati
Operazioni con gli applet
Esecuzione delle applet con Applet Viewer
Esecuzione del debug delle applet con Applet Viewer
| |
Configurazione dell'allocazione di memoria di pagine grandi
Supporto CORBA
Supporto per GIOP 1.2
Supporto per Portable Interceptors
Supporto per Interoperable Naming Service
Proprietà di sistema per tracciare l'ORB
Proprietà di sistema per ottimizzare ORB
Autorizzazioni di sicurezza Java 2 per ORB
Classi di implementazione ORB
RMI su IIOP
Implementazione di Connection Handler Pool per RMI
Supporto bidirezionale avanzato
BigDecimal migliorato
Supporto del simbolo dell'Euro
Uso di Java Communications API (JavaComm)
Installazione delle API di Java Communications
Posizione dei file API di Java Communications
Configurazione di Java Communications API
Cambio della modalità di accesso delle porte seriali e parallele
Abilitazione delle porte seriali su IBM ThinkPads
Limitazioni di stampa con Java Communications API
Disinstallazione di Java Communications API
Disinstallazione del pacchetto RMP (Red Hat Package Manager) installabile
Disinstallazione del pacchetto TAR (Tape Archive) compresso
Documentazione di Java Communications API
Sviluppo di applicazioni Java
(Solo Linux IA a 32 bit e PPC32) 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
(solo Linux IA 32-bit, PPC32 e PPC64) Utilizzo di Web Start
Esecuzione di Web Start
Invio di applicazioni Java
| |
Condivisione di dati di classe tra JVM
| |
Panoramica sulla condivisione di classi
| |
Contenuto della cache
| |
Aggiornamento dinamico della cache
| |
Abilitazione della condivisione di classi
| |
Sicurezza della cache
| |
Intervallo di tempo valido della cache
| |
Programmi di utilità della cache
| |
Utilizzo di opzioni della riga comandi per la condivisione di classi
| |
Creazione, popolamento ed eliminazione di una cache
| |
Prestazioni e consumo della memoria
| |
Limitazioni e considerazioni sull'uso della condivisione di classi
| |
Limiti di dimensioni della cache
| |
Modifiche bytecode al runtime
| |
Limitazioni del sistema operativo
| |
Utilizzo di SharedClassPermissions
| |
Adattamento dei classloader personalizzati per la condivisione di classi
Servizio e supporto per fornitori di software indipendente
Accessibilità
Accessibilità iKeyman
Tastiera trasversale di componenti JComboBox in Swing
(Solo Linux IA 32-bit, PPC32 e PPC64) Accessibilità Web Start
Limiti noti
Limiti validi per tutte le piattaforme Linux tranne dove indicato
Limitazioni di Linux IA a 32 bit
Limitazioni di Linux AMD64
Limitazioni di Linux PPC a 32 bit e a 64 bit
Limitazioni di Linux PPC a 64 bit
Limitazioni di Linux zSeries a 64 bit
Limitazioni di Linux zSeries a 31 bit e a 64 bit
Inoltro dei commenti relativi a questa guida utente
Informazioni particolari
Marchi

# Panoramica

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

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

Runtime Environment contiene Java Virtual Machine e il supporto file tra cui i file di cui non è possibile eseguire il debug .so e class. Runtime Environment contiene solo un insieme secondario delle classi trovate in SDK e consente di supportare il programma Java all'avvio ma non consente di compilare programmi Java. Runtime Environment per Linux non include alcun tool di sviluppo, del tipo appletviewer o Java compiler (javac) o le classi che sono solo per i sistemi di sviluppo.

Inoltre, viene fornito il pacchetto API (application programming interface) di Java Communications per piattaforme IA32, PPC32 e AMD64/EM64T, per essere utilizzato con il Runtime Environment per Linux. Per informazioni, consultare la sezione Uso di Java Communications API (JavaComm).

Il file license_xx.html contiene l'accordo di licenza per il software di Runtime Environment per Linux. (xx è l'abbreviazione per la lingua.) Per visualizzare o stampare l'accordo di licenza, aprire il file in un browser Web.

## Convenzioni

In questa guida per l'utente, la directory di installazione predefinita di SDK è indicata come /opt/ibm/java2-i386-50/. Le piattaforme elencate di seguito hanno varie directory di installazione predefinite; sostituire la directory per la piattaforma che si sta utilizzando quando si vede /opt/ibm/java2-i386-50/:

- Linux IA 32 bit: /opt/ibm/java2-i386-50/
- Linux AMD 64 bit: /opt/ibm/java2-x86_64-50/
- Linux PPC 32 bit: /opt/ibm/java2-ppc-50/
- Linux PPC 64 bit: /opt/ibm/java2-ppc64-50/
- Linux zSeries 31 bit: /opt/ibm/java2-s390-50/
- Linux zSeries 64 bit: /opt/ibm/java2-s390x-50/

## Compatibilità versione

In genere, qualsiasi applet o applicazione eseguibile con una versione precedente di SDK dovrebbe funzionare correttamente con IBM SDK per Linux, v5.0. Non viene fornita alcuna garanzia che le classi compilate con questo rilascio funzionino con i rilasci precedenti.

Per leggere la documentazione della Sun relativa alla compatibilità, consultare il sito web della Sun Web su http://java.sun.com.

## Aggiornamento di SDK

Se si sta effettuando un aggiornamento di SDK da un rilascio precedente, effettuare il backup di tutti i file di configurazione e dei file dei criteri di protezione prima di proseguire con l'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 queli originali perché il formato o le opzioni dei file sono state modificate.

## Migrazione da altri IBM JVM

Alla Versione 1.4.2 per AMD64/EM64T e Versione 5 per le altre piattaforme Linux, IBM Runtime Environment per Linux contiene nuove versioni di IBM Java Virtual Machine e del compilatore Just-In-Time (JIT). Se si sta eseguendo la migrazione da una versione più vecchia di IBM Runtime Environment, notare che:

- La libreria condivisa libjvm.so JVM è installata nella directory jre/bin/j9vm. Ciò è diverso, ad esempio, da Runtime Environment per Linux per la Versione 1.4.2 (per tutte le piattaforme diverse da AMD64/EM64T), dove è installato in jre/bin/classic. Le applicazioni native che usano l'interfaccia di richiamo JNI potrebbero aver bisogno di aggiungere un nuovo percorso di directory nella loro variabile di ambiente o nelle variabili per localizzare la libreria a collegamento dinamico JVM.
- |JVMMI (JVM Monitoring Interface) non è più disponibile. |Bisogna riscrivere le applicazioni che utilizzano quella API. Si raccomanda di usare al suo posto JVMTI |(JVM Tool Interface). JVMTI non è funzionalmente equivalente a JVMMI. Per informazioni su JVMTI, consultare http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ e Diagnostics Guide.
- |La nuova implementazione di JNI è conforme alla specifica JNI ma differisce dalla vecchia |implementazione. Restituisce copie degli oggetti piuttosto che fissarli. La differenza può esporre ad errori nel codice di applicazione JNI. Per informazioni sul debug del codice JNI, consultare -Xcheck:jni in Opzioni non standard .
- |Il formato ed il contenuto del log dettagliato della raccolta di dati obsoleti ottenuti utilizzando |-verbose:gc sono cambiati. I dati vengono ora formattati come XML. Il contenuto dei dati riflette |le modifiche apportate all'implementazione della raccolta dei dati obsoleti in |JVM, ed è cambiata la maggior parte dei dati statistici in uscita. |Bisogna cambiare eventuali programmi che elaborano l'output GC in dettaglio in modo che possano lavorare con il nuovo formato e la |nuova data. Consultare Diagnostics Guide per un esempio dei nuovi dati GC dettagliati.
- Le versioni precedenti di IBM JRE inviate con un file rt.jar si trovano nella directory jre/lib. Da Java v1.4 in avanti, questo file è stato restituito da vari file JAR che risiedono nelle directory jre/lib.
- |Per ulteriori informazioni sulla compatibilità industriale e sulle api obsolete, consultare la |Sun's Java 5 Compatibility Documentation e Sun's Java 5 Depreciated API List

| | |

## Hardware supportato per zSeries

|

I SDK zSeries e Runtime Environment a 31 e 64 bit eseguono i seguenti server System z9 e zSeries o equivalenti:

|

|
- z9-109
|
- z990
|
- z900
|
- z890
|
- z800

# Contenuti di SDK e Runtime Environment

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

Le applicazioni scritte interamente in Java non devono avere dipendenze sulla struttura della directory di SDK IBM (o sui file in quelle directory). Qualunque dipendenza sulla struttura della directory SDK (o sui file in quelle directory) potrebbe comportare problemi di trasportabilità dell'applicazione.

## Tool Runtime Environment

- Classi core -- Questi sono i file di classe compilati per la piattaforma e devono rimanere impacchettati affinché il compilatore e l'interprete possa accedervi. Non modificare tali classi ma creare, invece, delle sotto-classi e ricoprire dove necessario.
- Tool JRE -- I seguenti tool sono parte di Runtime Environment e si trovano nella directory jre/bin, se non diversamente specificato.
  - java (Java Interpreter)
    - Esecuzione di classi Java. L'interprete Java esegue programmi scritti in linguaggio di programmazione Java.
  - javaw (Interprete Java)
    - Esegue le classi Java nello stesso modo del comando java ma non usa una finestra di console.
  - keytool (Tool di gestione chiave e certificato)
    - Gestisce un keystore (database) di chiavi private e le loro catene di certificati X.509 associati che autenticano le chiavi pubbliche.
  - policytool (Politica di creazione file e tool di gestione)
    - Crea e modifica i file di configurazione della politica esterna che definisce la propria politica di sicurezza Java dell'installazione.
  - rmid (daemon del sistema di attivazione RMI)
    - Avvia il daemon del sistema di attivazione in modo che gli oggetti possano essere registrati e attivati in un JVM (Java virtual machine).
  - tnameserv (servizio di assegnazione nomi CORBA (Common Object Request Broker Architecture)
    - Avvia il servizio CORBA di assegnazione transitoria dei nomi.
  - rmiregistry (Registro oggetto remoto Java)
    - Crea ed avvia un registro remoto dell'oggetto sulla porta specificata dell'host corrente.
  - ikeyman (programma di utilità della GUI iKeyman)
    - Consente di gestire chiavi, certificati e richieste di certificato. Per ulteriori informazioni consultare Security Guide e visitare il sito http://www.ibm.com/developerworks/java/jdk/security. SDK fornisce inoltre una versione da riga comandi di questa utility. Consultare Accessibilità iKeyman per informazioni dettagliate.
  - jextract (estrattore dump)
    - Converte un dump prodotto dal sistema in un formato comune che può essere usato da jdmpview. Per ulteriori informazioni, consultare il manuale Diagnostics Guide.
  - (Solo Linux IA 32-bit, PPC32 e PPC64) javaws (Java Web Start)
    - Abilita la distribuzione e la manutenzione automatica delle applicazioni Java.
  - (Solo Linux IA 32-bit, PPC32 e PPC64) |updateSettings.sh (Impostazioni Java Web Start)
    - Configura il sistema per l'uso di Web Start con il browser. Per ulteriori informazioni, consultare Esecuzione di Web Start. Questo file risiede nella directory jre/lib/javaws.

## Tool SDK

- I tool di seguito riportati sono parte di SDK e si trovano nella directory /opt/ibm/java2-i386-50/bin :
  - javac (Compilatore Java)
    - Compila programmi scritti in linguaggio di programmazione JAVA in o bytecode (codice Java compilato).
  - appletviewer (Visualizzatore Applet di Java)
    - Testa ed esegue applet al di fuori di un browser web.
  - jdb (Java Debugger)
    - Aiuta ad eseguire il debug dei propri programmi Java.
  - javap (Disassemblatore file di classe)
    - Disassembla i file compilati e può stampare una rappresentazione dei bytecode.
  - javadoc (Generatore di documentazione Java)
    - Genera pagine HTML di documentazione API dai file sorgente Java.
  - javah (Intestazione in C e generatore di file matrice)
    - Abilita l'associazione dei metodi nativi con il codice scritto in linguaggio di programmazione Java.
  - jar (Tool di archiviazione Java)
    - Combina file multipli in un singolo file JAR (Java Archive).
  - jarsigner (Firma JAR e tool di verifica)
    - Genera firme per i file JAR e verifica le firme dei file JAR firmati.
  - jconsole (JConsole Monitoring and Management Tool - sperimentale)
    - Tool grafico conforme a JMX (non supportato) per il controllo delle JVM locali e remote.
  - 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 (Convertitore matrice RMI (Remote Method Invocation) Java)
    - Genera matrici, strutture e congiunzioni per gli oggetti remoti. Include RMI oltre al supporto del protocollo RMI_IIOP (Internet Inter-ORB Protocol).
  - 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.
  - idlj (IDL su Java Compiler)
    - Genera un legame Java da un dato file IDL.
  - 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.
  - 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.
  - jdmpview (Programma di formattazione del dump di piattaforme incrociate)
    - Un tool che consente di analizzare i dump. Per ulteriori informazioni, consultare il manuale Diagnostics Guide.
  - (Solo Linux IA 32-bit, PPC32 e PPC64) htmlconverter (Programma di conversione HTML Java Plug-in)
    - Converte una pagina HTML contenente applet in un formato che può usare Java Plug-in.
- INCLUDI FILE
  - Intestazione in C per programmi JNI.
- DEMO
  - La directory demo contiene un numero di sottodirectory contenenti esempi di codifica sorgente, demo, applicazioni e applet da usare.
- COPYRIGHT
  - Notizie riguardanti il copyright del software SDK. per Linux
- LICENZA
  - Il file della LICENZA, /opt/ibm/java2-i386-50/docs/<locale>/license_<locale>.html, contiene l'accordo di licenza per il SDK per il software Linux (dove <locale> è il nome della locale, ad esempio En_US). Per visualizzare o stampare l'accordo di licenza, aprire il file in un browser Web.
- FIXES.LST
  - Un file di testo che descrive gli eventuali difetti che sono stati corretti dopo il rilascio iniziale di questa versione.

Nota: la Guida per l'utente, Javadoc, e la licenza che la accompagna , i file di copyright e la directory della demo sono l'unica documentazione inclusa in questo SDK per Linux. È possibile visualizzare o scaricare la documentazione del software di Sun dal sito Web di Sun: http://java.sun.com.

# Installazione e configurazione di SDK e di Runtime Environment

E' possibile installare IBM Java SDK e Runtime Environment sia da un file RPM che da un file .tgz. A meno che non 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/java2-i386-50/. Gli esempi in questa guida presuppongono che sia stato installato Java in questa directory.

## Installazione su Red Hat Enterprise Linux (RHEL) 4

SDK dipende dalle librerie condivise non installate per impostazione predefinita per Red Hat Enterprise Linux (RHEL) 4.0.

Gli RPM che contengono tali librerie sono:

- `compat-libstdc++-33-3.2.3` e `xorg-x11-deprecated-libs-6.8.1` (Intel Architecture, PPC e PPC64)
- `compat-libstdc++-295-2.95.3` e `xorg-x11-deprecated-libs-6.8.1` (zSeries)

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 Sistema Windows X, selezionare Dettagli e accertarsi di avere selezionato `xorg-x11-deprecated-libs`.
3. Dalle opzioni Sviluppo selezionare Sviluppo software Legacy.

| | |

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

1. Aprire una richiesta di shell, accertandosi di essere root.
2. In una richiesta di shell, immettere `rpm -ivh <file RPM>`. Ad esempio:

       |rpm -ivh ibm-java2-<arch>-sdk-5.0-0.0.<arch>.rpm

   oppure

       |rpm -ivh ibm-java2-<arch>-jre-5.0-0.0.<arch>.rpm

   |Dove `<arch>` rappresenta l'architettura: |i386, x86_64, ppc, ppc64, s390 o s390x.

## Installazione da un file .tgz

1. Creare una directory per memorizzare i file di pacchetto Java. Gli esempi in questa guida presuppongono che sia stato installato in /opt/ibm/java2-i386-50/. Nel resto della guida, sostituire /opt/ibm/java2-i386-50/ con la directory in cui si è installato Java.
2. A una richiesta di shell, immettere `tar -zxvf <file .tgz>`. Ad esempio:

       |tar -zxvf ibm-java2-sdk-50-linux-<arch>.tgz

   oppure

       |tar -zxvf ibm-java2-jre-50-linux-<arch>.tgz

   |Dove `<arch>` rappresenta l'architettura: |i386, x86_64, ppc, ppc64, s390 o s390x.

## Configurazione di SDK e Runtime Environment per Linux

### Impostazione di PATH

Notare che, se si altera la variabile di ambiente PATH come descritto di seguito, verrà ricoperto qualunque eseguibile Java esistente nel proprio percorso.

Dopo aver installato SDK, è possibile eseguire un tool immettendo il suo nome nel prompt della shell con un nome file come argomento.

E' possibile specificare il percorso immettendolo ogni volta prima del nome del tool. Ad esempio, se è installato SDK per Linux in /opt/ibm/java2-i386-50/bin, si può compilae un file cui è stato assegnato il nome myfile.java immettendo quanto segue ad una richiesta shell:

      /opt/ibm/java2-i386-50/bin/javac myfile.java

Per cambiare la variabile di ambiente PATH:

1. Modificare il file di avvio della shell nella propria home directory (di solito, .bashrc, in base alla propria shell) ed aggiungere i percorsi assoluti nella variabile di ambiente PATH; ad esempio:

       export PATH=/opt/ibm/java2-i386-50/bin:/opt/ibm/java2-i386-50/jre/bin:$PATH

2. Collegarsi di nuovo oppure eseguire lo script aggiornato della shell per attivare le nuove impostazioni di PATH.

### Impostazione di CLASSPATH

CLASSPATH dice ai tool del SDK, come java, javac e javadoc dove trovare le librerie della classe Java.

E' necessario impostare esplicitamente CLASSPATH solo se si applica una delle seguenti possiilità:

- Si richiede una libreria differente o un file di classe, come quello sviluppato, e che non si trova nella directory corrente.
- Si cambia l'ubicazione delle directory bin e lib in modo che non debbano avere più la stessa directory principale in comune.
- Si pianifica di sviluppare o di eseguire applicazioni che utilizzano differenti ambienti runtime sullo stesso sistema.

Per visualizzare il valore corrente del proprio CLASSPATH, immettere quanto segue alla richiesta shell:

      echo $CLASSPATH

Se si pianifica di sviluppare ed eseguire applicazioni che usano differenti ambienti runtime, comprese altre versioni installate separatamente, bisogna impostare esplicitamente CLASSPATH (e PATH) per ciascuna applicazione. Se si pianifica di eseguire applicazioni multiple simultaneamente e si usano differenti ambienti runtime, ciascuna applicazione deve eseguire la sua propria shell.

Se si vuole eseguire solo una versione di Java alla volta, è possibile usare lo script shell per passare tra i diversi ambienti runtime.

Nota:
(solo per gli utenti di Linux IA a 32 bit in 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.

## Disinstallazione di SDK e Runtime Environment per Linux

Il processo utilizzato per rimuovere SDK e Runtime Environment 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) installabile

Per disinstallare SDK o Runtime Environment per Linux con installato il pacchetto RMP installabile:

1. In una richiesta shell,
   1. Per verificare quali pacchetti RPM sono stati installati , immettere:

          rpm -qa | grep -i java

   2. Verrà visualizzato un elenco di pacchetti IBM Java installati, ad esempio:

          ibm-java2-<arch>-jre-5.0-0.0.<arch>
          ibm-java2-<arch>-sdk-5.0-0.0.<arch>

   3. Tale output indica quali pacchetti è possibile disinstallare utilizzando il comando `rpm -e`; ad esempio:

          rpm -e ibm-java2-<arch>-jre-5.0-0.0.<arch>
          rpm -e ibm-java2-<arch>-sdk-5.0-0.0.<arch>

   In alternativa, è possibile utilizzare uno strumento grafico, come ad esempio kpackage oppure yast2
2. Rimuovere dall'istruzione PATH la directory in cui sono stati installati SDK e Runtime Environment.
3. (Solo per Linux IA a 32 bit e PPC32) Se è stato installato il plug-in Java, rimuovere i relativi file dalla directory del browser Web.

### Disinstallazione del pacchetto TAR (Tape Archive) compresso

Per disinstallare SDK o Runtime Environment per Linux se è stato estratto il pacchetto RMP compresso:

1. Rimuovere i file SDK o Runtime Environment dalla directory in cui è stato installato SDK o Runtime Environment.
2. Rimuovere dall'istruzione PATH la directory in cui è stato installato SDK o Runtime Environment.
3. Collegarsi nuovamente o eseguire lo script shell per attivare la nuova impostazione PATH.
4. (Solo per Linux IA a 32 bit e AMD64/EM64T) Se è stato installato il plug-in Java, rimuovere i relativi file dalla directory del browser Web.

# Utilizzo di Runtime Environment

Lo strumento java avvia un'applicazione Java avviando Java Runtime Environment e caricando una classe specificata.

JVM ricerca la classe di avvio (e le altre classi utilizzate) in tre serie di ubicazioni: il percorso classe di bootstrap, le estensioni installate e il percorso di classe utente. Gli argomenti specificati dopo il nome classe o il nome file JAR vengono passati alla funzione principale.

Il comando javaw è identico a java, tranne javaw che non ha alcuna finestra di console associata. Usare javaw quando non si desidera che venga visualizzata una finestra di richiesta comandi. Il programma di avvio javaw visualizza una casella di dialogo con le informazioni sugli errore nel caso in cui l'avvio abbia esito negativo.

I comandi java e javaw hanno la seguente sintassi:

    java [ opzioni ] classe [ argomenti ... ]
    java [ opzioni ] -jar file.jar [ argomenti ... ]
    javaw [ opzioni ] classe [ argomenti ... ]
    javaw [ opzioni ] -jar file.jar [ argomenti ... ]

Le voci tra parentesi sono facoltative.

opzioni
  Opzioni della riga comandi.
classe
  Il nome della classe da richiamare.
file.jar
  Il nome del file jar da richiamare. Utilizzato solo con -jar.
argomenti
  Argomenti passati alla funzione principale.

Se si specifica l'opzione -jar, il file JAR denominato contiene i file di risorsa e classe per l'applicazione, insieme alla classe di startup specificata nell'intestazione manifest Main-Class.

## Opzioni

Il programma di avvio ha una serie di opzioni standard supportate nell'ambiente di runtime corrente e che saranno supportate dai release successivi. Vi sono inoltre, una serie di opzioni non standard. Le opzioni predefinite sono state scelte per garantire le prestazioni migliori per gli utilizzi più comuni. Ponderare attentamente eventuali modifiche.

### Specifica di opzioni Java e proprietà del sistema

È possibile specificare le opzioni Java e le proprietà di sistema in tre modi diversi. In ordine di precedenza, tali modi sono:

1. Specificare l'opzione o la proprietà sulla riga comandi, ad esempio `java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass`.
2. Creare un file che contiene le opzioni e specificarlo sulla riga comandi utilizzando -Xoptionsfile=<nomefile>.
3. Creare una variabile d'ambiente denominata 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 precedenza su quelle più a sinistra; ad esempio se si specifica `-Xint -Xjit myClass`, -Xjit ha la precedenza.

### Opzioni standard

- -D<nome_proprietà>=<valore>
  - Imposta una proprietà di sistema.
- -assert
  - Visualizza l'aiuto sulle opzioni correlate all'asserzione.
- -cp o -classpath <directory e file zip o jar separati da :>
  - Imposta il percorso di ricerca per risorse e classi dell'applicazione. Se non vengono utilizzate -classpath e -cp e non si imposta CLASSPATH il classpath utente è predefinito sulla directory corrente (.).
- -help o -?
  - Visualizza le informazioni relative all'utilizzo.
- -showversion
  - Visualizza la versione del prodotto e continua.
- -verbose:[classe,gcterse,gc,dynload,stackwalk,dimensioni,stack,debug,jni]
  - Abilita l'output dettagliato.
- -version
  - Visualizza la versione del prodotto.
- -version:<valore>
  - Richiede l'esecuzione della versione specificata.
- -jre-restrict-search
  - Include i JRE provati dell'utente nella ricerca della versione
- -no-jre-restrict-search
  - Esclude i JRE provati dell'utente dalla ricerca della versione
- -agentlib:<nomelib>[=<opzioni>]
  - load native agent library <nomelib>, ad esempio -agentlib:hprof. Per ulteriori informazioni, specificare -agentlib:jdwp=help e -agentlib:hprof=help sulla riga comandi.
- -agentpath: nomelib[=<opzioni>]
  - Caricare la libreria dell'agente nativo per nome percorso completo
- -javaagent:<percorsojar>[=<opzioni>]
  - Caricare l'agente di programmazione Java; per ulteriori informazioni, consultare la documentazione dell'API java.lang.instrument.
- -X
  - Visualizza le istruzioni relative alle opzioni non standard.

### Opzioni non standard

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

Per opzioni che assumono il parametro <dimensione>, occorre aggiungere come suffisso il numero "k" o "K" per indicare i kilobyte, "m" o "M" per indicare i megabyte e "g" o "G" per indicare i gigabyte.

- -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. Non distribuire le applicazioni che utilizzano l'opzione -Xbootclasspath: o -Xbootclasspath/p: per sovrascrivere una classe nell'API standard, perché tale distribuzione contravverrebbe alla licenza sul codice binario di Java 2 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:jni
  - Esegue un'ulteriore verifica per le funzioni JNI. E' possibile utilizzare anche -Xrunjnichk. Per impostazione predefinita, non viene effettuata alcuna verifica.
- -Xcheck:nabounds
  - Esegue un'ulteriore verifica per le operazioni di matrice JNI. E' possibile utilizzare anche -Xrunjnichk. Per impostazione predefinita, non viene effettuata alcuna verifica.
- |-Xclassgc |
  |
  - Questa opzione abilita la raccolta di oggetti classe ad ogni raccolta di dati obsoleti. |Per impostazione predefinita, tale opzione è abilitata.
- -Xcompactexplicitgc
  - Eseguire la compattazione in ciascuna chiamata a `System.gc ().` Consultare anche -Xnocompactexplicitgc. Per impostazione predefinita, la compressione avviene solo quando viene attivata internamente.
- -Xcompactgc
  - Compattare ciascun ciclo del Raccoglitore di Dati obsoleti. Consultare anche -Xnocompactgc. Per impostazione predefinita, la compressione avviene solo quando viene attivata internamente.
- |-Xconcurrentbackground <numero> |
  |
  - Questa opzione specifica il numero di thread in secondo piano a bassa priorità allegati per assistere i thread mutator nel contrassegno simultaneo. L'impostazione predefinita è 1.
- |-Xconcurrentlevel <numero> |
  |
  - Questa opzione specifica una velocità "tax" di allocazione. Indica il rapporto tra la quantità di heap allocati e la quantità di heap contrassegnati. L'impostazione predefinita è 8.
- |-Xconmeter:<soa | loa | dynamic> |
  |
  - Questa opzione determina quale utilizzo dell'area, LOA o SOA, viene misurata e pertanto quali allocazioni vengono tassate durante il contrassegno simultaneo. Utilizzando -Xconmeter:soa viene applicata una tassa di allocazione alle allocazioni provenienti da una SOA (small object area), |utilizzando -Xconmeter:loa viene applicata la tassa di allocazione ad allocazioni provenienti da una LOA (large object area). Se viene specificato -Xconmeter:dynamic , il programma di raccolta determina in modo dinamico quale area misurare sulla base di quale area si è esaurita prima, se sia SOA o LOA. Per impostazione predefinita, l'opzione è impostata su -Xconmeter:soa.
- -Xdbg:<opzioni>
  - Carica le librerie di debug per il supporto del debug remoto delle applicazioni. È uguale a -Xrunjdwp. Per impostazione predefinita, le librerie di debug non vengono caricate e l'istanza VM non viene abilitata al debug.
- -Xdbginfo:<percorso per il file simboli>
  - Carica e passa opzioni al server di informazioni di debug. Per impostazione predefinita, il server delle informazioni di debug viene disabilitato.
- -Xdebug
  - Avvia JVM con il debugger abilitato. Per impostazione predefinita, il programma di debug viene disabilitato.
- |-Xdisableexcessivegc |
  |
  - Questa opzione disabilita l'attivazione di un'eccezione OutOfMemory se viene impiegato un Qutime eccessivo nel GC. Per impostazione predefinita questa opzione è off.
- -Xdisableexplicitgc
  - I segnali al VM che chiama `System.gc()` non devono avere effetto. Per impostazione predefinita, chiamate a `System.gc()` attivano una raccolta di dati obsoleti.
- |-Xdisablestringconstantgc |
  |
  - Questa opzione impedisce alle stringhe di essere raccolte nella tabella interna delle stringhe. |Per impostazione predefinita, tale opzione è disabilitata.
- -Xdisablejavadump
  - Disattiva la generazione javadump in caso di errori e segnali. Per impostazione predefinita, la generazione di javadump è disabilitata.
- |-Xenableexcessivegc |
  |
  - Se viene impiegato un tempo eccessivo in GC, questa opzione restituisce NULL per una richiesta di allocazione e pertanto provoca l'attivazione di un'eccezione OutOfMemory. Questa azione si verifica solo quando l'heap è stato espanso completamento e il tempo impiegato è di almeno il 95%. Questo è il comportamento predefinito.
- |-Xenablestringconstantgc |
  |
  - Questa opzione abilita la raccolta delle stringhe nella tabella interna delle stringhe. |Per impostazione predefinita, tale 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 nei rilasci successivi. 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. L'opzione optthruput è il valore predefinito e consente una capacità di elaborazione elevata alle applicazioni, ma comporta pause occasionali. L'opzione optavgpause riduce il tempo impiegato per queste pause di raccolta dati obsoleti e limita l'effetto dell'incremento della memoria riservata nella lunghezza della pausa della raccolta dei dati obsoleti. Utilizzare optavgpause se la configurazione ha una memoria riservata molto grande. L'opzione gencon richiede l'uso combinato della raccolta dati simultanea e generazionale per ridurre il tempo impiegato nella pausa della raccolta dei dati obsoleti. |L'opzione subpool utilizza un algoritmo di allocazione degli oggetti migliorati per acquisire migliori prestazioni quando gli oggetti vengono allocati nell'heap. Questa opzione potrebbe migliorare le prestazioni su sistemi SMP di grandi dimensioni. Per ulteriori informazioni, fare riferimento a Specifica della politica di raccolta dei dati obsoleti.
- -Xgcthreads< numero di thread>
  - Imposta il numero di thread dell'helper utilizzati per le operazioni parallele durante la raccolta di dati obsoleti. Per impostazione predefinita, il numero di thread viene impostato sul numero di CPU fisiche esistenti -1, con un minimo di 1.
- |-Xgcworkpackets <numero> |
  |
  - Questa opzione specifica il numero totale di pacchetti di lavoro disponibili nella raccolta globale. Se non specificata, il programma di raccolta alloca il numero di pacchetti basato sulla dimensione massima di heap.
- -Xint
  - Fa in modo che JVM utilizzi solo Interpreter, disabilitando il compilatore Just-In-Time (JIT). Per impostazione predefinita, l compilatore JIT è abilitato.
- -Xiss<dimensione>
  - Imposta la dimensione di stack dei thread Java iniziale. Per impostazione predefinita, 2 kilobyte.
- -Xjit[:<opzionesecondaria>,<opzionesecondaria>,...]
  - Abilita JIT. Per ulteriori informazioni, consultare il manuale Diagnostics Guide. 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 |
  |
  - Questa opzione 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 <numero> |
  |
  - <numero> è un numero compreso tra 0 e 0,95, che specifica la percentuale iniziale dello spazio di possesso attuale allocato su una LOA (large |object area). Il valore predefinito è 0,05 o 5%.
- |-Xloamaximum <numero> |
  |
  - <numero> è un numero compreso tra 0 e 0,95, che specifica la percentuale massima dello spazio di possesso attuale allocato su una LOA (large |object area). Il valore predefinito è 0,5 o 50%.
- -Xlp
  - Richiede alla JVM di allocare l'heap di Java con pagine grandi. Se le pagine grandi non sono disponibili, JVM non verrà avviato, visualizzando un messaggio di errore simile al seguente: `GC: la configurazione di sistema non supporta l'opzione --> '-Xlp'`. La JVM utilizza shmget() per allocare pagine grandi per l'heap. Le pagine grandi sono supportate dai sistemi che eseguono dei kernel Linux v2.6 o successive, oppure kernel precedenti dove è strato effettuato il backport del supporto delle pagine grandi dalla distribuzione. Per impostazione predefinita, le pagine grandi non vengono utilizzate. Consultare Configurazione dell'allocazione di memoria di pagine grandi.
- -Xmaxe<dimensione>
  - Imposta la quantità massima su cui il 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 ha una quantità compresa tra il 30% (o la quantità specificata utilizzando -Xminf), in base alla quantità richiesta per ripristinare lo spazio libero al 30%. L'opzione -Xmaxe limita l'espansione al valore specificato, ad esmepio `-Xmaxe10M` limita l'espansione a 10 MB. Per impostazione predefinita, non esiste alcuna dimensione di espansione massima.
- -Xmaxf<dimensione >
  - 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. Specificare la dimensione come valore decimale, con un intervallo 0-1, ad esempio `-Xmaxf0.5` imposta lo spazio libero massimo sul 50%. Il valore predefinito è 0,6 (60%).
- -Xmca<dimensione>
  - Imposta il passo di espansione per la memoria allocata per memorizzare la parte RAM delle classi caricate. Ogni volta che viene richiesta più memoria per memorizzare le classi nella RAM, la memoria allocata viene aumentata da questa quantità. Per impostazione predefinita, il passo di espansione è di 32 Kb.
- -Xmco<dimensione >
  - Imposta il passo di espansione per la memoria allocata per memorizzare la parte ROM delle classi caricate. Ogni volta che viene richiesta più memoria per memorizzare le classi nella ROM, la memoria allocata viene aumentata da questa quantità. Per impostazione predefinita, il passo di espansione è di 128 Kb.
- -Xmine<dimensione>
  - 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 per essere 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 è di 1 Mb.
- -Xminf<dimensione >
  - 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. Specificare la dimensione come valore decimale compreso nell'intervallo 0-1, ad esempio un valore `-Xminf0.3` richiede che lo spazio libero minimo sia il 30% della memoria riservata. Per impostazione predefinita, il valore minimo è di 0,3.
- -Xmn<dimensione>
  - Imposta la dimensione iniziale e massima del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. E' equivalente all'impostazione sia di -Xmns che di -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. È possibile utilizzare l'opzione -verbose:sizes per individuare i valori utilizzati attualmente da VM.
- -Xmns<dimensione>
  - Imposta la dimensione iniziale del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. |Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmn.
- -Xmnx<dimensione>
  - Imposta la dimensione massima del nuovo heap (asilo) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. |Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmn.
- -Xmo<dimensione >
  - Imposta la dimensione iniziale e massima dell'heap precedente (di possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. E' equivalente all'impostazione sia di -Xmos che di -Xmox. |Se si imposta -Xmos oppure -Xmox, non è possibile impostare -Xmo. Se si cerca di impostare |-Xmo con -Xmos oppure con -Xmox, VM non verrà avviato e restituirà un errore. Per impostazione predefinita, -Xmo viene selezionato internamente in base alle caratteristiche del sistema. È possibile utilizzare l'opzione -verbose:sizes per individuare i valori utilizzati attualmente da VM.
- -Xmos<dimensione>
  - Imposta la dimensione iniziale dell'heap precedente (possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. |Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmo.
- -Xmox<dimensione>
  - Imposta la dimensione massima dell'heap precedente (possesso) sul valore specificato quando si utilizza -Xgcpolicy:gencon. Per impostazione predefinita, questa opzione viene selezionata internamente in base alle caratteristiche del sistema. |Questa opzione restituirà un errore se di cerca di utilizzarla con -Xmo.
- -Xmoi<dimensione>
  - Imposta la quantità di heap Java incrementata quando si utilizza -Xgcpolicy:gencon. Se è impostata su zero, non viene consentita alcuna espansione. Per impostazione predefinita, la dimensione di incremento viene calcolata sulla dimensione di espansione -Xmine e -Xminf.
- -Xmr<dimensione >
  - 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.
- -Xms<dimensione>
  - Imposta la dimensione della memoria riservata Java iniziale. È possibile anche utilizzare -Xmo. Il valore predefinito viene impostato internamente in base alle caratteristiche del sistema.
- -Xmso<dimensione>
  - Imposta la dimensione dello stack C dei thread duplicati. Per impostazione predefinita, questa opzione viene impostata a 32 kilobyte su piattaforme a 32 bit e 256 kilobyte per piattaforme a 64 bit.
- -Xmx<dimensione>
  - Imposta la dimensione massima di memoria riservata Java. Per impostazione predefinita, questa opzione viene impostata internamente in base alle caratteristiche del sistema.
- -Xnoclassgc
  - Disabilita la raccolta disordinata di classi. Disattiva la raccolta dei dati obsoleti della memoria associata alle classi Java che non sono più utilizzate da JVM. La funzionalità predefinita è -Xclassgc.
- -Xnocompactgc
  - Disabilita il compattamento per il Raccoglitore di dati obsoleti. Consultare anche -Xcompactgc. Per impostazione predefinita, la compressione è abilitata.
- -Xnocompactexplicitgc
  - Disabilita la compattazione su una chiamata a `System.gc()`. Consultare anche -Xcompactexplicitgc. Per impostazione predefinita, la compressione è abilitata sulle chiamate a `System.gc()`.
- -Xnojit
  - Disabilita il compilatore JIT. Consultare anche -Xjit. Per impostazione predefinita, l compilatore JIT è abilitato.
- -Xnolinenumbers
  - Disabilita i numeri di riga per il debug. Consultare anche -Xlinenumbers. Per impostazione predefinita, i numeri della riga sono impostati su on.
- |-Xnoloa |
  |
  - Questa opzione 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. Per impostazione predefinita, questa opzione non viene impostata, pertanto tutte e compressioni sono piene.
- -Xnosigcatch
  - Disabilita il codice di gestione del segnale JVM. Consultare anche -Xsigcatch. Per impostazione predefinita, la gestione del segnale è abilitata.
- -Xnosigchain
  - Disabilita il concatenamento della gestione del segnale. Consultare anche -Xsigchain. Per impostazione predefinita, il concatenamento della gestione del segnale è abilitato.
- -Xoptionsfile=<file>
  - Specifica un file che contiene le opzioni JVM e esegue la definizione. Per impostazione predefinita, non viene utilizzato alcun file di opzioni.
- -Xoss<dimensione>
  - Imposta la dimensione di stack Java e la dimensione di stack C per tutti i thread. Questa opzione è fornita per motivi di compatibilità ed è equivalente ad impostare sia -Xss che -Xmso sul valore specificato.
- -Xpartialcompactgc
  - Abilita la compressione parziale. Consultare anche -Xnopartialcompactgc.
- -Xquickstart
  - Migliora il tempo di avvio ritardando la compilazione JIT e le ottimizzazioni. Per impostazione predefinita, viene disabilitato quickstart e non vi è alcun ritardo nella compilazione JIT.
- -Xrdbginfo:<host>:<porta>
  - Carica e passa le opzioni al server di informazioni di debug remoto. Per impostazione predefinita, il server delle informazioni di debug remoto viene disabilitato.
- -Xrs
  - Riduce l'utilizzo dei segnali del sistema operativo. Per impostazione predefinita, VM utilizza completamente i segnali del sistema operativo; per informazioni consultare Segnali usati da JVM .
- -Xrun<nome libreria[: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 Diagnostics Guide.
    - -Xrunjdwp[:help] | [:<opzione>=<valore>, ...]
      - Carica le librerie di debug per il supporto del debug remoto delle applicazioni. È uguale a -Xdbg. Per ulteriori informazioni, fare riferimento a Esecuzione del debug nelle applicazioni Java.
    - -Xrunjnichk[:help] | [:<opzione>=<valore>, ...]
      - Effettua verifiche aggiuntive per le funzioni JNI, per effettuare la traccia degli errori in programmi nativi che accedono a JVM utilizzando JNI. Per ulteriori informazioni, consultare il manuale Diagnostics Guide.
- |-Xscmx<dimensione>[k|m|g] |
  |
  - Per informazioni dettagliate su -Xscmx, consultare Utilizzo di opzioni della riga comandi per la condivisione di classi.
- |-Xshareclasses:<opzioni secondarie> |
  |
  - Per informazioni dettagliate sulle opzioni secondarie -Xshareclasses, consultare Utilizzo di opzioni della riga comandi per la condivisione di classi.
- -Xsigcatch
  - Abilita il codice di gestione del segnale VM. Consultare anche -Xnosigcatch. Per impostazione predefinita, la gestione del segnale è abilitata.
- -Xsigchain
  - Abilita il concatenamento della gestione del segnale. Consultare anche -Xnosigchain. Per impostazione predefinita, il concatenamento della gestione del segnale è abilitato.
- |-Xsoftrefthreshold<numero> |
  |
  - Questa opzione imposta il numero di GC dopo i quali un riferimento soft verrà eliminato se il relativo referente non è stato contrassegnato. Il valore predefinito è 3, cioè, al terzo GC in cui non viene contrassegnato il referente, il riferimento soft verrà eliminato.
- -Xss<dimensione>
  - Imposta la dimensione di stack Java massima per tutti i thread.Per impostazione predefinita, questa opzione è impostata su 256 KB. Per ulteriori informazioni, consultare Gestione degli stack mobili.
- -Xthr:<opzioni>
  - Imposta le opzioni di thread.
- -Xverbosegclog:<percorso per il file><nomefile>[X, Y]
  - Comporta che l'output verboseGC 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 verboseGC viene indirizzato sul numero X di file, ciascuno contenente il numero Y di cicli gc valido per l'output verboseGC. Questi file hanno il formato nomefile1, nomefile2 e così via. Per impostazione predefinita, non viene effettuato alcun log verboso della raccolta di dati inutili.
- -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.

## Ricerca del numero di build IBM e del numero della versione

Per ottenere il numero di build IBM e la versione, ad una richiesta comandi shell immettere:

    java -version

## Globalizzazione dei comandi java

Il comando java e altri comandi di java (ad esempiojavaw) consentono di specificare un nome classe con un qualsiasi carattere del set di caratteri della locale corrente.

È possibile anche specificare un qualsiasi carattere Unicode nel nome classe e gli argomenti utilizzando le sequenze di escape java. Per eseguire tale operazione, occorre specificare -Xargencoding. Per specificare un carattere Unicode, utilizzare sequenze di escape nel formato `\u####`, dove # è una cifra esadecimale (da 0 a 9, dalla A alla F).

In alternativa, per specificare che il nome classe e gli argomenti comando sono con codifica UTF8, utilizzare -Xargencoding:utf8 oppure con codifica ISO8859_1 utilizzando -Xargencoding:latin.

Ad esempio, per specificare una classe denominata "HelloWorld" utilizzando la codifica Unicode a lettere maiuscole, si utilizzerà questo comando:

    java -Xargencoding '\u0048ello\u0057orld'

I comandi java e javaw forniscono messaggi di output tradotti. Tali messaggi differiscono in base alla lingua in cui Java è in esecuzione. Le descrizione di errore dettagliate e le altre informazioni di debug restituite da java sono in Inglese.

## Compilatore Just-In-Time (JIT)

Il compilatore IBM JIT (Just-In-Time) genera dinamicamente il codice macchina per le sequenze di bytecode usate frequentemente nelle applicazioni Java e nelle applet mentre sono in esecuzione.|Il compilatore JIT V5.0 fornisce nuove ottimizzazioni risultati dalla ricerca del compilatore, migliora le ottimizzazioni implementate nelle precedenti versioni del JIT e fornisce un migliore utilizzo dell'hardware.

IBM SDK e Runtime Environment includono JIT, abilitato per impostazione predefinita nelle applicazioni utente e nei tool SDK. Di norma, non è necessario richiamare esplicitamente JIT; la compilazione del bytecode Java in codice macchina avviene in maniera trasparente. Tuttavia, se si incontra un problema con Runtime Environment mentre si esegue un'applicazione o un'applet Java, è possibile disabilitare JIT per facilitare l'isolamento del problema. La disabilitazione di JIT deve essere una soluzione solo temporanea; per prestazioni soddisfacenti è richiesto JIT.

### Come disabilitare JIT

Esistono tre modi per disabilitare JIT:

- Impostare la variabile d'ambiente JAVA_COMPILER su "NONE" o la stringa vuota prima di eseguire l'applicazione Java.

  Da una richiesta comandi, immettere quanto segue:

  1. Per il Korn shell:

     -     export JAVA_COMPILER=NONE

       (I comandi Korn shell sono usati come promemoria di questa Guida per l'utente.)

  2. Per il Bourne shell:

     -     JAVA_COMPILER=NONE

     -     export JAVA_COMPILER

  3. Per il C shell:

     -     setenv JAVA_COMPILER NONE

- Utilizzare l'opzione -D sulla riga comandi della JVM per impostare la proprietà java.compiler su "NONE" o sulla stringa vuota:

      java -Djava.compiler=NONE MyApp

- Utilizzare l'opzione -Xint sulla riga comandi della JVM. Ad esempio:

      java -Xint MyApp

Entrambe le opzioni di riga comandi sovrascrivono la variabile d'ambiente JAVA_COMPILER.

### Come abilitare JIT

Per abilitare JIT esplicitamente, impostare la variabile d'ambiente JAVA_COMPILER su "jitc", oppure utilizzare l'opzione -D per impostare la proprietà java.compiler su "jitc". In alternativa, utilizzare l'opzione -Xjit (e omettere l'opzione -Xint) sulla riga comandi JVM per attivare JIT.

Se la variabile d'ambiente JAVA_COMPILER o la proprietà java.compiler sono impostate su "" (stringa vuota), JIT resta disabilitato. Per annullare l'impostazione della variabile d'ambiente, immettere `unset JAVA_COMPILER` alla richiesta della shell.

### Come determinare se JIT è abilitato

Per verificare se JIT è abilitato, immettere quanto segue da una richiesta comandi:

    java -version

Se JIT non è in uso, viene visualizzato un messaggio che comprende quanto segue:

    (JIT disabilitato)

Se JIT è in uso, viene visualizzato un messaggio che comprende quanto segue:

    (JIT abilitato)

Per ulteriori informazioni su JIT, consultare Diagnostics Guide.

## Specifica della politica di raccolta dei dati obsoleti

La raccolta dei dati obsoleti gestisce la memoria usata da Java e dalle applicazioni in esecuzione all'interno del VM.

Quando Recupera spazio riceve una richiesta per la memorizzazione, la memoria heap non usata viene impostata a parte - "assegnazione". La raccolta dei dati obsoleti controlla inoltre le aree di memoria cui non si fa più riferimento e le rilascia per il riutilizzo - "raccolta".

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

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

Per ulteriori informazioni, consultare Diagnostics Guide.

### Opzioni di Raccolta dei dati obsoleti

L'opzione -Xgcpolicy specifica la politica di raccolta dati obsoleti.

-Xgcpolicy prende i valori optthruput (valore predefinito e consigliato), optavgpause|, subpool| (solo PPC e |zSeries) oppure gencon. Questa opzione controlla il comportamento del programma di raccolta dei dati obsoleti, bilanciando la velocità effettiva dell'applicazione e del sistema in generale e le pause determinate dalla raccolta dei dati obsoleti.

Il formato dell'opzione ed i suoi valori sono:

> -Xgcpolicy:optthruput

> -Xgcpolicy:optavgpause

> -Xgcpolicy:gencon

|

> -Xgcpolicy:subpool (Solo PPC e zSeries)

### Tempo di pausa

Quando il tentativo di un'applicazione di creare un oggetto non può essere immediatamente soddisfatto a causa dello spazio disponibile nella memoria riservata, il programma di raccolta dei dati obsoleti è responsabile dell'identificazione degli oggetti cui non si fa riferimento (obsoleti), della loro cancellazione e della reimpostazione della memoria riservata su uno stato in cui le immediate e successive richieste di allocazione possono essere soddisfatte rapidamente. Questi cicli di raccolta dei dati obsoleti causano delle pause occasionali ed impreviste nell'esecuzione del codice dell'applicazione. Quando la dimensione e la complessità delle applicazioni crescono, e le memorie riservate diventano di conseguenza più grandi, questa pausa per la raccolta dei dati obsoleti tende a crescere. L'impostazione predefinita per la raccolta dei dati obsoleti, -Xgcpolicy:optthruput, consente alle applicazioni una velocità di trasmissione molto alta, tuttavia possono verificarsi delle pause occasionali, il che può variare da alcuni millisecondi a svariati secondi, in base alla dimensione della memoria e alla quantità di dati obsoleti.

### Riduzione della pausa

JVM utilizza due tecniche per ridurre i tempi di pausa:

- Raccolta dati obsoleti simultanea
- Raccolta dati obsoleti generazionale

L'opzione della riga comandi -Xgcpolicy:optavgpause richiede l'utilizzo della raccolta dati obsoleti simultanea per ridurre in modo significativo il tempo utilizzato nelle pause della raccolta dei dati obsoleti. La raccolta dati obsoleti simultanea riduce il tempo di pausa eseguendo alcune attività di raccolta dei dati obsoleti contemporaneamente all'esecuzione normale del programma per ridurre le interruzioni causate dalla raccolta della memoria riservata. L'opzione -Xgcpolicy:optavgpause limita inoltre l'effetto dell'incremento della dimensione della memoria riservata nella lunghezza della pausa della raccolta dei dati obsoleti. L'opzione -Xgcpolicy:optavgpause è molto utile per configurazioni che hanno grandi memorie riservate. Con il tempo di pausa ridotto, è possibile che si verifichi una riduzione nella capacità di elaborazione delle applicazioni.

Durante la raccolta dei dati obsoleti simultanea, viene sprecato molto tempo per identificare gli oggetti di durata relativamente lunga che non possono essere raccolti. Se la raccolta dei dati obsoleti si concentra solo su tali oggetti, che sono di solito riciclabili, è possibile ridurre ulteriormente i tempi di pausa per alcune applicazioni. La raccolta dati obsoleti generazionale ottiene questo risultato dividendo la memoria riservata in due "generazioni", le aree "asilo" e "possesso". Gli oggetti sono ubicati in una di queste aree a seconda della loro età. L'asilo è il più piccolo del due e contiene oggetti più giovani; il possesso è più grande e contiene oggetti più vecchi. Gli oggetti vengono prima assegnati all'asilo; se essi sopravvivono abbastanza a lungo, vengono eventualmente promossi nell'area di possesso.

La raccolta dati obsoleti generazionale si basa su una maggioranza di oggetti che non durano a lungo. La raccolta dati obsoleti generazionale, riduce i tempi di pausa concentrandosi sul reclamo memoria nell'asilo in quanto questa area, dispone di più spazio riciclabile. Invece di utilizzare tempi di pausa lunghi per la raccolta dell'intera memoria riservata, i dati nell'asilo vengono raccolti più spesso e, se l'asilo è sufficientemente piccolo, i tempi di pausa sono conseguentemente brevi. Il lato negativo della raccolta dati generazionale consiste nel fatto che, nel tempo, l'area di possesso potrebbe diventare piena se molti oggetti durano troppo a lungo. Per ridurre il tempo di pausa quando si verifica tale situazione, utilizzare una combinazione di raccolte dati obsoleti generazionali e simultanee. L'opzione -Xgcpolicy:gencon richiede l'uso combinato della raccolta dati simultanea e generazionale per ridurre il tempo impiegato nella pausa della raccolta dei dati obsoleti.

### Ambienti con memorie riservate molto piene

Quando una memoria riservata Java è quasi piena ed i dati obsoleti da eliminare sono pochi, è possibile che le richieste per nuovi oggetti non possano essere soddisfatte rapidamente poiché non c'è spazio immediatamente disponibile. Se la memoria riservata viene utilizzata quando è quasi piena, è possibile che le prestazioni delle applicazioni subiscano una riduzione, indipendentemente da quale delle opzioni sopra indicate viene utilizzata: e, se si continua ad inoltrare richieste per ulteriore spazio della memoria riservata, l'applicazione riceve un'eccezione OutofMemory, che determina la chiusura del JVM se l'eccezione non viene rilevata e risolta. A questo punto, JVM produce un file di diagnostici denominato "javadump". In queste situazioni, si consiglia di aumentare la dimensione della memoria riservata utilizzando l'opzione e -Xmx oppure di ridurre il numero di oggetti di applicazione in uso. Per ulteriori informazioni, consultare il manuale Diagnostics Guide.

## Modalità di elaborazione di JVM dei segnali

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

Se il segnale è per un thread Java, JVM prende il controllo della gestione del segnale. Se è installato un gestore applicazioni per questo segnale e non è stata specificata l'opzione riga comandi -Xnosigchain, quando JVM termina l'elaborazione, viene richiamato il gestore applicazioni per questo segnale.

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. In caso contrario, se il segnale viene richiesto da JVM o dall'applicazione JAVA, il segnale viene ignorato oppure viene eseguita l'azione predefinita.

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

- Gestisce la condizione ed esegue il recupero, oppure
- Immette una sequenza di chiusura controllata che:
  1. Genera un Javadump, per descrivere lo stato di JVM al momento del malfunzionamento
  2. Chiama il gestore del segnale dell'applicazione per quel segnale
  3. Chiama eventuali hook di uscita di applicazioni installate
  4. Esegue le necessarie pulizie per una chiusura pulita

Per informazioni su come scrivere un programma di avvio che specifica gli hook sopra indicati, consultare: http://www-106.ibm.com/developerworks/java/library/i-signalhandling/. Questo elemento è stato scritto per Java V1.3.1 ma è valido anche per le versioni successive.

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

- Chiama il gestore del segnale dell'applicazione per quel segnale
- Esegue tutti gli hook di chiusura delle applicazioni
- Chiama eventuali hook di uscita di applicazioni installate
- Esegue le necessarie pulizie JVM

La chiusura è identica a quella iniziata da una chiamata al metodo Java `System.exit()`.

Altri segnali usati da JVM servono per controlli interni e non causano la chiusura. L'unico segnale di controllo di interesse è SIGQUIT, che genera un Javadump.

### Segnali usati da JVM

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

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

Tabella 1. Segnali usati da JVM
Nome segnale | Tipo segnale | Descrizione | Disabilitato da -Xrs
--- | --- | --- | ---
SIGBUS | Eccezione | Accesso errato alla memoria (allineamento errato di dati ) | Sì
SIGSEGV | Eccezione | Accesso alla memoria non corretto (scrittura su memoria non accessibile) | Sì
SIGILL | Eccezione | Istruzione non valida (tentativo di richiamare istruzione macchina sconosciuta) | No
SIGFPE | Eccezione | Eccezione virgola mobile (dividere per zero) | Sì
SIGABRT | Errore | Fine anomala. JVM emette questo segnale quando rileva un problema JVM. | Sì
SIGINT | Interrotto | Attenzione interattiva (CTRL-C). JVM esce normalmente. | Sì
SIGTERM | Interrotto | Richiesta termine. JVM uscirà normalmente. | Sì
SIGHUP | Interrotto | Disconnessione. JVM esce normalmente. | Sì
SIGQUIT | Controllo | Un segnale di uscita per un terminale. JVM lo utilizza per effettuare i Javadump. | Sì
|SIGTRAP (5) | |Controllo | |Utilizzato da JIT. | |Sì
|__SIGRTMAX - 2 | |Controllo | |Utilizzato da SDK. | |No
|SIGCHLD | |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, consultare la pagina di avvio dell'applicazione Java della Sun all'indirizzo http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.

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 di segnale a catena

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

La funzione di 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 che chiamate quali `signal()`, `sigset()` e `sigaction()` vengano intercettate così che i loro gestori non sostituiscano i gestori di 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.

Per utilizzare libjsig.so:

- Eseguire il collegamento all'applicazione che crea oppure inserisce una JVM:

      5gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm java_application.c

  oppure
- Utilizzare la variabile di ambiente LD_PRELOAD:

      export LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (bash e ksh)

      setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; java_application (csh)

  (Presumendo che `JAVA_HOME` sia impostato; altrimenti, utilizzare /opt/ibm/java2-i386-50/jre.)

Se si installano gestori di segnale che utilizzano `sigaction()` , alcuni indicatori sa_flags non vengono rispettati quando la JVM utilizza il segnale. Tali indicatori sono:

- SA_NOCLDSTOP - Sempre non impostato.
- SA_NOCLDWAIT - Sempre non impostato.
- SA_RESTART - Sempre impostato.

La libreria libjsig.so nasconde anche i gestori segnali 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.

## Gestione degli stack mobili

Alcune distribuzioni Linux, come, ad esempio, Red Hat, hanno abilitato una funzione GLIBC detta 'a stack mobili'. A causa di limitazioni del kernel Linux, JVM non viene eseguito su hardware SMP con gli stack mobili abilitati se il livello del kernel è inferiore a 2.4.10. In questo ambiente, gli stack mobili devono essere disabilitati prima di avviare JVM o qualsiasi applicazione che determina l'avvio di JVM. Su Red Hat, è possibile disabilitare gli stack mobili esportando una variabile di ambiente:

    export LD_ASSUME_KERNEL=2.2.5

Su un sistema Linux a stack non mobili, indipendentemente da quanto impostato per -Xss, viene fornita una dimensione di stack nativo minima di 256 KB. Su un sistema Linux a stack mobili, i valori specificati per -Xss vengono applicati. Pertanto, se si sta eseguendo una migrazione da un sistema Linux con stack non mobili, è necessario verificare che tutti i valori -Xss specifichino delle dimensioni sufficienti e non dipendano dal valore minimo di 256 KB.

## Trasformazione di documenti XML

L'IBM SDK contiene il processore XSLT4J e il parser XML4J che sono conformi alla specifica JAXP 1.3. Tali strumenti consentono di analizzare e trasformare documenti XML indipendentemente da qualsiasi implementazione di elaborazione XML fornita. Utilizzando "Factory Finders" per individuare le implementazioni SAXParserFactory, DocumentBuilderFactory e TransformerFactory, l'applicazione può passare tra differenti implementazioni senza dover cambiare alcun codice.

|La tecnologia XML inclusa con IBM SDK è simile a |Apache Xerces Java e Apache Xalan Java. Per ulteriori informazioni, visitare i siti http://xml.apache.org/xerces2-j/ ehttp://xml.apache.org/xalan-j/.

Il processore XSLT4J consente di scegliere tra il processore XSLT Interpretive originale oppure e il nuovo processore XSLT Compiling. Il processore Interpretive è progettato per ambienti di debug e supporto e supporta le funzioni di estensione XSLT che non sono supportate dal processore XSLT Compiling. Il processore XSLT Compiling viene progettato per ambienti di esecuzione ad alte prestazioni; genera un motore di trasformazione oppure translet, da un foglio di stile. Questo approccio separa l'interpretazione delle istruzioni dei fogli di stile dalla relativa applicazione di runtime a dati XML.

Il processore XSLT Interpretive è quello predefinito. Per selezionare il processore XSLT Compiling è possibile:

- Modificare l'entrata nel file jaxp.properties (localizzato nella /opt/ibm/java2-i386-50/jre/lib), oppure
- Impostare la proprietà di sistema per la chiave javax.xml.transform.TransformerFactory su org.apache.xalan.xsltc.trax.TransformerFactoryImpl.

Per implementare le proprietà nel file jaxp.properties, copiare jaxp.properties.sample in jaxp.properties nella /opt/ibm/java2-i386-50/. Questo file contiene anche dettagli completi sulla procedura utilizzata per determinare quali implementazioni utilizzare per TransformerFactory, SAXParserFactory e DocumentBuilderFactory.

Per migliorare le prestazioni quando si trasforma un oggetto StreamSource con il processore XSLT Compiling, specificare la classe com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager come provider del servizio org.apache.xalan.xsltc.dom.XSLTCDTMManager. Per determinare il service provider, provare ogni operazioni finché non si individua org.apache.xalan.xsltc.dom.XSLTCDTMManager:

1. Verificare l'impostazione della proprietà di sistema org.apache.xalan.xsltc.dom.XSLTCDTMManager.
2. Verificare il valore della proprietà org.apache.xalan.xsltc.dom.XSLTCDTMManager nel file /opt/ibm/java2-i386-50/lib/xalan.properties.
3. verificare il contenuto del file META-INF/services/org.apache.xalan.xsltc.dom.XSLTCDTMManager per un nome della classe.
4. Utilizzare il service provider predefinito, org.apache.xalan.xsltc.dom.XSLTCDTMManager.

Il processore XSLT Compiling rileva il service provider per il servizio org.apache.xalan.xsltc.dom.XSLTCDTMManager quando viene creato un oggetto javax.xml.transform.TransformerFactory. Qualsiasi oggetto javax.xml.transform.Transformer oppure javax.xml.transform.sax.TransformerHandler creato utilizzando l'oggetto TransformerFactory, utilizzerà lo stesso service provider. È possibile modificare i service provider modificando una delle impostazioni descritte e quindi creando un nuovo oggetto TransformerFactory.

### Utilizzo di una versione precedente di Xerces o Xalan

Se si sta usando una versione meno recente di Tomcat, potrebbe applicarsi questa limitazione.

Se si sta usando una versione più vecchia di Xerces (antecedente a 2.0) o Xalan (antecedente a 2.3), si potrebbe ricevere un'eccezione di puntatore nullo quando si lancia l'applicazione. Questa eccezione si verifica perché le versioni più vecchie non gestiscono correttamente il file jaxp.properties.

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

- Aggiornare ad una versione più recente dell'applicazione in modo da implementare la specifica più recente di Java API per XML Programming (JAXP) (http://java.sun.com/xml/jaxp/index.html).
- Eliminare il file jaxp.properties da /opt/ibm/java2-i386-50/jre/lib.
- Eliminare il commento alle voci del file jaxp.properties in /opt/ibm/java2-i386-50/jre/lib.
- Impostare esplicitamente SAX Parser, DocumentBuilder o Transformer factory usando la variabile di ambiente IBM_JAVA_OPTIONS. Ad esempio:

      export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
        org.apache.xerces.jaxp.SAXParserFactoryImpl

  oppure

      export IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
        org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

  oppure

      export IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
        org.apache.xalan.processor.TransformerFactoryImpl

- Impostare la proprietà di sistema per javax.xml.parsers.SAXParserFactory, javax.xml.parsers.DocumentBuilderFactory o javax.xml.transform.TransformerFactory dall'interno del codice dell'applicazione. Per un esempio, consultare le specifiche JAXP 1.3.

# Utilizzo di SDK per lo sviluppo di applicazioni Java

Le seguenti sezioni forniscono informazioni sull'utilizzo di SDK per Linux per sviluppare applicazioni Java. Consultare Tool SDK per informazioni dettagliate sugli strumenti disponibili.

## Esecuzione del debug nelle applicazioni Java

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

### Java Debugger (JDB)

JDB (Java Debugger) è incluso nel SDK per Linux. Il programma di debug è richiamato dal comando jdb; questo si "collega" a JVM che usa usando 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=<porta>
            MyApp <arg MyApp>

2. JVM si avvia ma sospende l'esecuzione prima di avviare l'applicazione Java . In una sessione separata, è possibile collegare il programma di debug a JVM:

       jdb -attach <numero porta>

   Il programma di debug si collega a JVM ed è ora possibile emettere una gamma di comandi per esaminare e controllare le applicazioni Java; ad esempio, immettere `run` per consentire l'esecuzione di applicazioni Java.

Per ulteriori informazioni sulle opzioni JDB, immettere:

    jdb -help

Per ulteriori informazioni sui comandi JDB:

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

È inoltre possibile usare JDB per effettuare il debug delle applicazioni Java eseguite su macchine remote:

1. Avviare JVM come precedentemente indicato.
2. Collegare il programma di debug alla macchina in remoto:

       jdb -attach <nome macchina o indirizzo ip>:<numero porta>

Quando si lancia una sessione di debug usando il trasporto dt_socket, accertarsi che le porte specificate siano libere.

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

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

- http://java.sun.com/products/jpda/
- http://java.sun.com/j2se/1.5.0/docs/guide/jpda/
- http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdb.html

## Come stabilire se l'applicazione esegue una JVM a 32 o 64 bit

Con alcune applicazioni Java deve essere possibile determinare se viene eseguita una JVM a 32 o 64 bit. Ad esempio,se l'applicazione dispone di una libreria di codice nativo, tale libreria deve essere compilata separatamente in moduli a 32 e 64 bit per le piattaforme che supportano entrambe le modalità di funzionamento (a 32 e 64 bit). In questo caso, l'applicazione deve caricare la libreria corretta al runtime, perché non è possibile mischiare il codice a 32 bit con quello a 64 bit.

La proprietà di sistema com.ibm.vm.bitmode consente alle applicazioni di determinare il modo in cui è in esecuzione il JVM di cui si dispone. Vengono restituiti i seguenti valori:

- 32 - la JVM è in esecuzione in modalità a 32bit
- 64 - JVM è in esecuzione nel modo a 64 bit

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

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

## Scrittura di applicazioni JNI

I numeri di versione JNI validi che i programmi nativi possono specificare sulla chiamata JNI_CreateJavaVM() API sono:

- JNI_VERSION_1_2(0x00010002)
- JNI_VERSION_1_4(0x00010004)

Questo numero di versione determina solo il livello dell'interfaccia nativa JNI da utilizzare. Il livello attuale di JVM creato viene specificato dalle librerie J2SE (cioé v5.0). 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, visitare il sito http://java.sun.com/j2se/1.5.0/docs/guide/jni.

Se per l'applicazione occorrono due librerie JNI, una creata per 31-bit e una per 64 -bit, utilizzare la proprietà di sistema com.ibm.vm.bitmode per determinare se si sta eseguendo con un JVM a 31 oppure a 64 bit e selezionare la libreria appropriata.

Per compilare e collegare un'applicazione nativa con SDK 5.0 IBM, utilizzare il seguente comando:

    gcc -I/opt/ibm/java2-i386-50/include -L/opt/ibm/java2-i386-50/jre/bin/j9vm
    -ljvm -ldl -lpthread <nomefile programma JNI>

L'opzione -ljvm specifica che libjvm.so sia la libreria condivisa che implementa 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.

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

## Supporto per il recupero di livello-thread dei connettori bloccati

|

Sono state aggiunte quattro nuove classi IBM specifiche per SDK al pacchetto com.ibm.jvm per supportare il |recupero a livello di thread dei connettori bloccati. Le nuove classi sono impacchettate in core.jar.

|

Queste nuove classi consentono di sbloccare i thread che si sono bloccati nella rete |o nelle chiamate di sincronizzazione. Se l'applicazione non usa queste classi, deve terminare l'intero processo piuttosto |che interrompere un thread individuale bloccato.

|

Le classi sono:

|

|
Interfaccia pubblica InterruptibleContext()
|
  Definisce due metodi, isblocked() e unblock(). Le altre tre classi implementano InterruptibleContext. |
|
Classe pubblica InterruptibleLockContext()
|
  Classe di utilità per interrompere le chiamate di sincronizzazione. |
|
Classe pubblica InterruptibleIOContext()
|
  Classe di utilità per interrompere le chiamate di rete. |
|
Classe pubblica InterruptibleThread()
|
  Classe di utilità che estende java.lang.Thread, per consentire il riciclo dei metodi eseguibili che si possono |interrompere. Usa istanze di InterruptibleLockContext |e InterruptibleIOContext per eseguire i metodi isblocked() e unblock() |a seconda che l'operazione di sincronizzazione o di rete stia bloccando il thread. |
|

|

Entrambi InterruptibleLockContext e InterruptibleIOContext funzionano facendo riferimento al |thread corrente. Pertanto se non si usa InterruptibleThread, bisogna fornire la propria classe che estende |java.lang.Thread per usare queste nuove classi.

|

Il Javadoc per questa classi è fornito con il SDK nel file docs/apidoc.zip.

## Operazioni con gli applet

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

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

### Esecuzione delle applet con Applet Viewer

Per eseguire un'applet con il suo visualizzatore, immettere in una shell di richiesta :

       appletviewer name

dove name è uno dei seguenti:

- Il nome di un file HTML che chiama un'applet
- L'URL di una pagina Web che richiama un'applet

Ad esempi, per richiamare un'Applet Viewer su un file HTML che chiama un'applet, immettere su una shell di richiesta comandi :

      appletviewer $HOME/filename.html

dove filename è il nome del file HTML.

Ad esempio, `http://java.sun.com/applets/NervousText/example1.html` è l'URL della pagina Web che richiama l'applet. Per richiamare Applet Viewer su questa pagina web, immettere su una shell di comandi:

    appletviewer http://java.sun.com/applets/NervousText/example1.html

L'Applet Viewer non riconosce l'opzione charset della tag <META>. Se il file caricato da appletviewer non è codificato come predefinito del sistema, potrebbe verificarsi un'eccezione I/O. Per evitarla, usare l'opzione -encoding quando si esegue appletviewer. Ad esempio:

    appletviewer -encoding JISAutoDetect sample.html

### Esecuzione del debug delle applet con Applet Viewer

Si può eseguire il debug delle applet usando l'opzione -debug di Applet Viewer. Quando si esegue il debug delle applet, viene consigliato di richiamare Applet Viewer dalla directory che contiene il file HTML che chiama l'applet. 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 della Sun: http://java.sun.com.

| | |

## Configurazione dell'allocazione di memoria di pagine grandi

|

È possibile abilitare il supporto a pagine grandi, su sistemi che lo supportano, avviando Java con l'opzione -Xlp.

|

L'utilizzo di pagine grandi serve principalmente a fornire dei miglioramenti delle prestazioni alle applicazioni che allocano molta memoria e che accedono ad essa frequentemente. |I miglioramenti delle prestazioni delle pagine grandi 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 grandi deve essere disponibile nel kernel e abilitato, per consentire l'utilizzo di queste pagine grandi da parte di Java.

|

Per configurare l'allocazione di memoria di pagine grandi, accertarsi prima che il kernel in esecuzione supporti le pagine grandi. Controllare che il file /proc/meminfo contenga le seguenti righe:

|

    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 il supporto di pagine grandi non è disponibile 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. Configurare il numero di pagine grandi all'avvio affinché siano contigue.

|

Le allocazioni di pagine grandi avrà esito positivo se JVM ha le autorizzazioni di accesso di root. Per utilizzare pagine grandi, eseguire Java come root oppure impostare il bit di suid dell'eseguibile Java.

## Supporto CORBA

Java 2 Platform, Standard Edition (J2SE) supporta, almeno, le specifiche definite nelle Official Specifications for CORBA support in J2SE (V1.5). In alcuni casi, IBM J2SE ORB supporta le versioni più recenti delle specifiche.

### Supporto per GIOP 1.2

Questo SDK supporta tutte le versioni di GIOP, come definito nei capitoli 13 e 15 delle specifiche CORBA 2.3.1, documento OMG formal/99-10-07, recuperabile su:

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

GIOP bidirezionale non è supportato.

### Supporto per Portable Interceptors

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

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

Portable Interceptors sono ganci posti in ORB attraverso cui i servizi ORB possono intercettare il normale flusso esecutivo di ORB.

### Supporto per Interoperable Naming Service

SDK supporta Interoperable Naming Service, come definito da OMG nel documento ptc/00-08-07, che è possibile ottenere da:

http://www.omg.org/cgi-bin/doc?ptc/00-08-07

La porta predefinita usata da Transient Name Server (il comando `tnameserv`), quando non viene dato il parametro ORBInitialPort, cambia da 900 a 2809, che è il numero della porta registrata con IANA (Internet Assigned Number Authority) per il servizio di assegnazione nomi CORBA. I programmi dipendenti da questo valori predefiniti, per lavorare con questa versione, potrebbero aver bisogno di essere aggiornati.

Il contesto iniziale che viene restituito dal Transient Name Server è ora un `org.omg.CosNaming.NamingContextExt`. I programmi esistenti che riducono il riferimento ad un contesto `org.omg.CosNaming.NamingContext` funzionano comunque e non hanno bisogno di essere ricompilati.

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

OMG specifica un metodo ORB::register_initial_reference per registrare un servizio con Interoperable Naming Service. Tuttavia, questo metodo non è disponibile in Sun Java Core API alla Versione 5.0. I programmi che hanno bisogno di registrare un servizio nella versione corrente devono richiamare questo metodo nella classe di implementazione ORB interna IBM. Ad esempio, per registrare un servizio "MyService":

    ((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MyService",
    serviceRef);

dove `orb` è un'istanza di `org.omg.CORBA.ORB`, che viene restituita da `ORB.init()`, e `serviceRef` e un Oggetto ORBA, che è connesso a ORB. Questo meccanismo è temporaneo e non è compatibile con le future versioni o portatili ORB non-IBM.

### Proprietà di sistema per tracciare l'ORB

Una funzione di debug al momento dell'esecuzione fornisce funzionalità potenziate. Potrebbe risultare utile per la diagnosi dei problemi o potrebbe essere richiesta dal personale di assistenza IBM. La funzione di traccia è controllata da tre proprietà di sistema.

- Per attivare la funzione di traccia, impostare `com.ibm.CORBA.Debug=true` .
- Per formattare ed aggiungere alla traccia GIOP i messaggi inviati e ricevuti, impostare `com.ibm.CORBA.CommTrace=true`. Come valore predefinito, la traccia ORB si indirizza sui file che hanno nomi del formato orbtrc.DDMMYYYY.HHmm.SS.txt.
- Per inviarlo ad un file differente, impostare `com.ibm.CORBA.Debug.Output=<nomefile>`.

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

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

Non attivare la traccia per le normali operazioni in quanto ciò potrebbe comportare un peggioramento delle prestazioni. Anche se la traccia è stata disattivata, FFDC (First Failure Data Capture) funziona comunque, per cui vengono riportati solo gli errori gravi. se viene generato un file di output del debug, esaminarlo per verificare il problema. Ad esempio, il server potrebbe essersi interrotto senza eseguire un ORB.shutdown().

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

### Proprietà di sistema per ottimizzare ORB

Le seguenti proprietà agevolano l'ottimizzazione di ORB:

- Per controllare la frammentazione GIOP 1.2, impostare la proprietà di sistema com.ibm.CORBA.FragmentSize.

  Ad esempio, per impostare la dimensione del frammento su 4096 byte:

      java -Dcom.ibm.CORBA.FragmentSize=4096 myapp

  La dimensione predefinita del frammento è 1024 byte. E possibile disattivare la frammentazione impostando la dimensione del frammento su 0.

- In una rete eterogenea, la risposta ad una richiesta CORBA potrebbe essere ritardata o persa. E' possibile impostare il tempo massimo di attesa usando la proprietà di sistema com.ibm.CORBA.RequestTimeout. Inoltre, è possibile usare com.ibm.CORBA.LocateRequestTimeout per controllare il timeout perLocateRequests. Ad esempio, per ridurre entrambi i ritardi a 30 secondi, immettere:

      java -Dcom.ibm.CORBA.RequestTimeout=30
           -Dcom.ibm.CORBA.LocateRequestTimeout=30 myapp

  Come impostazione predefinita, ORB attende una risposta indefinitamente. Non impostare il timeout su un valore troppo basso, altrimenti le connessioni potrebbero terminare inutilmente.

- Se il programma sta fornendo un servizio in una rete, potrebbe essere necessario salvare su un valore ben noto il numero della porta da cui ORB legge le richieste in entrata. E' possibile controllare ciò tramite la proprietà di sistema com.ibm.CORBA.ListenerPort.

  Ad esempio, per far in modo che ORB usi la porta 1050, immettere:

      java -Dcom.ibm.CORBA.ListenerPort=1050 myapp

  Se viene impostata questa proprietà, ORB si mette in ascolto appena viene inizializzato. Altrimenti, inizia solo quando viene richiesto.

### Autorizzazioni di sicurezza Java 2 per ORB

Quando si utilizza Java 2 SecurityManager, il richiamo di alcuni metodi nelle classi API di CORBA potrebbe comportare l'esecuzione di controlli sulle autorizzazioni, il che potrebbe comportare una SecurityException. I metodi interessati comprendono quanto segue:

Tabella 2. Metodi interessati durante l'utilizzo di Java 2 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, booleano) | 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

Se i programmi di cui si dispone usano alcuni di questi metodi, assicurarsi che siano garantite le autorizzazioni necessarie.

### Classi di implementazione ORB

Le classi di implementazione ORB in questo rilascio sono:

- org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
- org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton
- javax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.UtilDelegateImpl
- javax.rmi.CORBA.StubClass=com.ibm.rmi.javax.rmi.CORBA.StubDelegateImpl
- javax.rmi.CORBA.PortableRemoteObjectClass= com.ibm.rmi.javax.rmi.PortableRemoteObject

Questi sono i valori predefiniti, e viene posta all'attenzione l'avvertenza di non impostare queste proprietà o di fare riferimento direttamente alle classi di implementazione. Per la portabilità, fare riferimento alle classi API di CORBA API e non all'implementazione. Questi valori potrebbero essere modificati nei prossimi rilasci.

## RMI su IIOP

RMI (Remote Method Invocation) Java fornisce un semplice meccanismo per effettuare programmazione distribuita Java. RMI su IIOP (RMI-IIOP) utilizza il protocollo IIOP (Internet Inter-ORB Protocol) standard dell'archietttura CORBA (Common Object Request Broker Architecture) per estendere RMI Java di base ed effettuare comunicazioni. In tal modo, si consente la diretta interazione con qualsiasi altro ORB (CORBA Object Request Brokers), sia che sia implementato in Java che in qualsiasi altro linguaggio.

È disponibile la seguente documentazione:

- Il manuale RMI-IIOP Programmer's Guide è un'introduzione alla scrittura di programmi RMI-IIOP. La guida viene installata quando si installa la documentazione.
- La directory demo contiene:
  - Un esempio "Hello World" che consente di passare dal protocollo JRMP (Java Remote Method Protocol ) al protocollo IIOP (demo/rmi-iiop/hello)
  - Un esempio "Hello World" che interagisce con un programma IDL standard (demo/rmi-iiop/idl)
- Il documento Java Language to IDL Mapping è una specifica tecnica dettagliata di RMI-IIOP ed è reperibile presso il seguente sito:
  http://www.omg.org/cgi-bin/doc?ptc/00-01-06.pdf

## 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 del trasporto TCP RMI, impostare l'opzione

    -Dsun.rmi.transport.tcp.connectionPool=true (o un qualsiasi valore non nullo)

Questa versione di Runtime Environment non ha alcuna impostazione che è possibile utilizzare per limitare il numero di thread nel pool delle connessioni.

Per ulteriori informazioni, consultare il sito Java della Sun: http://java.sun.com.

## Supporto bidirezionale avanzato

IBM SDK comprende il supporto bidirezionale avanzato. Per ulteriori informazioni, consultare http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html . Il Javadoc per questo pacchetto bidirezionale è fornito con il SDK nel file docs/apidoc.zip.

## BigDecimal migliorato

| |

Da Java 5.0, la classe BigDecimal IBM è stata adottata dalla Sun come java.math.BigDecimal. | IBM non effettua più manutenzione su com.ibm.math.BigDecimal ed è contrassegnato come sconsigliato. | Si raccomanda di migrare il codice Java esistente in modo che usi java.math.BigDecimal.

|

Il nuovo java.math.BigDecimal usa gli stessi metodi di entrambe le precedenti |java.math.BigDecimal e com.ibm.math.BigDecimal. Il codice esistente che usa java.math.BigDecimal |continua a funzionare correttamente.

|

Per migrare il codice Java esistente in modo che usi la classe java.math.BigDecimal, cambiare l'istruzione di importazione |in cima al file java da: `import com.ibm.math.*;` in `import java.math,*;`.

## Supporto del simbolo dell'Euro

IBM SDK e Runtime Environment impostano l'Euro come valuta predefinita per quelle nazioni dell'EMU (European Monetary Union) per le date a partire dal 1 gennaio, 2002.

Per usare la valuta nazionale, specificare `-Duser.variant=PREEURO` sulla riga comandi Java.

Se si sta usando la locale UK, Danese o Svedese e si vuole usare l'Euro, specificare `-Duser.variant=EURO` sulla riga comandi Java.

# Uso di Java Communications API (JavaComm)

L'interfaccia delle applicazioni di programmazione (API) di Java Communications (JavaComm) è un pacchetto facoltativo fornito per essere usato con Runtime Environment per Linux su piattaforme IA32, PPC32/PPC64 e AMD64/EM64T . JavaComm viene installato indipendentemente da SDK o da Runtime Environment.

L'API di JavaComm fornisce alle applicazioni Java un modo indipendente dalla piattaforma per eseguire comunicazioni tra porte seriali e parallele per tecnologie come voice mail, fax e smartcard. Dopo aver scritto comunicazioni per porte seriali o parallele per le applicazioni, è possibile includere quei file nelle proprie applicazioni.

L'API di Java Communications supporta le porte seriali di Electronic Industries Association (EIA)-232 (RS232) e le porte parallele dell'Institute of Electrical and Electronics Engineers (IEEE) 1284 ed è supportata su sistemi con IBM Versione 5.0 Runtime Environment.

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

- Elencare le porte su un sistema
- Aprire ed esigere la proprietà delle porte
- Risolvere il problema della proprietà della porta tra applicazioni che usano l'API di Java Communications.
- Eseguire controlli sincroni e asincroni su porte I/O attraverso la notifica degli eventi.
- Ricevere eventi in stile bean ce descrivono i cambi di stato della porta.

## Installazione delle API di Java Communications

Accertarsi che una copia di SDK o di Runtime Environment venga installata prima di installare l'API di Java Communications.

Se è stato usato il pacchetto RPM per installare originariamente Java, installare l'API di Java Communications dal file RPM. Per installare l'API di Java Communications da un pacchetto RPMe:

1. Aprire una richiesta di shell, accertandosi che ci si trovi nella root.
2. Usare il comando `rpm -ivh`, installare il file Java Communications API RPM. Ad esempio:

       rpm -ivh ibm-java2-<arch>-javacomm-5.0-0.0.<arch>.rpm

   L'API di Java Communications è installata all'interno della struttura dele directory /opt/ibm/java2-i386-50/ .

Per installare l'API di Java Communications da un file zip .tgz file:

1. Inserire il file di archivio di Java Communications API, ibm-java2-javacomm-50-linux-<arch>.tgz, nella directory che contiene la directory IBMJava2-50.
2. Da un prompt della shell, nella directory contenente il file .tgz, estrarre i contenuti:

       tar -xvzf ibm-java2-javacomm-50-linux-<arch>.tgz

   Java Communications API viene estratto nelle relative sottodirectory all'interno della directory IBMJava2-50 esistente.

## Posizione dei file API di Java Communications

I file API di Java Communications vengono installai nel seguente modo:

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

Se l'installazione è stata eseguita nella directory predefinita, il file comm.jar si trova nella /opt/ibm/java2-i386-50/jre/lib/ext.

Se il pacchetto è stato installato in un'altra directory, i file si trovano nella stessa struttura di directory, ma /opt/ibm/java2-i386-50/ viene sostituita dalla directory in cui era stato installato Java Communications API.

## Configurazione di Java Communications API

Dopo aver installato Java Communications API, bisogna:

- Cambiare la modalità di accesso delle porte seriali e parallele.
- Impostare il PATH, se l'impostazione non è stata effettuata durante l'installazione di Java. Consultare Impostazione di PATH.

### Cambio della modalità di accesso delle porte seriali e parallele

Dopo aver installato Java Communications API, bisogna cambiare il modo di accesso delle porte seriali e parallele in modo che gli utenti possano accedere a tali dispositivi. Bisogna fornire un accesso in lettura/scrittura ai dispositivi richiesti. Collegarsi come root ed usare i seguenti comandi, dove applicabili:

        chmod 666 /dev/ttyS0    (conosciuto anche come porta seriale COM1)
        chmod 666 /dev/lp0      (conosciuto anche come porta parallela LPT1)
        chmod 666 /dev/ttyS1    (conosciuto anche come porta seriale COM2)
        chmod 666 /dev/ttyS2    (conosciuto anche come porta seriale COM3)
        chmod 666 /dev/ttyS3    (conosciuto anche come porta seriale COM4)

Questi comandi danno accesso in lettura/scrittura a chiunque sul sistema.

Un metodo alternativo consiste nel fare i 660 permessi ed aggiungere gli utenti specifici al gruppo nel quale risiedono i dispositivi. 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 resi disponibili da Java Communications API e di indicare 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 esistono i dispositivi `/dev/ttyS0` e `/dev/ttyS1`, questi verranno allocati rispettivamente come COM1 e COM2.

Per usare i connettori USB-serial, 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. Al momento, non c'è modo di abilitare le porte con Linux (il pacchetto tpctl non abilita le porte se queste sono disabilitate nel BIOS).

Per abilitare le porte nel BIOS, bisogna usare la versione DOS di ThinkPad Configuration Utility che è disponibile sul sito IBM ThinkPad Download. Per usare ThinkPad Configuration Utility, è necessario un dischetto DOS riavviabile. Notare che il programma di utilità di configurazione del ThinkPad potrebbe essere stato installato come parte delle ThinkPad Utilities sotto Windows, in base alle opzioni di installazione, ed è possibile eseguirlo dalla riga comandi di Windows.

L'applicazione del ThinkPad Configuration fornito 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 usa questa applicazione con Windows, le porte sono disponibili; tuttavia, riavviando la macchina con Linux, le porte non saranno abilitate.

## Limitazioni di stampa con Java Communications API

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

## Disinstallazione di Java Communications API

Il processo usato per disinstallare Java Communications API dipende da se è stato installato il pacchetto dell'installabile Red Hat Package Manager (RPM) o il pacchetto compresso di Tape Archive (TAR).

### Disinstallazione del pacchetto RMP (Red Hat Package Manager) installabile

Per disinstallare Java Communications API se è stato installato il pacchetto installabile di RPM:

1. In una richiesta shell, immettere:

           rpm -e ibm-java2-<arch>-javacomm-5.0-0.0

   In alternativa, possibile utilizzare uno strumento grafico, come kpackage oppure yast2.

2. Se la directory in cui è stato installato Java Communications API non contiene altri tool di cui si ha bisogno, eliminare la directory dall'istruzione PATH.

### Disinstallazione del pacchetto TAR (Tape Archive) compresso

Per disinstallare Java Communications API, se è stato installato il pacchetto compresso TAR, cancellare i seguenti file dalla directory in cui sono stati installati.

- jre/lib/ext/comm.jar
- jre/bin/libibmcomm.so
- jre/lib/javax.comm.properties

## Documentazione di Java Communications API

E' possibile trovare trovare la documentazione API ed esempi di Java Communications API sul sito web della Sun: http://java.sun.com.

# Sviluppo di applicazioni Java

## (Solo Linux IA a 32 bit e PPC32) Utilizzo del plug-in di Java

Il plug-in Java è un plug-in del browser Web. Se si utilizza il plug-in Java, è possibile ignorare il JVM predefinito del browser Web e utilizzare il Runtime Environment desiderato per eseguire gli applet o i bean nel browser.

Occorre consentire gli applet per terminare il caricamento in modo da 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.

La documentazione sul plug-in Java è resa disponibile dalla Sun presso il seguente sito: http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.

### Browser supportati

|Per Linux PPC32, Mozilla 1.6 è il |browser supportato.

|Per Linux IA32, consultare Tabella 3.

|Tabella 3. Browser supportati dal plug-in Java su Linux IA32
|Distribuzione | |Versione predefinita di Netscape | |Versioni supportate di Netscape | |Versione predefinita di Mozilla | |Versioni supportate di Mozilla
--- | --- | --- | --- | ---
|Red Hat Enterprise Linux 3.0 | |- | |7.x | |1.4.2 | |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x
|Red Hat Enterprise Linux 4.0 | |4.8 | |7.x | |1.7.3 | |1.4.1, 1.4.2, 1.7.8, Firefox 1.0.x
|SUSE Linux Enterprise Server 9.0 | |- | |7.x | |1.6 | |1.4.1, 1.4.2, 1.6, 1.7.8, Firefox 1.0.x

|

### Installazione e configurazione del plug-in Java

|Più versioni del Plug-in Java sono fornite con il |SDK. Scegliere la versione corretta per il browser utilizzato. Le più comuni sono:

| |
libjavaplugin_oji.so
|
  Il Plug-in più comune. Si basa sull'iniziativa di Mozilla Open JVM Integration e viene utilizzato con la maggior parte dei prodotti Mozilla e derivati, incluso Firefox. |
|
libjavaplugin_ojigtk2.so
|
  Lo stesso Plug-in ma compilato con il toolkit GTK2. |

|Di seguito vengono fornite istruzioni sull'installazione del Plug-in su alcuni browser comuni.

|È necessario collegre simbolicamente il Plug-in, anziché copiarlo, per consentirgli di individuare la JVM.

#### Mozilla

|È supportato solo Mozilla 1.4 e versioni successive.

Per rendere il plug-in Java disponibile a tutti gli utenti:

1. Collegarsi come root.
2. Cambiare la directory dei Plug-in di Mozilla (potrebbe essere diversa su alcune distribuzioni Linux).

       cd /usr/local/mozilla/plugins/

3. |Creare un collegamento simbolico a libjavaplugin_oji.so. |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

È necessario collegre simbolicamente il Plug-in, anziché copiarlo, per consentirgli di individuare la JVM.

| | |

#### Firefox

|

Per rendere il plug-in Java disponibile a tutti gli utenti:

|

|
1. Collegarsi come root.
|
2. Cambiare la directory dei Plug-in di Firefox (potrebbe essere diversa su alcune distribuzioni Linux). | |

       cd /usr/local/mozilla-firefox/plugins/

|
3. |Creare un collegamento simbolico a libjavaplugin_oji.so. |

       ln -s /opt/ibm/java2-i386-50/jre/bin/libjavaplugin_oji.so .

   |

È necessario collegre simbolicamente il Plug-in, anziché copiarlo, per consentirgli di individuare la JVM.

#### Netscape 7.1 e versioni successive

Per installare e configurare Java Plug-in per Netscape, fare un collegamento simbolico dal file della libreria /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so nella directory dei Plug-in del browser (/percorso-installazione-browser/plugins).

1. Collegarsi come root.
2. Cambiare la directory dei Plug-in di Netscape (potrebbe essere diversa su alcune distribuzioni Linux).

       cd /usr/local/netscape/plugins/

3. Collocare un collegamento simbolico a javaplugin_oji.so nella directory Plug-in.

       ln -s /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so .

È necessario collegare simbolicamente il Plug-in, anziché copiarlo, per consentirgli di individuare la JVM.

### Supporto DOM (Document Object Model) comune

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

- sun.plugin.dom.exception.NotSupportedException ricevuto per alcune di queste funzioni.
- sun.plugin.dom.exception.InvalidStateException ricevuto quando il browser non supporta una funzione particolare.

### Utilizzo dei parametri DBCS

Il plug-in Java supporta i caratteri a doppio byte (ad esempio il Cinese tradizionale BIG-5, il Coreano e il Giapponese) come parametri per le tag `<APPLET>`,`<OBJECT>` e `<EMBED>`. E' necessario selezionare la codifica caratteri corretta per il documento HTML in modo che il plug-in Java possa analizzare il parametro. Specificare la codifica dei caratteri per il documento HTML utilizzando il 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. Tutti i parametri vengono passati al plug-in Java in modo corretto. Tuttavia, alcune versioni meno recenti dei browser potrebbero non interpretare il tag correttamente. In questo caso, è possibile forzare il browser in modo da ignorare questo tag, ma potrebbe essere necessario modificare manualmente la codifica.

E' possibile specificare quale codifica utilizzare per l'analisi del file HTML:

- Netscape 4: Menu Visualizza -> Serie di caratteri
- Mozilla: Menu Visualizza -> Codifica d caratteri

## (solo Linux IA 32-bit, PPC32 e PPC64) Utilizzo di Web Start

E' possibile usare Java Web Start per distribuire le applicazioni Java. Web Start consente agli utenti di lanciare e di gestire le applicazioni direttamente dal Web. L'uso di Java Web Start consente di avviare facilmente le applicazioni dal Web, assicurandosi che si sta usando la versione più recente ed eliminando le procedure di installazione o di aggiornamento. Java Web Start elimina la necessità di scaricare ed installare il software, bypassando le opzioni di installazione.

|In aggiunta a java-vm-args documentata su http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, Web Start supporta -Xgcpolicy per l'impostazione della politica di raccolta dei dati obsoleti.

Per informazioni sui browser supportati da Web Start, consultare Browser supportati.

Per ulteriori informazioni su Web Start, consultare: http://java.sun.com/products/javawebstart e http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Per ulteriori informazioni sulla distribuzione delle applicazioni, consultare: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.

### Esecuzione di Web Start

Java Web Start v5.0 viene installato automaticamente quando si installa Java utilizzando i pacchetti .rpm oppure .tgz.

|Se si estrae Java dal pacchetto .tgz, eseguire la shell script jre/lib/javaws/updateSettings.sh per aggiornare i file .mailcap e .mime.types sul sistema.

E' possibile richiamare Web Start in tre modi:

1. Selezionare un collegamento su una pagina Web che fa riferimento al file .jnlp.
2. Dalla riga shell, immettere `javaws <URL>`, dove `<URL>` è l'ubicazione di un file .jnlp.
3. |Se è già stato utilizzato Java Web Start per aprire l'applicazione, |eseguire javaws dalla directory jre/bin, per avviare |Java Application Cache Viewer.

Una volta scaricata l'applicazione, questa viene memorizzata nella cache delle applicazioni Java. Se si accede di nuovo all'applicazione, Java Web Start scarica una versione più recente dell'applicazione, se disponibile, ed utilizza la versione nella cache nel caso che non vi siano versioni più recenti.

Se si verifica un errore in un file .jnlp (quale un nome tag non valido), Web Start non funziona e non visualizza alcun messaggio di errore.

## Invio di applicazioni Java

Un'applicazione Java, diversamente da un applet Java, non può fare affidamento su browser Web per l'installazione e i servizi runtime. Quando si invia un'applicazione Java, il pacchetto software probabilmente è formato dalla parti seguenti:

- La classe, la risorsa e i file di dati
- Una procedura o programma di installazione

Per eseguire l'applicazione, occorre Runtime Environment per Linux. Il software SDK per Linux contiene un Runtime Environment. Tuttavia, non è possibile supporre che il software SDK per Linux sia installato.

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

| | |

# Condivisione di dati di classe tra JVM

|

L'IBM Virtual Machine (VM) consente di condividere classi bootstrap e delle applicazioni tra VM, memorizzandoli in una cache della memoria condivisa. La condivisione delle classi riduce il consumo totale della memoria virtuale quando più VM condividono una cache. La condivisione di classi riduce inoltre il tempo di avvio per un VM dopo la creazione della cache. La cache della classe condivisa è indipendente da qualsiasi VM attivo e persiste oltre la durata del VM che ha avviato la cache.

| |

## Panoramica sulla condivisione di classi

|

IBM SDK consente di condividere il maggior numero di classi possibile ed è trasparente all'utente.

| |

### Contenuto della cache

|

La cache delle classi condivise contiene dati e metadati di classe statiche di sola lettura che descrivono le classi. Qualsiasi VM può leggere o aggiornare la cache. I VM che sono in condivisione devono essere allo stesso livello di release. Prestare molta attenzione |se viene utilizzata la modifica del bytecode di avvio. (Consultare Modifiche bytecode al runtime.)

| |

### Aggiornamento dinamico della cache

|

Poiché la cache delle classi condivise persiste oltre la durata di qualsiasi VM, la cache viene aggiornata in modo dinamico per riflettere tutte le modifiche che potrebbero essere apportate ai JAR o alle classi nel sistema di file. L'aggiornamento dinamico rende la cache trasparente all'applicazione che la utilizza.

| |

### Abilitazione della condivisione di classi

|

Abilitare la condivisione di classi con l'opzione -Xshareclasses quando si avvia un VM, |affinché il VM si colleghi ad una cache esistente oppure ne crei una se non esiste. Tutte le classi bootstrap e delle applicazioni caricate dal VM vengono condivise per impostazione predefinita. Classloader personalizzati effettuano automaticamente la condivisione se estendono il classloader delle applicazioni, altrimenti, devono utilizzare le API di Java Helper fornite con il VM per accedere alla cache. (Consultare Adattamento dei classloader personalizzati per la condivisione di classi.)

| |

### Sicurezza della cache

|

L'accesso alla cache delle classi condivise è limitato dalle autorizzazioni del sistema operativo e da quelle della sicurezza. La cache delle classi condivise viene creata per impostazione predefinita con l'accesso utente a meno che non venga utilizzata l'opzione secondaria di riga comandi groupAccess. Solo un programma di caricamento classi con classi di condivisione registrate può aggiungere classi alla cache delle classi condivise. Se viene installato un Java SecurityManager, ai ClassLoader, esclusi quelli di estensione, applicazione e bootstrap predefiniti, dovrà essere concessa l'autorizzazione alla condivisione di classi aggiungendo |SharedClassPermissions al file java.policy. (Consultare Utilizzo di SharedClassPermissions.) |RuntimePermission "createClassLoader" limita la creazione di nuovi ClassLoader e di conseguenza anche l'accesso alla cache.

| |

### Intervallo di tempo valido della cache

|

Su un sistema possono esistere più cache e sono specificate per |nome come un'opzione secondaria del comando -Xshareclasses. Una VM può collegarsi ad una sola cache per volta. Viene specificata la dimensione della cache all'avvio utilizzando -Xscmx<n>[k|m|g], ma tale dimensione è quindi fissata per la durata della cache. Le cache esistono finché non vengono distrutte esplicitamente utilizzando un'opzione secondaria del comando |-Xshareclasses oppure finché il sistema non viene riavviato.

| |

### Programmi di utilità della cache

|

Tutti i programmi di utilità della cache sono opzioni secondarie del comando -Xshareclasses. Utilizzare -Xshareclasses:help per consultare un elenco di opzioni secondarie disponibili.

| |

## Utilizzo di opzioni della riga comandi per la condivisione di classi

|

La condivisione di classi è abilitata e configurata utilizzando le opzioni -Xshareclasses e -Xscmx della riga comandi.

|

|
- -Xscmx<dimensione>[k|m|g] |
  |
  - Specifica la dimensione della cache. Questa opzione si applica solo se viene creata cache e non esiste un'altra cache con lo stesso nome. La dimensione predefinita della cache dipende dalla piattaforma. |È possibile scoprire il valore della dimensione utilizzato aggiungendo -verbose:sizes come argomento di riga comandi. La dimensione minima della cache è 4 kB. Anche la dimensione massima della cache dipende dalla piattaforma. (Consultare Limiti di dimensioni della cache.)
|
- -Xshareclasses:<opzionesecondaria1>[,<opzionececondaria2>...] |
  |
  - Abilita la condivisione di classi. Può avere una serie di opzioni secondarie, alcune delle quali sono programmi di utilità della cache. I programmi di utilità della cache effettuano l'operazione richiesta sulla cache specificata ma senza l'avvio del VM. È possibile combinare più opzioni secondarie, separate da virgole, ma i programmi di utilità della cache si escludono a vicenda.
  È possibile utilizzare le seguenti opzioni secondarie con l'opzione -Xshareclasses, ad esempio, -Xshareclasses:help |
  |
  - help |
    |
    - Visualizza un elenco di tutte le opzioni della riga comandi.
  |
  - name=<nome> |
    |
    - Collega una cache di un nome specificato, creando una cache se non esiste già. Utilizzare l'opzione del programma di utilità listAllCaches per visualizzare quale |cache sono disponibili al momento. Se non si specifica un nome, viene utilizzato il nome predefinito |"sharedcc_" viene combinato con il nome utente per creare il nome della cache.
  |
  - 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 |
    |
    - Questa opzione fornisce un'output dettagliato sull'attività di I/O della cache, elencando le informazioni sulle classi che vengono individuate e memorizzate. 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. Si noti che l'opzione standard -verbose:class abilita anche l'output verboso di condivisione classi se la condivisione delle classi è abilitata.
  |
  - modified=<contenuto modificato> |
    |
    - Questa opzione è richiesta se è installato un agente bytecode che possa modificare |bytecode durante il runtime. Se non si specifica questa opzione e viene installato un agente bytecode, non vengono individuate o memorizzate classi nella cache. <contenuto modificato è un descrittore scelto dall'utente, ad esempio, |"myModification1". In tal modo viene partizionata la cache, affinché solo i JVM che utilizzano il contesto |myModification1 possano condividere le stesse classi. Ad esempio, se si esegue "HelloWorld" |con un contesto di modifica e quindi lo si esegue di nuovo con una contesto di modifica differente, verranno visualizzate tutte le classi memorizzate due volte nella cache.
  |
  - destroy (opzione di utilità) |
    |
    - Distrugge una cache utilizzando il nome specificato nell'opzione secondaria name=<nome>. Se non viene specificato il nome, la cache predefinita viene distrutta. Una cache può essere distrutta solo se sono chiusi tutti i VM che la utilizzano e l'utente ha un livello di autorizzazione sufficiente.
  |
  - destroyAll (opzione di utilità) |
    |
    - Cerca di distruggere tutte le cache disponibili agli utenti. Una cache può essere distrutta solo se sono chiusi tutti i VM che la utilizzano e l'utente ha un livello di autorizzazione sufficiente.
  |
  - expire=<tempo espresso in minuti> |(opzione di utilità) |
    |
    - Distrugge tutte le cache che non sono utilizzate nel periodo di tempo specificato.
  |
  - listAllCaches (opzione di utilità) |
    |
    - Fornisce un elenco di tutte le cache sul sistema, indicando se sono in uso e quando sono state utilizzate l'ultima volta.
  |
  - printStats (opzione di utilità) |
    |
    - Visualizza informazioni statistiche di riepilogo sulla cache specificata nell'opzione secondaria name=<nome>. Se non viene specificato il nome, vengono visualizzate le informazioni sulla cache predefinita. Le informazioni più utili visualizzate sono relative a quanto è piena la cache e a quante classi contiene. Si noti che le classi "stale" sono classi aggiornate sul sistema di file e che la cache ha quindi contrassegnato come "stale". Le classi stale non vengono eliminate dalla cache. Consultare Diagnostics Guide per ulteriori informazioni.
  |
  - printAllStats (opzioni di utilità) |
    |
    - Visualizza informazioni dettagliate sul contesto della cache specificata nell'opzione secondaria name=<nome>. |Se non viene specificato il nome, vengono visualizzate le informazioni sulla cache predefinita. |Ogni classe viene elencata in ordine cronologico con un riferimento alla posizione dalla quale è stata caricata. Consultare Diagnostics Guide per ulteriori informazioni.

| |

## Creazione, popolamento ed eliminazione di una cache

|

Per abilitare la condivisione di classi, aggiungere -Xshareclasses[:name=<nome |alla riga comandi dell'applicazione. La VM si collegherà ad una cache esistente con il nome specificato oppure creerà una nuova cache con quel nome. Se è stata creata una nuova cache, in essa verranno inserite tutte le classi bootstrap e delle applicazioni caricate finché non si riempie. Se vengono avviati contemporaneamente due o più VM, popoleranno tutti contemporaneamente la cache.

|

Per verificare che la cache sia stata creata, eseguire `java -Xshareclasses:listAllCaches`. Per verificare quante classi sono state memorizzate e quanti dati delle classi, eseguire `java -Xshareclasses:[name=<nome>],printStats`. Tali programmi di utilità possono essere eseguiti dopo che il VM dell'applicazione è stato terminato oppure in un'altra finestra comandi.

|

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

|

Per eliminare la cache creata, eseguire `java -Xshareclasses:[name=<nome>],delete`. Occorre eliminare le cache solo se contengono molte classi stale oppure se la cache è piena e si desidera crearne una più grande.

|

Si consiglia di regolare la dimensione della cache per la specifica applicazione utilizzata, perché è improbabile che l'impostazione predefinita sia la dimensione ottimale. Il modo migliore per determinare la dimensione ottimale per la cache consiste nello specificare una cache di grandi dimensioni (utilizzando -Xscmx), eseguire l'applicazione e quindi utilizzare printStats per stabilire la quantità di dati di classe memorizzati. Aggiungere una piccola quantità al valore mostrato in printStats. Si noti che poiché le classi possono essere caricare in qualsiasi momento della durata della VM, è consigliabile eseguire questa analisi una volta terminata l'applicazione. Tuttavia, una cache completa non ha un impatto negativo sulle prestazioni o sulle funzionalità delle VM ad essa collegate, pertanto è possibile impostare una dimensione della cache più piccola di quella richiesta.

|

Se una cache si riempie, viene emesso un messaggio sulla riga comandi di tutte le VM che utilizzano tale cache e le VM caricheranno ulteriori classi nella propria memoria processi. Le classi in una cache piena possono essere condivise, ma una cache piena è di sola lettura e non può essere aggiornata con nuove classi.

| |

## Prestazioni e consumo della memoria

|

La condivisione di classi è particolarmente utile su sistemi che utilizzano più VM con un codice simile; i traggono vantaggio dal consumo ridotto di memoria virtuale. Inoltre, è utile su sistemi che avviano e chiudono VM di frequente, che traggono vantaggio dal miglioramento del tempo di avvio.

|

Il sovraccarico per creare e popolare una nuova cache è minimo. Il consumo per il tempo di avvio per una singola VM è compreso tra 0 e 5%, a seconda di quante classi vengono caricate. Il miglioramento del tempo di avvio del VM con una cache popolata è di solito tra il 10% e il 40%, a seconda del sistema operativo e del numero di classi caricate. Più VM in esecuzione contemporaneamente mostrano maggiori vantaggi del tempo di avvio generale.

|

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

| |

## Limitazioni e considerazioni sull'uso della condivisione di classi

| |

### Limiti di dimensioni della cache

|

La cache per la condivisione delle classi viene allocata con il meccanismo System |V IPC Shared Memory.

|

La cache massima teorica è 2 GB. La dimensione della |cache che è possibile specificare è limitata dalla quantità di spazio fisico e di paginazione disponibile sul sistema.

|

Dal momento che lo spazio di indirizzo virtuale di un processo viene condiviso tra la cache di classi condivise e l'heap |Java, l'aumento della dimensione massima dell'heap Java riduce 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 individuare tali impostazioni nel file /proc/sys/kernel/shmmax. SHMMAX è di solito impostato a 30 MB.

| |

### Modifiche bytecode al runtime

|

Qualsiasi VM che utilizza un agente JVMTI, che può modificare bytecode, non è in grado di condividere le classi a meno che non si utilizzi l'opzione secondaria modified=<contesto_modificato> da riga comandi (consultare la sezione relativa). Il contesto modificato è un descrittore specificato dall'utente che descrive il tipo di modifica da effettuare. Tutti i VM che utilizzano un contesto modificato specificato devono modificare il |bytecode in un modo ripetibile e prevedibile per ciascuna classe, così che le classi memorizzate nella cache avranno le modifiche previste quando verranno caricate da un altro VM. Ogni modifica deve essere prevedibile poiché le classi caricate da una cache di classi condivise non può essere modificata di nuovo dall'agente. Si noti che bytecode modificati e non modificati possono essere memorizzati nella stessa cache. Consultare Diagnostics Guide per ulteriori informazioni su questo argomento.

| |

### Limitazioni del sistema operativo

|

Per sistemi operativi che possono eseguire applicazioni sia a 32 bit che a 64 bit, non è consentita la condivisione di classi tra VM a 32 bit e quelli a 64 bit. |L'opzione secondaria listAllCaches elencherà le cache a 31 bit e quelle a 64 bit, a seconda del modo di indirizzo del VM utilizzato.

|

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 di identificazione viene eliminata, il VM non può identificare le classi condivise sul sistema e devono ricreare la cache. Utilizzare il comando `ipcs` per visualizzare i segmenti della memoria utilizzati da un VM o 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 SharedClassPermissions

|

Se SecurityManager viene utilizzato insieme alla condivisione delle classi e l'applicazione in esecuzione utilizza propri classloader, a tali devono essere concesse autorizzazioni SharedClassPermissions prima di poter condividere le classi. Aggiungere SharedClassPermissions |al file java.policy utilizzando al nome classe ClassLoader (i caratteri jolly sono consentiti) |e "read", "write" o "read,write" per determinare l'accesso concesso. |Ad esempio:

|

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

Se un ClassLoader non ha l'autorizzazione SharedClassPermission corretta e tenta di condividere classi, viene inviata un'eccezione AccessControlException. Non è possibile modificare o ridurre le autorizzazioni dei classloader di estensione, applicazione o bootstrap predefiniti.

| |

## Adattamento dei classloader personalizzati per la condivisione di classi

|

Più applicazioni Java utilizzeranno i propri classloader del VM oppure avranno classloader personalizzati |che estendono java/net/URLClassLoader. Le applicazioni che utilizzano tali classloader potranno condividere automaticamente le classi bootstrap e delle applicazioni. |I classloader personalizzati, che non estendono java/net/URLClassLoader, richiedono che le modifiche utilizzino la condivisione di classi. A tutti i classloader personalizzati dovranno essere concesse autorizzazioni SharedClassPermissions se viene utilizzato un SecurityManager. Consultare. Utilizzo di SharedClassPermissions. IBM fornisce svariate interfacce Java per diversi tipi di classloader personalizzati, che consentono ai classloader di individuare e memorizzare classi nella cache di classi condivise. |Tali classi si trovano nel pacchetto |com.ibm.oti.shared. Il Javadoc per questo pacchetto è fornito con il SDK nel file docs/apidoc.zip. |Consultare Diagnostics |Guide per ulteriori informazioni su queste interfacce.

# Servizio e supporto per fornitori di software indipendente

Se si ha diritto ai servizi per il codice del programma conforme a IBM Solutions Developer Program, rivolgersi a IBM Solutions Developer Program attraverso il normale metodo di accesso oppure presso il seguente sito Web: http://www-1.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 Runtime Environment sono state testate usando dei lettori di schermi. E' possibile usare uno screen reader come Home Page Reader o JAWS con queste guide.

Per cambiare le dimensioni dei font nelle guide, usare la funzione fornita dal browser, che di solito si trova nel menu Visualizza.

Per gli utenti che richiedono la navigazione tramite tastiera, una descrizione delle sequenze di tasti per le applicazioni Swing è reperibile in "Swing Key Bindings" all'indirizzo Webhttp://www-128.ibm.com/developerworks/java/jdk/additional/

## Accessibilità iKeyman

|Oltre alla GUI, il tool iKeyman fornire il tool di riga comandi IKEYCMD, che ha le stesse funzioni della GUI. IKEYCMD consente di gestire chiavi, certificati e richieste di |certificato. E' possibile chiamare IKEYCMD dagli script shell nativi e dai programmi che devono essere usati quando le |applicazioni hanno bisogno di aggiungere interfacce personalizzate al certificato e alle attività di gestione chiavi. IKEYCMD può creare file di database per tutti i tipi che |iKeyman supporta al momento. IKEYCMD può inoltre creare richieste di certificati, importare |certificati firmati CA e gestire certificati auto-firmati.

Per eseguire un comando IKEYCMD, immettere:

    java [-Dikeycmd.properties=<file properties>]com.ibm.gsk.ikeyman.ikeycmd
    <oggetto> <azione> [opzioni]

dove:

<oggetto>
  è uno dei sguenti:
  -keydb
    Azioni intraprese sul database di chiavi (un file del database di chiavi CMS, un file keyring WebDB oppure di classe SSLight)
  -cert
    Azioni da eseguire su un certificato in un database di chiavi
  -certreq
    Azioni da eseguire a una richiesta di certificato in un database di chiavi
  -version
    Visualizza informazioni sulla versione per IKEYCMD
  -help
    Visualizza l'aiuto per i richiami IKEYCMD.
<azione>
  |L'azione specificata intrapresa sull'oggetto. Per visualizzare le azioni disponibili per un oggetto, richiamare IKEYCMD passando solo l'oggetto come argomento. Viene visualizzata la guida sensibile al contesto che mostra le azioni disponibili per l'oggetto.
-Dikeycmd.properties
  Specifica il nome del file facoltativo delle proprietà da usare per questo richiamo di Java. Un file predefinito delle proprietà, ikeycmd.properties, è fornito come campione da modificare e usare da qualunque applicazione Java.

Nota:
Le parole chiave dell'oggetto e dell'azione devono trovarsi in una sequenza specificata. Tuttavia, le opzioni non sono legate alla posizione e possono essere in una sequenza qualunque, purché vengano specificate come opzione e coppia di operandi.

Per ulteriori informazioni, consultare la guida di iKeyman all'indirizzo: http://www.ibm.com/developerworks/java/jdk/security/index.html.

## Tastiera trasversale di componenti JComboBox in Swing

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

## (Solo Linux IA 32-bit, PPC32 e PPC64) Accessibilità Web Start

IBM Java Web Start v5.0 contiene diversi miglioramenti di accessibilità ed utilizzo rispetto ai release precedenti, compreso un supporto migliore per screen reader e una tastiera per la navigazione migliorata.

E' possibile usare la riga comandi solo per lanciare un'applicazione Java abilitata per 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 impostabili in Java Application Cache Viewer sono disponibili nel file di configurazione.

# Limiti noti

Le sezioni seguenti illustrano i limiti noti di SDK e Runtime Environment per Linux.

## Limiti validi per tutte le piattaforme Linux tranne dove indicato

- |Il gestore finestre potrebbe sovrascrivere alcuni dei collegamenti da tastiera Java. Se è necessario un collegamento da tastiera Java sovrascritto, consultare il manuale del sistema operativo utilizzato e modificare i collegamenti da tastiera del gestore finestre. |

- |X Windows System non è in grado di utilizzare i 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.

- Potrebbe non essere possibile utilizzare gli Appunti di sistema con i caratteri DBCS (double-byte character set) per copiare le informazioni tra applicazioni Linux e Java se si utilizza KDE (K Desktop Environment).

- Su RHEL3, SLES9 e su distribuzioni più recenti, la libreria di threading predefinita è 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 sottoprocessi 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:

  - Le impostazioni dell'utente (ulimit -u) in /etc/security/limits.conf
  - Il limite definito in /proc/sys/kernel/threads_max
  - Il limite PTHREAD_THREADS_MAX definito in libpthreads.so (la modifica di questo valore richiede la ricompilazione di glibc)

  Tuttavia, la memoria virtuale potrebbe esaurirsi prima di raggiungere il numero massimo di thread.

- Se si termina un'applicazione Java con Ctrl-C, diversi processi potrebbero essere lasciati in sospeso.

- I risultati di KeyEvent che includono l'utilizzo del tasto ALT variano in base ai diversi gestori di finestre in Linux. Inoltre, variano anche dai risultati di altri sistemi operativi. Nella finestra di Enlightenment, Alt+A e Maius+Alt+A comportano l'esecuzione di diverse funzioni di modifica, mentre Ctrl+Alt+A non produce alcun risultato. In WindowMaker, invece la combinazione di tasti Ctrl+Alt+A è associata ad una funzione.

- 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

  Questo è il motivo per cui SDK considera che Meta e Alt vengano premuti insieme. 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"

  Nota:
  Tale operazione potrebbe influire su altre applicazioni X-Window in esecuzione nello stesso schermo se utilizzano il tasto Meta eliminato.

- La creazione di coppie di chiavi DSA di lunghezza insolita può richiedere molto tempo su macchine lente. Il ritardo non indica un blocco. L'algoritmo di generazione delle chiavi DSA è stato ottimizzato in modo da generare lunghezze di chiavi standard (ad esempio 512, 1024) più velocemente di altre.

- I programmi nativi non possono creare una VM con interfacce JNI_VERSION_1_1(0x00010001). Non è possibile richiamare JNI_CreateJavaVM() e passargli una versione di JNI_VERSION_1_1(0x00010001). Le versioni che possono essere passate sono:
  - JNI_VERSION_1_2(0x00010002)
  - JNI_VERSION_1_4(0x00010004)

  La VM creata viene determinata dalle librerie Java presenti (quindi 1.2.2, 1.3.x, 1.4.x, 5.x), non quella indicata dalla versione dell'interfaccia JNI passata.

  La versione dell'interfaccia non influenza alcuna area della funzionalità della VM se non le funzioni disponibili sul codice nativo.

- Una chiamata a JNI_CreateJavaVM() dall'applicazione JNI può causare un errore di segmentazione (segnale SIGSEGV); per evitarlo, ricreare il programma JNI specificando l'opzione -lpthread.

- Solo per gli utenti di cinese classico, i tasti Invio, Spazio, Indietro ed ESC non funzionano nel modo previsto quando si utilizzano gli IME LinYi ZhuYin, YiTian ZhuYin e Bosham per l'immissione dei caratteri TCH. Il tasto Invio inserisce una nuova riga, il stato ESC è utilizzato per cancellare una stringa modificata o la finestra candidati e la barra spaziatrice inserisce uno spazio. La finestra candidati dovrebbe scomparire dopo che viene premuto il tasto di commit e non dovrebbe essere visualizzata quando si preme il tasto Indietro mentre si utilizzano gli IME Bosham, LinYi ZhuYin e YiTian ZhuYin per l'immissione di caratteri in Cinese tradizionale.

- Se sono in esecuzione molti thread contemporaneamente, potrebbe essere visualizzato un messaggio di avvertenza: `java.lang.OutOfMemoryError`. Tale messaggio indica che le risorse di sistema della macchina sono in esaurimento; i messaggi possono essere determinati dalle seguenti cause:
  1. Non è possibile creare nuovi thread perché:
     - Il numero di processi creati supera il limite utente. (Se la propria installazione Linux utilizza LinuxThreads, anziché NPTL.)
     - Non sono disponibili risorse di sistema sufficienti per creare nuovi thread. In questo caso, potrebbero essere visualizzate anche altre eccezioni Java, in base all'applicazione in esecuzione.
  2. La memoria del kernel è in esaurimento oppure è frammentata. Potrebbero essere visualizzati messaggi kernel relativi all'esaurimento della memoria in /var/log/messages con gli ID processo terminati.
  Provare a regolare il sistema in modo da incrementare le risorse di sistema corrispondenti.

- Durante l'installazione, se è già stata installata una versione precedente di questo prodotto distribuita da Red Hat, RPM (Red Hat Package Manager) indica che il pacchetto IBM è precedente rispetto a qualsiasi versione del prodotto distribuita da Red Hat. Questa condizione si verifica perché Red Hat aggiunge al pacchetto RPM un "numero di serie" che ricopre lo schema della versione del prodotto nel pacchetto e, per impostazione predefinita, RPM non installa un pacchetto precedente ad un pacchetto già installato. L'opzione --oldpackage del comando rpm consente di installare il nuovo pacchetto IBM.

- Quando si esegue un'applicazione Java AWT/Swing su una macchina Linux e si esporta la visualizzazione su una seconda macchina, è possibile che si verifichino dei problemi nella visualizzazione di alcune finestre di dialogo se il gruppo di font caricato sulla macchina client X è diverso dal gruppo caricato sulla macchina server X. Questo problema può verificarsi in particolare con SLES8 con delle locale in cinese, dove l'installazione predefinita della versione server installa i font arphic ma l'installazione del client non lo fa. Per evitare questo problema, installare gli stessi font su entrambe le macchine.

- Se la propria locale di sistema sta utilizzando una codifica UTF-8, alcune funzioni SDK potrebbero generare una sun.io.MalformedInputException. Per rilevare se il proprio sistema sta utilizzando una codifica UTF-8, esaminare le variabili di ambiente specifiche per la locale, quali LANG o LC_ALL per vedere se finiscono con il suffisso ".UTF-8". Se si riceve tale sun.io.MalformedInputException, modificare i caratteri che non rientrano nell'intervallo ASCII a 7 bit (0x00 - 0x7f) e non sono rappresentati come valori letterali di carattere Unicode in valori letterali di carattere Unicode Java (ad esempio: '\u0080'). E' anche 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".
  Nota:
  alcune distribuzioni di Red Hat, incluso Red hat 9 e RHEL3, utilizzano la codifica UTF-8 per impostazione predefinita.

- 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, rivolgersi al distributore Linux.

- Su Red Hat Enterprise Linux 3, i caratteri cinesi potrebbero non essere visualizzati nei componenti di testo AWT fatta eccezione per i caratteri GB2312 nella locale GB18030 in cinese.

- |Nel tool JConsole di IBM, la scheda Locale |che consente di collegarsi alle altre macchine virtuali sulle stesso sistema non è disponibile. Utilizzare invece la scheda Remoto di JConsole |per collegarsi alla Virtual Machine da controllare. Quando viene avviata l'applicazione da controllare, impostare le seguenti opzioni di riga comandi: |
  |
  - -Dcom.sun.management.jmxremote.port=<valore> per specificare la porta su cui deve essere in attesa l'agente di gestione.
  |
  - -Dcom.sun.management.jmxremote.authenticate=false per disabilitare l'autenticazione a meno che non è stato creato un file di nomi utente.
  |
  - -Dcom.sun.management.jmxremote.ssl=false per disabilitare la crittografia SSL.
  |

- |Gli gli utenti di lingua cinese, coreana e giapponese di Red Hat Enterprise Linux 4 che utilizzano IIMF (Internet/Intranet Input Method Framework), devono utilizzare pacchetti IIIMF inclusi in |Linux 4 Update 2 o versioni successive. Inoltre, si noti il seguente problema. Se si verifica questo problema, contattare Hat all'indirizzo http://www.redhat.com. |
  |
  - Su Linux zSeries 64-bit, potrebbero verificarsi errori IIIMF o un errore di avvio. Vedere Red Hat Bugzilla numero RIT73533 (solo utenti giapponesi).
  |

- |Solo utenti di lingua cinese semplificata di Red Hat Enterprise |Linux 4. La locale zh_CN.GB18030 non è supportata da xlib a RHEL4. |xterm non è in grado di attivare il metodo di input per immettere i caratteri GB18030. Utilizzare invece la locale zh_CN.UTF8. Se si dispone di programmi precedenti o di dati codificati con GB2312, GBK, |o GB18030 e si desidera migrarli a RHEL4, è necessario pre-elaborarli con iconv per convertirli in codifica utf-8 affinché i programmi possano essere eseguiti e i dati possano essere visualizzati correttamente in RHEL4 con la locale zh_CN.UTF8. |

- |Su RHEL 3 con miniChinput (server XIM in cinese semplificato) su ambienti a 64 bit (ad esempio AMD64 o piattaforme zSeries 64-bit), potrebbero verificarsi comportamenti imprevisti con Java. Contattare Red Hat, all'indirizzo http://www.redhat.com. Vedere Red Hat Bugzilla numero |RIT75701. |

- |Su RHEL 3 con ami (server XIM in coreano), potrebbe verificarsi un comportamento imprevisto con Java su ambienti a 64 bit (ad esempio AMD64 o piattaforme zSeries 64-bit). Contattare Red Hat, all'indirizzo http://www.redhat.com. vedere Red Hat Bugzilla numeri RIT73605 e RIT75708. |

- |Su RHEL 4 con xcin (server XIM in cinese tradizionale), potrebbe verificarsi un comportamento imprevisto, ad esempio errori di segmentazione, con Java |su ambienti a 64 bit (ad esempio AMD64 o piattaforme zSeries 64-bit). Contattare |Red Hat, all'indirizzo http://www.redhat.com. |Vedere Red Hat Bugzilla numero |RIT78430. |

- |Gli utenti di lingua giapponese,e cinese e coreana non possono utilizzare XIM per immettere i propri caratteri in componenti di testo su un'applet Java in un browser Web. |Questa limitazione perché XEmbed richiede una fix per il file di libreria X11. |Per evitare questa situazione, specificare il parametro di sistema -Dsun.awt.noxembed=true per disabilitare XEmbed. È possibile impostare questa opzione utilizzando il pannello di controllo: |
  |
  1. Aprire il pannello di controllo del Plug-in Java e selezionare la scheda Java.
  |
  2. Fare clic sul pulsante View in Java Applet Runtime |Settings.
  |
  3. Immettere -Dsun.awt.noxembed=true in Java Runtime |Parameters e fare clic su OK.
  |
  4. fare clic su Apply
  |
  5. Avviare un browser.
  |

## Limitazioni di Linux IA a 32 bit

- Per gli utenti di testo in arabo, quando si utilizza Linux con una scheda video Matrox e l'accelerazione abilitata, potrebbe verificarsi una distorsione dei caratteri quando si utilizza drawString per visualizzare dei font grandi. Questo problema è causato dal driver per queste schede. Il metodo consigliato per aggirare questo problema è la disabilitazione dell'accelerazione per la periferica.

- Su SLES 9 NPTL, il driver della porta parallela causa un arresto anomalo del kernel e e arresta il thread Java. La JVM rileva tale arresto anomalo quando tenta di sospendere il thread per la raccolta di dati obsoleti e quindi viene arrestata in modo anomalo producendo un file di base e il messaggio JVMLH030 che indica che i threads smettono di essere visualizzati quando se ne tenta la relativa sospensione.

  Il prospetto SUSE Bugzilla 47947 viene emesso rispetto a questo problema. Tale bug viene corretto in SLES 9 Service Pack 1.

## Limitazioni di Linux AMD64

| |
- Nota importante sulle impostazioni BIOS su sistemi AMD64 SMP: |

  L'impostazione BIOS Node memory interleaving deve essere impostazione su `DISABLED`. Altrimenti, possono verificarsi risultati imprevedibili, comprese interruzioni e blocchi di Java. Questa istruzione è conforme con le raccomandazioni di AMD.

## Limitazioni di Linux PPC a 32 bit e a 64 bit

- Se il codice Java utilizza le chiamate JNI e una qualsiasi chiamata dispone di più di 8 elementi mobili o di parametri doppi, il codice C dovrà essere compilato con il livello gcc-2.95.3 Free Software Foundation (FSF) del compilatore GNU C (GCC).

- Se si esegue XFree86 versione 3.x, viene ricevuto un errore SIGSEGV. Per evitare tale problema, si consiglia di utilizzare XFree86 versione 4.x.

- Se la data è antecedente al 1970, all'avvio di Java si otterrà un errore di eccezione. Per risolvere questo problema, impostare manualmente la macchina sulla data corrente.

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

- A causa della funzione IOCTL non implementata nella modalità a 32 bit del kernel a 64 bit, JavaComm non supporta le operazioni di porte seriali su SLES 9 e RHEL 4. Questa limitazione viene risolta in SLES 9 SP2 (numero Bugzilla 49787) e RHEL 4 aggiornamento 1 (numero Bugzilla 144904).

## Limitazioni di Linux PPC a 64 bit

- Il compilatore gcc cross predefinito (versione 3.2-49) causa vari errori. Per generare la libreria condivisa libFileStat.so, eseguire `/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<PERCORSO_SDK>/include FileStat.c` dove `<PERCORSO_SDK>` è il percorso per la directory dell'SDK installato.

## Limitazioni di Linux zSeries a 64 bit

Le seguenti limitazioni di applicano solo a utenti di lingua cinese e taiwanese su Linux zSeries 64-bit:

- Il server del metodo di input in cinese e taiwanese non è stato testato con la versione 5.0.

## Limitazioni di Linux zSeries a 31 bit e a 64 bit

- Se si utilizza l'audio su una macchina che non dispone di scheda audio, potrebbe essere visualizzato un messaggio che indica che la memoria non è sufficiente quando Java prova a riprodurre suoni. Il messaggio viene visualizzato nella console, ma non influenza l'applicazione Java.

- Sebbene il kernel Linux nelle distribuzioni correnti fornisca il supporto per IP6 (Internet Protocol versione 6), potrebbero verificarsi alcuni problemi durante il relativo utilizzo. In questo rilascio è incluso il supporto per IP6 da Java, tuttavia è necessario disabilitare il supporto utilizzando l'opzione -Djava.net.preferIPv4Stack=true del comando Java. Se si installa un kernel che supporta completamente IP6, questa opzione non è necessaria.

- |Se si utilizza Java per zSeries 31-bit o 64-bit con server X |con un'impostazione di risoluzione alta, i simboli dei font in un componente AWT Choice con |Motif AWT potrebbero essere tagliati. Per evitare questo problema, abbassare l'impostazione della risoluzione oppure utilizzare XAWT anziché Motif AWT. |

# Inoltro dei commenti relativi a questa guida utente

Se si hanno dei commenti da esprimere relativi all'utilità o dei commenti di qualsiasi tipo su questa guida è possibile utilizzare uno dei canali riportati di seguito. Si noti che tali canali non sono impostati per rispondere ad interrogazioni tecniche ma sono intesi solo per i commenti relativi alla documentazione. Inviare i commenti a:

- Tramite e-mail a idrcf@hursley.ibm.com.
- Con fax:
  - Dal Regno Unito: 01962 842327
  - Da fuori il Regno Unito:<prefisso internazionale>44 1962 842327
- Per posta a:
  IBM United Kingdom Ltd
  User Technologies,
  Mail Point 095
  Hursley Park
  Winchester
  Hampshire
  SO21 2JN United Kingdom

Annotazioni. Inviando un messaggio alla IBM, tutte le informazioni in esso contenute, incluso i dati di feedback, come ad esempio domande, commenti, suggerimenti verranno ritenute non riservate e IBM non avrà nessun obbligo di nessun tipo rispetto a tali informazioni e potrà riprodurle, utilizzarle, diffonderle e distribuirle a terzi illimitatamente. IBM inoltre, si riserva il diritto di utilizzare idee, concetti, conoscenze o tecniche contenute in tali informazioni per qualsiasi scopo, incluso ma non limitato allo sviluppo, fabbricazione e commercializzazione di prodotti che incorporano tali informazioni.

# Informazioni particolari

Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati Uniti d'America. E' possibile che la IBM non offra i prodotti, i servizi o le funzioni trattati in questo documento in altri paesi. Consultare il rappresentante commerciale IBM per informazioni relative ai prodotti e servizi disponibili nel proprio paese. Ogni riferimento a prodotti programmi o servizi IBM non significa che possano essere usati soltanto tali programmi, prodotti o servizi. In sostituzione a quelli forniti dall'IBM, possono essere usati prodotti, programmi o servizi funzionalmente equivalenti che non comportino violazione dei diritti di proprietà intellettuale. Tuttavia, è responsabilità dell'utente valutare e verificare la possibilità di usare programmi, prodotti o servizi non IBM.

L'IBM può avere brevetti o domande di brevetto in corso relativi a quanto trattato nella presente pubblicazione. La fornitura di questa pubblicazione non implica la concessione di alcuna licenza su di essi. Chi desiderasse ricevere informazioni relative a licenze può rivolgersi per iscritto a:

- IBM Director of Licensing
  IBM Corporation
  North Castle Drive, Armonk
  NY 10504-1758 U.S.A.

Chi desiderasse ricevere delucidazioni sulle licenze relative alle informazioni DBCS, può contattare IBM Intellectual Property Department nel proprio paese o rivolgersi per iscritto a:

- IBM World Trade Asia Corporation Licensing
  2-31 Roppongi 3-chome, Minato-ku
  Tokyo 106-0032, Japan

Il seguente paragrafo non è valido per il Regno Unito o per tutti i paesi le cui leggi nazionali siano in contrasto con le disposizioni in esso contenute:

L'IBM FORNISCE QUESTA PUBBLICAZIONE SENZA ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVI INCLUSE EVENTUALI GARANZIE DI COMMERCIABILITÀ' ED IDONEITÀ' AD UNO SCOPO PARTICOLARE. Alcune nazioni non escludono le garanzie implicite; di conseguenza la suddetta esclusione potrebbe, in questo caso, non essere applicabile.

Queste informazioni potrebbero contenere imprecisioni tecniche o errori tipografici. Le correzioni relative saranno incluse nelle nuove edizioni. L'IBM si riserva il diritto di apportare miglioramenti o modifiche al prodotto o al programma descritto in qualsiasi momento e senza preavviso.

Tutti i riferimenti a pubblicazioni e a siti Web non dell'IBM contenuti in questo documento sono forniti solo per consultazione. I materiali contenuti in tali pubblicazioni e siti Web non fanno parte di questo prodotto e l'utilizzo di questi è a discrezione dell'utente.

L'IBM può utilizzare o distribuire qualsiasi informazione voi forniate nel modo più appropriato senza incorrere in alcuna obbligazione nei vostri riguardi.

Coloro che detengono la licenza su questo programma e desiderano avere informazioni su di esso allo scopo di consentire: (i) uno scambio di informazioni tra programmi indipendenti ed altri (compreso questo) e (ii) l'uso reciproco di tali informazioni, dovrebbero rivolgersi a:

- JIMMAIL@uk.ibm.com
  [Hursley Java Technology Center (JTC) contact]

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

Il programma su licenza descritto in queste informazioni e tutto il materiale su licenza ad esso relativo sono forniti dall'IBM nel rispetto delle condizioni previste dalla licenza d'uso.

I dati relativi alle prestazioni contenuti nel presente documento sono stati ottenuti in un ambiente controllato. Pertanto, i risultati ottenibili in altri ambienti operativi potrebbero variare significativamente. Alcune rilevazioni sono state effettuate su sistemi in fase di sviluppo e non si garantisce in alcun modo che tali rilevazioni siano uguali su tutti i sistemi. Inoltre, alcune rilevazioni non state effettuate tramite estrapolazione. Pertanto, i risultati effettivi possono essere differenti. Gli utenti devono verificare l'applicabilità dei dati negli specifici ambienti operativi.

Le informazioni relative a prodotti non IBM sono state ottenute dai fornitori di tali prodotti. L'IBM non ha verificato tali prodotti e, pertanto, non può garantirne l'accuratezza delle prestazioni. Eventuali commenti relativi alle prestazioni dei prodotti non IBM devono essere indirizzati ai fornitori di tali prodotti.

## Marchi

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

Questo prodotto è basato anche parzialmente su FreeType Project. Per ulteriori informazioni su Freetype, consultare http://www.freetype.org.

Questo prodotto include il software sviluppato da Apache Software Foundation http://www.apache.org/.