Date: 2005-10-25

# IBM SDK and Runtime Environment for Linux platforms, Java 2 Technology Edition, Version 5.0

# Guía del usuario

# Información de copyright

Nota: antes de utilizar esta información y el producto al que da soporte, asegúrese de leer la información general que aparece en Avisos.

Esta edición de la guía del usuario corresponde a:

- IBM 32-bit SDK and Runtime Environment for Linux sobre arquitectura Intel, Java 2 Technology Edition, Versión 5.0
- IBM 64-bit SDK and Runtime Environment for Linux sobre arquitectura AMD64/EM64T, Java 2 Technology Edition, Versión 5.0
- IBM 32-bit SDK and Runtime Environment for Linux sobre iSeries y pSeries, Java 2 Technology Edition, Versión 5.0
- IBM 64-bit SDK and Runtime Environment for Linux sobre iSeries y pSeries, Java 2 Technology Edition, Versión 5.0
- IBM 31-bit SDK and Runtime Environment for Linux sobre zSeries, Java 2 Technology Edition, Versión 5.0
- IBM 64-bit SDK and Runtime Environment for Linux sobre zSeries, Java 2 Technology Edition, Versión 5.0

y a todos los releases y modificaciones siguientes hasta que se indique lo contrario en nuevas ediciones.

(c) Copyright Sun Microsystems, Inc. 1997, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 EE.UU. Reservados todos los derechos.

(c) Copyright International Business Machines Corporation, 1999, 2005. Reservados todos los derechos.

Derechos restringidos para los usuarios del Gobierno de los Estados Unidos - Su uso, duplicación o divulgación están restringidos por el GSA ADP Schedule Contract con IBM Corp.

# Prefacio

Esta Guía del usuario proporciona información general sobre IBM(R) SDK and Runtime Environment for Linux(TM) platforms, Java(TM) 2 Technology Edition, Version 5.0 e información específica sobre las diferencias en la implementación de IBM comparada con la implementación de Sun. Lea esta Guía del usuario además de la documentación más amplia que se proporciona en el sitio Web de Sun: http://java.sun.com.

Para obtener una lista de distribuciones sobre las que se ha comprobado el SDK y Runtime Environment para Linux, consulte: http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html.

La guía Diagnostics Guide proporciona información más detallada sobre la IBM Virtual Machine para Java.

Los términos "Runtime Environment" y "Java Virtual Machine" se utilizan de manera indistinta a lo largo de esta Guía del usuario.

Los cambios técnicos realizados en esta Guía del usuario de la versión 5.0, que no sean los menores u obvios como la actualización de la versión "1.4.2" a "5.0", están indicados en rojo cuando se trata de HTML o una copia impresa en color y mediante barras verticales a la izquierda de los cambios.

# Contenido

Información de copyright
Prefacio
Visión general
Convenciones
Compatibilidad de versiones
Actualización del SDK
Migración desde otras IBM JVM
| |
Hardware soportado para zSeries
Contenido del SDK y el Runtime Environment
Herramientas del Runtime Environment
Herramientas del SDK
Instalación y configuración del SDK y Runtime Environment
Instalación en Red Hat Enterprise Linux (RHEL) 4
| |
Instalación del SDK de 32 bits sobre una arquitectura de 64 bits
Instalación desde un archivo RPM
Instalación desde un archivo .tgz
Configuración del SDK y Runtime Environment para Linux
Establecimiento de la PATH
Establecimiento de la CLASSPATH
Desinstalación del SDK y Runtime Environment para Linux
Desinstalación del paquete instalable Red Hat Package Manager (RPM)
Desinstalación del paquete comprimido Tape Archive (TAR)
Utilización del Runtime Environment
Opciones
Especificación de opciones Java y propiedades del sistema
Opciones estándar
Opciones no estándar
Obtención del número de versión y de nivel de compilación de IBM
Globalización del mandato java
Compilador Just-In-Time (JIT)
Inhabilitación del JIT
Habilitación del JIT
Cómo determinar si el JIT está habilitado
Cómo especificar una política de recopilación de desechos
Opciones de recopilación de desechos
Tiempo de pausa
Reducción del tiempo de pausa
Entornos con almacenamientos dinámicos muy llenos
Cómo procesa las señales la JVM
Señales utilizadas por la JVM
Enlace de un controlador de código nativo con la biblioteca de encadenamiento de señales
Trabajo con pilas flotantes
Transformación de documentos XML
Utilización de una versión anterior de Xerces o Xalan
Utilización del SDK para desarrollar aplicaciones Java
Depuración de aplicaciones Java
Depurador Java (JDB)
Cómo determinar si la aplicación se está ejecutando en una JVM de 32 bits o 64 bits
Cómo escribir aplicaciones JNI
| |
Soporte de recuperación de conectores bloqueados a nivel de hebra
Trabajo con applets
Ejecución de applets con el Visor de applets
Depuración de applets con el Visor de applets
| |
Configuración de la asignación de memoria con páginas grandes
Soporte CORBA
Soporte de GIOP 1.2
Soporte de interceptores portátiles
Soporte de Servicio de nombres interoperativo
Propiedades del sistema para rastrear el ORB
Propiedades del sistema para ajustar el ORB
Permisos de seguridad de Java 2 para el ORB
Clases de implementación de ORB
RMI a través de IIOP
Implementación de la agrupación de manejadores de conexiones para RMI
Soporte BiDireccional mejorado
BigDecimal mejorado
Soporte del símbolo de Euro
Utilización de la API Java Communications (JavaComm)
Instalación de la API Java Communications
Ubicación de los archivos de la API Java Communications
Configuración de la API Java Communications
Cambio de la modalidad de acceso de los puertos serie y paralelo
Habilitación de puertos serie en IBM ThinkPads
Limitaciones de impresión con la API Java Communications
Desinstalación de la API Java Communications
Desinstalación del paquete instalable Red Hat Package Manager (RPM)
Desinstalación del paquete comprimido Tape Archive (TAR)
Documentación de la API Java Communications
Despliegue de aplicaciones Java
(Sólo para Linux IA de 32 bits y PPC32) Utilización del Java Plug-in
Navegadores soportados
Instalación y configuración del Java Plug-in
Soporte de DOM (Document Object Model) común
Utilización de parámetros DBCS
(Sólo para Linux IA de 32 bits, PPC32 y PPC64) Utilización de Web Start
Ejecución de Web Start
Envío de aplicaciones Java
| |
Compartimiento de datos de clases entre JVM
| |
Visión general del compartimiento de clases
| |
Contenido de la antememoria
| |
Actualización dinámica de la antememoria
| |
Habilitación del compartimiento de clases
| |
Seguridad de antememoria
| |
Ciclo de vida de la antememoria
| |
Programas de utilidad de antememoria
| |
Utilización de las opciones de la línea de mandatos para el compartimiento de clases
| |
Cómo crear, llenar, supervisar y suprimir una antememoria
| |
Rendimiento y consumo de memoria
| |
Limitaciones y consideraciones al utilizar el compartimiento de clases
| |
Límites del tamaño de antememoria
| |
Modificación del código de bytes en el tiempo de ejecución
| |
Limitaciones del sistema operativo
| |
Utilización de SharedClassPermissions
| |
Adaptación de cargadores de clases personalizados para compartir clases
Servicio y soporte de proveedores de software independientes
Accesibilidad
Accesibilidad de iKeyman
Recorrido del teclado de componentes JComboBox en Swing
(Sólo para Linux IA de 32 bits, PPC32 y PPC64) Accesibilidad de Web Start
Limitaciones conocidas
Limitaciones aplicables a todas las plataformas Linux excepto donde se indique
Limitaciones de Linux IA de 32 bits
Limitaciones de Linux AMD64
Limitaciones de Linux PPC de 32 bits y 64 bits
Limitaciones de Linux PPC de 64 bits
Limitaciones de Linux zSeries de 64 bits
Limitaciones de Linux zSeries de 31 y 64 bits
Comentarios sobre esta Guía del usuario
Avisos
Marcas registradas

# Visión general

IBM SDK es un entorno de desarrollo para escribir y ejecutar applets y aplicaciones que se ajustan a la interfaz de programas de aplicación (API) central Java 1.4 de IBM.

El SDK incluye el Runtime Environment para Linux, que permite ejecutar sólo aplicaciones Java. Si ha instalado el SDK, está incluido el Runtime Environment.

El Runtime Environment contiene la Java Virtual Machine y archivos de soporte, incluidos los archivos .so no depurables y los archivos de clases. El Runtime Environment contiene sólo un subconjunto de las clases que se encuentran en el SDK y permite dar soporte a un programa Java durante el tiempo de ejecución, pero no permite compilar programas Java. El Runtime Environment para Linux no incluye ninguna de las herramientas de desarrollo como, por ejemplo, appletviewer o el compilador Java (javac), ni clases que sean sólo para sistemas de desarrollo.

Asimismo, para las plataformas IA32, PPC32 y AMD64/EM64T,se proporciona el paquete de la interfaz de programas de aplicación Java Communications para su uso con Runtime Environment para Linux. Puede encontrar información sobre ello en Utilización de la API Java Communications (JavaComm).

El archivo license_xx.html contiene el acuerdo de licencia del software de Runtime Environment para Linux. (xx es la abreviatura del idioma). Para ver o imprimir el acuerdo de licencia, abra el archivo en un navegador Web.

## Convenciones

En esta Guía del usuario se hace referencia al directorio de instalación por omisión del SDK como /opt/ibm/java2-i386-50/. Las plataformas que se incluyen a continuación tienen directorios de instalación por omisión diferentes; sustituya el directorio de la plataforma que está utilizando cuando aparezca /opt/ibm/java2-i386-50/:

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

## Compatibilidad de versiones

En general, cualquier applet o aplicación que se ejecute con una versión anterior del SDK debería ejecutarse correctamente con IBM SDK for Linux, v5.0. No se garantiza que las clases compiladas con este release funcionen en releases anteriores.

Consulte el sitio Web de Sun en http://java.sun.com para ver la documentación de Sun sobre compatibilidad.

## Actualización del SDK

Si desea actualizar el SDK de un release anterior, haga una copia de seguridad de todos los archivos de configuración y los archivos de políticas de seguridad antes de continuar con la actualización.

Después de la actualización, puede que necesite restaurar o reconfigurar estos archivos porque es posible que se hayan sobrescrito durante el proceso de actualización. Compruebe la sintaxis de los archivos nuevos antes de restaurar los archivos originales porque es posible que el formato o las opciones de los archivos hayan cambiado.

## Migración desde otras IBM JVM

En la Versión 1.4.2 para AMD64/EM64T y la Versión 5 para las otras plataformas Linux, el IBM Runtime Environment para Linux contiene nuevas versiones de IBM Java Virtual Machine y el compilador Just-In-Time (JIT). Si realiza una migración desde un IBM Runtime Environment anterior, tenga en cuenta lo siguiente:

- La biblioteca compartida libjvm.so de JVM está instalada en el directorio jre/bin/j9vm. Esto es distinto, por ejemplo, del Runtime Environment para Linux Versión 1.4.2 (para todas las plataformas distintas de AMD64/EM64T), donde está instalada en jre/bin/classic. Las aplicaciones nativas que utilizan la interfaz de invocación JNI deberán añadir la nueva vía de acceso de directorios a sus variables de entorno para poder ubicar la biblioteca de enlaces dinámicos de JVM.
- |JVM Monitoring Interface (JVMMI) ya no está disponible. |Debe volver a escribir las aplicaciones que utilizan esa API. Se recomienda utilizar |JVM Tool Interface (JVMTI) en su lugar. JVMTI no es funcionalmente equivalente a |JVMMI. Para obtener información sobre la JVMTI, consulte |http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ y la guía |Diagnostics Guide.
- |La nueva implementación de JNI cumple la especificación JNI, pero es |distinta de la implementación anterior. Devuelve copias de objetos, en lugar de |fijarlos. Esta diferencia puede generar errores en el código de aplicación JNI. Para |obtener información sobre la depuración del código JNI, consulte |-Xcheck:jni en Opciones no estándar.
- |El formato y el contenido de los registros verbosos del recopilador |de desechos que se obtienen con -verbose:gc han cambiado. Los |datos tienen ahora el formato XML. El contenido de los datos refleja los cambios en |la implementación del recopilador de desechos en la JVM, y la mayoría de las |estadísticas de salida han cambiado. Debe modificar los programas que procesen la |salida verbosa de la GC para que funcionen con el nuevo formato y los nuevos datos. |Consulte la guía Diagnostics Guide para ver un |ejemplo de los nuevos datos verbosos de la GC.
- Las versiones anteriores del IBM JRE se suministraban con un archivo denominado rt.jar en el directorio jre/lib. De Java v1.4 en adelante, este archivo se ha sustituido por varios archivos JAR que residen en el directorio jre/lib.
- |Para obtener más información sobre la compatibilidad del |sector y las API desechadas, consulte |Sun's Java 5 Compatibility Documentation y Sun's Java 5 Depreciated API List

| | |

## Hardware soportado para zSeries

|

Los SDK de 31 bits y 64 bits para zSeries y los |Runtime Environment se ejecutan en los siguientes servidores de System z9 y zSeries o equivalentes:

|

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

# Contenido del SDK y el Runtime Environment

El SDK contiene varias herramientas de desarrollo y un Java Runtime Environment (JRE). En este apartado se describe el contenido de las herramientas del SDK y el Runtime Environment.

Las aplicaciones que se graban completamente en Java no deben tener dependencias de la estructura de directorios del IBM SDK (o los archivos en esos directorios). Una dependencia de la estructura de directorios del SDK (o los archivos en esos directorios) puede generar problemas de portabilidad de aplicaciones.

## Herramientas del Runtime Environment

- Clases centrales -- Son los archivos de las clases compiladas de la plataforma y deben permanecer comprimidos para que el compilador y el intérprete puedan acceder a ellos. No modifique estas clases; en su lugar, cree subclases y realice alteraciones temporales cuando sea necesario.
- Herramientas JRE -- Las siguientes herramientas forman parte del Runtime Environment y se encuentran en el directorio jre/bin a menos que se especifique lo contrario.
  - java (Intérprete Java)
    - Ejecuta clases Java. El Intérprete Java ejecuta programas escritos en el lenguaje de programación Java.
  - javaw (Intérprete Java)
    - Ejecuta clases Java de la misma forma que el mandato java, pero no utiliza una ventana de consola.
  - keytool (Herramienta de gestión de claves y certificados)
    - Gestiona un almacén de claves (base de datos) de claves privadas y sus cadenas de certificados X.509 asociadas que autentican las claves públicas correspondientes.
  - policytool (Herramienta de gestión y creación de archivos de políticas)
    - Crea y modifica los archivos externos de configuración de políticas que definen la política de seguridad Java de la instalación.
  - rmid (Daemon del sistema de activación RMI)
    - Inicia el daemon del sistema de activación para que los objetos se puedan registrar y activar en una Java Virtual Machine (JVM).
  - tnameserv (Servicio de nombres CORBA (Common Object Request Broker Architecture))
    - Inicia el servicio de nombres transitorios CORBA.
  - rmiregistry (Registro de objetos remotos Java)
    - Crea e inicia un registro de objetos remotos en el puerto especificado del sistema principal actual.
  - ikeyman (Programa de utilidad iKeyman GUI)
    - Permite gestionar claves, certificados y peticiones de certificado. Para obtener más información, consulte el manual adjunto Security Guide y http://www.ibm.com/developerworks/java/jdk/security. El SDK también proporciona una versión de línea de mandatos de este programa de utilidad. Consulte el apartado Accesibilidad de iKeyman para obtener más información.
  - jextract (Extractor de vuelco)
    - Convierte un vuelco producido por el sistema en un formato común que se pueda utilizar en jdmpview. Para obtener más información, consulte la guía Diagnostics Guide.
  - (Sólo para Linux IA de 32 bits, PPC32 y PPC64) javaws (Java Web Start)
    - Habilita el despliegue y el mantenimiento automático de aplicaciones Java.
  - (Sólo para Linux IA de 32 bits, PPC32 y PPC64)|updateSettings.sh (Valores de Java Web Start)
    - Configura el sistema para utilizar Web Start con el navegador. Para obtener más información, consulte el apartado Ejecución de Web Start. Este archivo está instalado en el directorio jre/lib/javaws.

## Herramientas del SDK

- Las siguientes herramientas forman parte del SDK y se encuentran en el directorio /opt/ibm/java2-i386-50/bin :
  - javac (Compilador Java)
    - Compila programas escritos en el lenguaje de programación Java en códigos de bytes (código Java compilado).
  - appletviewer (Visor de applets de Java)
    - Prueba y ejecuta applets fuera de un navegador Web.
  - jdb (Depurador Java)
    - Permite depurar los programas Java.
  - javap (Desensamblador de archivos de clases)
    - Desensambla los archivos compilados y permite imprimir una representación de los códigos de bytes.
  - javadoc (Generación de documentación de Java)
    - Genera páginas HTML de documentación de la API desde archivos de origen Java.
  - javah (Generador de archivos de resguardo y cabeceras C)
    - Permite asociar métodos nativos con código escrito en el lenguaje de programación Java.
  - jar (Java Archive Tool)
    - Combina varios archivos en un único archivo JAR (Java Archive).
  - jarsigner (Herramienta de verificación y firmas de JAR)
    - Genera firmas para archivos JAR y verifica las firmas de los archivos JAR firmados.
  - jconsole (Herramienta de supervisión y gestión JConsole - experimental)
    - Herramienta gráfica experimental compatible con JMX (no soportado) para supervisar las JVM remotas y locales.
  - native2ascii (Conversor de nativa a ASCII)
    - Convierte un archivo de codificación nativa en un archivo ASCII que contiene caracteres codificados en Latin-1, Unicode o ambos.
  - rmic (Conversor de apéndices de invocación a método remoto (RMI) de Java)
    - Genera apéndices, esqueletos y nudos de objetos remotos. Incluye el soporte RMI-IIOP (RMI a través de Internet Inter-ORB Protocol).
  - java-rmi.cgi (Herramienta de envío de peticiones de HTTP a CGI)
    - Acepta peticiones RMI sobre HTTP y las envía a un listado de servidores RMI de cualquier puerto.
  - idlj (Compilador de IDL en Java)
    - Genera enlaces Java de un determinado archivo IDL.
  - serialver (Mandato de versión de serie)
    - Devuelve el serialVersionUID de una o varias clases en un formato adecuado para copiarlo en una clase en evolución.
  - extcheck (Programa de utilidad Extcheck)
    - Detecta conflictos de versión entre un archivo jar de destino y archivos jar de ampliación instalados actualmente.
  - jdmpview (Formateador de vuelcos entre plataformas)
    - Herramienta que le permite analizar los vuelcos. Para obtener más información, consulte la guía Diagnostics Guide.
  - (Sólo para Linux IA de 32 bits, PPC32 y PPC64) htmlconverter (Java Plug-in HTML Converter)
    - Convierte una página HTML que contiene applets en un formato que puede utilizar el Java Plug-in.
- ARCHIVOS DE INCLUSIÓN
  - Cabeceras C de programas JNI.
- DEMOSTRACIONES
  - El directorio demo incluye varios subdirectorios que contienen código fuente de ejemplo, demostraciones, aplicaciones y applets que puede utilizar.
- COPYRIGHT
  - Aviso de copyright del software de SDK para Linux.
- LICENSE
  - El archivo LICENSE, /opt/ibm/java2-i386-50/docs/<entorno local>/license_<entorno local>.html , contiene el acuerdo de licencia del software de SDK para Linux (donde <entorno local> es el nombre de entorno local, por ejemplo, En_US). Para ver o imprimir el acuerdo de licencia, abra el archivo en un navegador Web.
- FIXES.LST
  - Un archivo de texto que describe los defectos que se han solucionado después del release inicial de esta versión.

Nota: Las guías del usuario, el Javadoc y los archivos de licencia y copyright que se adjuntan, y el directorio demo son la única documentación que se incluye en este SDK para Linux. Puede ver la documentación del software de Sun directamente en el sitio Web de Sun, o puede descargar el paquete de documentación de software de Sun del sitio Web de Sun en: http://java.sun.com.

# Instalación y configuración del SDK y Runtime Environment

Puede instalar el IBM Java SDK y Runtime Environment desde un archivo RPM o .tgz. A menos que desee que todos los usuarios de la máquina puedan acceder a esta instalación de Java, utilice el método de instalación del .tgz. Si no dispone de acceso root, utilice el archivo .tgz.

Si instala utilizando un archivo RPM, los archivos Java se instalan en /opt/ibm/java2-i386-50/. En los ejemplos de esta guía se asume que ha instalado Java en este directorio.

## Instalación en Red Hat Enterprise Linux (RHEL) 4

El SDK depende de las bibliotecas compartidas que no se instalan por omisión para Red Hat Enterprise Linux (RHEL) 4.0.

Los RPM que contienen estas bibliotecas son:

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

Para incluir estas bibliotecas durante la instalación de RHEL 4:

1. Cuando llegue a la pantalla Package Defaults (Valores por omisión del paquete), seleccione la opción Customize the set of packages to be installed (Personalizar el conjunto de paquetes a instalar).
2. En la pantalla Package Group Selection (Selección del grupo de paquetes), bajo X Windows System (Sistema X Windows), elija Details (Detalles) y asegúrese de seleccionar `xorg-x11-deprecated-libs`.
3. Bajo las opciones de Development (Desarrollo), seleccione Legacy Software Development (Desarrollo de software heredado).

| | |

## Instalación del SDK de 32 bits sobre una |arquitectura de 64 bits

|

Para ejecutar el SDK, debe instalar las versiones correctas de todas |las bibliotecas necesarias para el SDK, ya sea de 32 bits o de 64 bits.

|

En RHEL4, las versiones de 64 bits de los paquetes están disponibles en |el grupo de paquetes Compatibility Arch Support.

|

Puede utilizar la herramienta RPM para comprobar qué versiones de los |paquetes ha instalado añadiendo la opción `--queryformat |"%{NAME}.%{ARCH}\n"` al mandato RPM. Por ejemplo:

|

    /home/username : rpm --queryformat "%{NAME}.%{ARCH}\n" -q libstdc++
    |libstdc++.x86_64
    |libstdc++.i386

## Instalación desde un archivo RPM

1. Abra un indicador de shell y compruebe que es usuario root.
2. En el indicador del shell, escriba `rpm -ivh <archivo RPM>`. Por ejemplo:

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

   o bien

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

   |Donde `<arqui>` representa la |arquitectura: i386, x86_64, ppc, ppc64, s390, o s390x.

## Instalación desde un archivo .tgz

1. Cree un directorio para almacenar los archivos del paquete Java. En los ejemplos de esta guía se asume que ha instalado en /opt/ibm/java2-i386-50/. En el resto de la guía, sustituya /opt/ibm/java2-i386-50/ por el directorio en el que ha instalado Java.
2. En un indicador de shell, escriba `tar -zxvf <archivo .tgz>`. Por ejemplo:

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

   o bien

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

   |Donde `<arqui>` representa la arquitectura: i386, x86_64, ppc, |ppc64, s390, o s390x.

## Configuración del SDK y Runtime Environment para Linux

### Establecimiento de la PATH

Tenga en cuenta que, si altera la variable de entorno PATH tal como se describe a continuación, alterará temporalmente los ejecutables Java existentes en la vía de acceso.

Después de instalar el SDK, puede ejecutar una herramienta escribiendo su nombre en el indicador de shell con un nombre de archivo como argumento.

Puede especificar la vía de acceso a una herramienta escribiendo siempre la vía de acceso antes del nombre de la herramienta. Por ejemplo, si el SDK para Linux está instalado en /opt/ibm/java2-i386-50/bin, puede compilar un archivo denominado miarchivo.java escribiendo lo siguiente en un indicador de shell:

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

Para cambiar la variable de entorno PATH:

1. Edite el archivo de arranque de shell en el directorio local (normalmente .bashrc, dependiendo del shell) y añada las vías de acceso absolutas a la variable de entorno PATH; por ejemplo:

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

2. Vuelva a iniciar una sesión o ejecute el script de shell actualizado para activar el nuevo valor de PATH.

### Establecimiento de la CLASSPATH

La CLASSPATH indica a las herramientas del SDK como, por ejemplo, java, javac y javadoc, dónde se encuentran las bibliotecas de clases Java.

Sólo es necesario establecer la CLASSPATH de forma explícita en los siguientes casos:

- Si necesita un archivo de clase o de biblioteca diferente, por ejemplo, uno que haya desarrollado previamente, y no está en el directorio activo.
- Si cambia la ubicación de los directorios bin y lib de forma que ya no tienen el mismo directorio local común.
- Si tiene previsto desarrollar o ejecutar aplicaciones que utilicen entornos de tiempo de ejecución diferentes en el mismo sistema.

Para visualizar el valor actual de CLASSPATH, escriba lo siguiente en el indicador de shell:

      echo $CLASSPATH

Si tiene previsto desarrollar y ejecutar aplicaciones que utilicen entornos de tiempo de ejecución diferentes, incluido otras versiones que haya instalado por separado, debe establecer la CLASSPATH (y la PATH ) de forma explícita para cada aplicación. Si tiene previsto ejecutar varias aplicaciones simultáneamente y utilizar entornos de tiempo de ejecución diferentes, cada aplicación debe ejecutar su propio shell.

Si desea ejecutar sólo una versión de Java cada vez, puede utilizar un script de shell para conmutar entre los distintos entornos de tiempo de ejecución.

Nota:
(Sólo para usuarios de Linux IA de 32 bits chino) Debido a incoherencias en las codificaciones de fonts en Red Hat Advanced Server, cuando instala en un entorno en el que desea que el chino sea el idioma por omisión, es mejor instalar con inglés como idioma por omisión y cambiar a chino después de completarse la instalación. En caso contrario, puede que no se muestren los fonts en chino.

## Desinstalación del SDK y Runtime Environment para Linux

El proceso utilizado para eliminar el SDK y Runtime Environment para Linux dependerá del tipo de instalación que haya utilizado. Consulte Desinstalación del paquete Red Hat Package Manager (RPM) o Desinstalación del paquete comprimido Tape Archive (TAR) para obtener instrucciones.

### Desinstalación del paquete instalable Red Hat Package Manager (RPM)

Para desinstalar el SDK o Runtime Environment para Linux si ha instalado el paquete instalable RPM:

1. En el indicador del shell,
   1. Para comprobar qué paquetes RPM ha instalado, escriba:

          rpm -qa | grep -i java

   2. Verá una lista de los paquetes IBM Java que ha instalado; por ejemplo:

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

   3. Esta salida le indica qué paquetes puede desinstalar mediante el mandato `rpm -e`; por ejemplo:

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

   De forma alternativa puede utilizar una herramienta gráfica como kpackage o yast2.
2. Elimine de la sentencia PATH el directorio en el que ha instalado el SDK y Runtime Environment.
3. (Sólo Linux IA de 32 bits y PPC32) Si ha instalado el Java Plug-in, elimine los archivos del Java Plug-in del directorio del navegador Web.

### Desinstalación del paquete comprimido Tape Archive (TAR)

Para desinstalar el SDK o Runtime Environment para Linux si ha extraído el paquete TAR comprimido:

1. Elimine los archivos del SDK o Runtime Environment del directorio en el que ha instalado el SDK o Runtime Environment.
2. Elimine de la sentencia PATH el directorio en el que ha instalado el SDK o Runtime Environment.
3. Vuelva a iniciar una sesión o ejecute el script de shell actualizado para activar el nuevo valor de PATH.
4. (Sólo Linux IA de 32 bits y AMD64/EM64T) Si ha instalado el Java Plug-in, elimine los archivos del Java Plug-in del directorio del navegador Web.

# Utilización del Runtime Environment

La herramienta java inicia una aplicación Java iniciando un Java Runtime Environment y cargando una clase especificada.

La JVM busca la clase inicial (y otras clases utilizadas) en tres pasos de localización: la classpath de la rutina de carga, las extensiones instaladas y la classpath del usuario. Los argumentos que se especifiquen después del nombre de clase o nombre de archivo JAR se pasan a la función principal.

El mandato javaw es idéntico a java, excepto que javaw no tiene una ventana de consola asociada. Utilice javaw si no desea que aparezca una ventana indicadora de mandatos. El iniciador javaw muestra un recuadro de diálogo con información de error si se produce una anomalía durante el inicio.

Los mandatos java y javaw tienen la sintaxis siguiente:

    java [ opciones ] clase [ argumentos ... ]
    java [ opciones ] -jar archivo.jar [ argumentos ... ]
    javaw [ opciones ] clase [ argumentos ... ]
    javaw [ opciones ] -jar archivo.jar [ argumentos ... ]

Los elementos que aparecen entre corchetes son opcionales.

opciones
  Opciones de la línea de mandatos.
clase
  Nombre de la clase que se va a invocar.
archivo.jar
  Nombre del archivo jar que se va a invocar. Sólo se utiliza con -jar.
argumentos
  Argumentos pasados a la función main (principal).

Si se especifica la opción -jar, el archivo JAR especificado contiene los archivos de clases y recursos de la aplicación, con la clase de arranque indicada mediante la cabecera de manifiesto Main-Class (clase principal).

## Opciones

El iniciador tiene un conjunto de opciones estándar a las que el Runtime Environment da soporte actualmente y en releases futuros. Además, existe un conjunto de opciones no estándar. Las opciones por omisión se han seleccionado para el mejor uso general. Deben tenerse en cuenta las mayúsculas y minúsculas cuando se decida realizar cambios.

### Especificación de opciones Java y propiedades del sistema

Puede especificar las propiedades del sistema y las opciones de Java de tres modos distintos. En orden de prioridad, éstos modos son:

1. Mediante la especificación de la opción o propiedad en la línea de mandatos, por ejemplo`java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MiClaseJava`.
2. Mediante la creación de un archivo que contenga las opciones y la especificación de éste en la línea de mandatos utilizando -Xoptionsfile=<nombrearchivo>.
3. Mediante la creación de un variable de entorno llamada IBM_JAVA_OPTIONS que contenga las opciones, por ejemplo, `exportIBM_JAVA_OPTIONS="-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump"`.

Las opciones situadas más a la derecha de la línea de mandatos tienen prioridad sobre las opciones situadas más a izquierda; por ejemplo, si especifica las opciones `-Xint -Xjit miClase`, tendrá prioridad -Xjit.

### Opciones estándar

- -D<nombre_propiedad>=<valor>
  - Establece una propiedad de sistema.
- -assert
  - Imprime ayuda sobre opciones relacionadas con aserciones.
- -cp o -classpath <directorios y archivos zip o jar separados por :>
  - Establece la vía de acceso de búsqueda de clases y recursos de aplicaciones. Si no se utilizan -classpath y -cp, y no está establecida CLASSPATH, la classpath del usuario es, por omisión, el directorio activo (.).
- -help o -?
  - Imprime un mensaje de uso.
- -showversion
  - Imprime la versión del producto y prosigue.
- -verbose:[class,gcterse,gc,dynload,stackwalk,sizes,stack,debug,jni]
  - Habilita la salida verbosa.
- -version
  - Imprime la versión del producto.
- -version:<valor>
  - Requiere que se ejecute la versión especificada.
- -jre-restrict-search
  - Incluye los JRE privados de usuario en la búsqueda de versión
- -no-jre-restrict-search
  - Excluye JRE privados de usuario en la búsqueda de versión
- -agentlib:<nombre_bib>[=<opciones>]
  - cargue la biblioteca de agentes nativos <nombre_bib>, por ejemplo -agentlib:hprof. Para obtener más información, especifique -agentlib:jdwp=help y -agentlib:hprof=help en la línea de mandatos.
- -agentpath: nombre_bib[=<opciones>]
  - carga la biblioteca de agentes nativos por nombre de vía de acceso completo
- -javaagent:<vía_acceso_jar>[=<opciones>]
  - Carga el agente de lenguaje de programación Java; consulte la documentación de la API java.lang.instrument para obtener más información.
- -X
  - Imprime ayuda sobre las opciones no estándar.

### Opciones no estándar

Las opciones -X que se listan a continuación no son estándar y están sujetas a cambios sin previo aviso.

En las opciones del parámetro <tamaño>, debe añadir al número el sufijo "k" o "K" para indicar kilobytes, "m" o "M" para indicar megabytes, y "g" o "G" para indicar gigabytes.

- -Xargencoding
  - Permite añadir secuencias de escape Unicode en la lista de argumentos. Esta opción está desactivada por omisión.
- -Xbootclasspath:<directorios y archivos zip o jar separados por ;>
  - Establece la vía de acceso de búsqueda de clases y recursos de rutina de carga. El valor por omisión es buscar clases y recursos de rutina de carga en los directorios VM internos y en los archivos .jar.
- -Xbootclasspath/a:<directorios y archivos zip o jar separados por ;>
  - Añade los directorios, archivos zip o jar especificados al final de la classpath de la rutina de carga. El valor por omisión es buscar clases y recursos de rutina de carga en los directorios VM internos y en los archivos .jar.
- -Xbootclasspath/p:<directorios y archivos zip o jar separados por ;>
  - Pone los directorios, archivos zip o jar especificados delante de la classpath de la rutina de carga. No despliegue aplicaciones que utilicen la opción -Xbootclasspath: o -Xbootclasspath/p: para alterar una clase en la API estándar, porque el despliegue podría violar la licencia de código binario de Java 2 Runtime Environment. El valor por omisión es buscar clases y recursos de rutina de carga en los directorios VM internos y en los archivos .jar.
- -Xcheck:jni
  - Realiza comprobaciones adicionales de las funciones JNI. También puede utilizar -Xrunjnichk. Por omisión, no se realiza ninguna comprobación.
- -Xcheck:nabounds
  - Realiza comprobaciones adicionales de las operaciones JNI de matriz. También puede utilizar -Xrunjnichk. Por omisión, no se realiza ninguna comprobación.
- |-Xclassgc |
  |
  - Esta opción habilita la recopilación de objetos de clase en cada recopilación de |desechos. |Por omisión, esta opción está habilitada.
- -Xcompactexplicitgc
  - Comprimir en cada llamada a `System.gc()`. Consulte también -Xnocompactexplicitgc. Por omisión, la compactación sólo se realiza cuando se desencadena de forma interna.
- -Xcompactgc
  - Comprimir cada ciclo del recopilador de desechos. Consulte también -Xnocompactgc. Por omisión, la compactación sólo se realiza cuando se desencadena de forma interna.
- |-Xconcurrentbackground <número> |
  |
  - Esta opción especifica el número de hebras de fondo de prioridad baja conectadas |para ayudar a las hebras mutantes en la marca concurrente. El valor por omisión es 1.
- |-Xconcurrentlevel <número> |
  |
  - Esta opción especifica la cadencia del "impuesto" de asignación. Indica la |proporción entre la cantidad de almacenamiento dinámico asignado y la cantidad de |almacenamiento dinámico marcado. El valor por omisión es 8.
- |-Xconmeter:<soa | loa | dynamic> |
  |
  - Esta opción determina qué uso del área, LOA o SOA, se calibra y, por lo tanto, |qué impuestos de asignaciones se calculan durante la marca concurrente. El uso de | -Xconmeter:soa aplica el impuesto de asignación a las |asignaciones desde el área de objetos pequeños (SOA); el uso de |-Xconmeter:loa aplica el impuesto de asignación a las |asignaciones desde el área de objetos grandes (LOA). Si se especifica | -Xconmeter:dynamic, el recopilador determina dinámicamente |qué área se calibra según el área que se agote primero, ya sea la SOA o la LOA. Por omisión, la opción se establece en |-Xconmeter:soa.
- -Xdbg:<opciones>
  - Carga bibliotecas de depuración que dan soporte a la depuración remota de aplicaciones. Esta opción es la misma que -Xrunjdwp. Por omisión, las bibliotecas de depuración no están cargadas y la instancia de VM no está habilitada para la depuración.
- -Xdbginfo:<vía de acceso al archivo de símbolos>
  - Carga y pasa las opciones al servidor de información de depuración. Por omisión, el servidor de información de depuración está inhabilitado.
- -Xdebug
  - Inicia la JVM con el depurador habilitado. Por omisión, el depurador está inhabilitado.
- |-Xdisableexcessivegc |
  |
  - Esta opción inhabilita la generación de una excepción OutOfMemory si se |invierte demasiado tiempo en la GC. Por omisión, esta opción está desactivada.
- -Xdisableexplicitgc
  - Indica a la VM que las llamadas a `System.gc()` no deben tener ningún efecto. Por omisión, las llamadas a `System.gc()` desencadenan una recopilación de desechos.
- |-Xdisablestringconstantgc |
  |
  - Esta opción impide la recopilación de las series de la tabla interna de series. |Por omisión, esta opción está inhabilitada.
- -Xdisablejavadump
  - Desactiva la generación de Javadumps en el caso de errores y señales. Por omisión, la generación de Javadumps está habilitada.
- |-Xenableexcessivegc |
  |
  - Si se invierte demasiado tiempo en la GC, esta opción devuelve NULL para una |petición de asignación y, por lo tanto, genera una excepción OutOfMemory. Esta |acción se realiza sólo cuando el almacenamiento dinámico se ha expandido al máximo y |el tiempo invertido constituye como mínimo el 95%. Este es el comportamiento por |omisión.
- |-Xenablestringconstantgc |
  |
  - Esta opción habilita la recopilación de las series de la tabla interna de |series. |Por omisión, esta opción está habilitada.
- -Xfuture
  - Activa las comprobaciones estrictas de formato de archivo-clases. Utilice este distintivo cuando desarrolle código nuevo, ya que las comprobaciones más estrictas serán las comprobaciones por omisión en los próximos releases. Por omisión, las comprobaciones estrictas de formato están inhabilitadas.
- -Xgcpolicy:[optthruput]|[optavgpause]|[gencon]||[subpool] (subagrupación en PPC y zSeries)
  - Controla el comportamiento del recopilador de desechos. La opción optthruput es el valor por omisión y proporciona un rendimiento muy alto a las aplicaciones, aunque con el inconveniente de pausas ocasionales. La opción optavgpause reduce el tiempo invertido en estas pausas de recopilación de desechos, y limita el efecto de incremento del tamaño del almacenamiento dinámico en la duración de la pausa de recopilación de desechos. Utilice optavgpause si la configuración tiene un almacenamiento dinámico muy grande. La opción gencon solicita el uso combinado de GC concurrente y generacional para minimizar el tiempo invertido en una pausa de recopilación de desechos. |La opción |subpool utiliza un algoritmo mejorado de asignación de |objetos para obtener un mayor rendimiento al asignar objetos en el almacenamiento |dinámico. Esta opción puede aumentar el rendimiento en los sistemas SMP de |gran tamaño. Para obtener más información, consulte el apartado Cómo especificar una política de recopilación de desechos.
- -Xgcthreads<número de hebras>
  - Establece el número de hebras de ayuda que se utilizan para las operaciones paralelas durante la recopilación de desechos. Por omisión, el número de hebras se establece como el número de CPU físicas presentes -1, con un mínimo de 1.
- |-Xgcworkpackets <número> |
  |
  - Esta opción especifica el número total de paquetes de trabajo disponibles en |el recopilador global. Si no se especifica, el recopilador asigna un número de |paquetes basado en el tamaño del almacenamiento dinámico máximo.
- -Xint
  - Hace que la JVM utilice sólo el intérprete, e inhabilita el compilador Just-In-Time (JIT). Por omisión, el compilador JIT está habilitado.
- -Xiss<tamaño>
  - Establece el tamaño inicial de la pila de hebras Java. El valor por omisión es 2 kilobytes.
- -Xjit[:<subopción>,<subopción>,...]
  - Habilita el JIT. Para obtener más información sobre las subopciones, consulte la guía Diagnostics Guide. Consulte también -Xnojit. Por omisión, el JIT está habilitado.
- -Xlinenumbers
  - Muestra los números de línea en los rastreos de pilas, para la depuración. Consulte también -Xnolinenumbers. Por omisión, los números de línea están activados.
- |-Xloa |
  |
  - Esta opción asigna un área de objetos grandes (LOA). Los objetos se |asignarán a esta LOA en lugar de la SOA. Por omisión, la LOA está habilitada para todas las políticas de recopilación de |desechos excepto para la subagrupación, donde la LOA no está disponible. Consulte |también -Xnoloa.
- |-Xloainitial |<número> |
  |
  - <número> es un número entre 0 y 0,95, que especifica el porcentaje |inicial del espacio de permanencia actual asignado al área de objetos |grandes (LOA). El valor por omisión es 0,05 ó 5%.
- |-Xloamaximum |<número> |
  |
  - <número> es un número entre 0 y 0,95, que especifica el porcentaje |máximo del espacio de permanencia actual asignado al área de objetos |grandes (LOA). El valor por omisión es 0,5 ó 50%.
- -Xlp
  - Solicita a la JVM que asigne almacenamiento dinámico de Java con páginas grandes. Si las páginas grandes no están disponibles, la JVM no se iniciará y aparecerá el mensaje de error `GC: system configuration does not support option --> '-Xlp'`. La JVM utiliza shmget() para asignar páginas grandes para el almacenamiento dinámico. Las páginas grandes están soportadas por sistemas que ejecutan kernels de Linux V2.6 o superior, o kernels anteriores en los que la distribución ha recuperado el soporte de páginas grandes. Por omisión, no se utilizan páginas grandes. Consulte Configuración de la asignación de memoria con páginas grandes.
- -Xmaxe<tamaño>
  - Establece la cantidad máxima a la que el recopilador de desechos expande el almacenamiento dinámico. Normalmente, el recopilador de desechos expande el almacenamiento dinámico cuando la cantidad de espacio libre es menor del 30% (o la cantidad especificada utilizando -Xminf) a la cantidad necesaria para restaurar el espacio libre al 30%. La opción -Xmaxe limita la expansión al valor especificado; por ejemplo, `-Xmaxe10M` limita la expansión a 10 MB. Por omisión, no hay ningún tamaño de expansión máximo.
- -Xmaxf<tamaño>
  - Especifica el porcentaje máximo de almacenamiento dinámico que debe quedar libre después de una recopilación de desechos. Si el espacio libre sobrepasa esta cantidad, la JVM intenta mermar el almacenamiento dinámico. Especifique el tamaño como un valor decimal en el rango del 0 al 1, por ejemplo `-Xmaxf0,5` establece el espacio libre máximo en el 50%. El valor por omisión es 0,6 (60%).
- -Xmca<tamaño>
  - Establece el paso de expansión de la memoria asignada para almacenar la parte de RAM de las clases cargadas. Cada vez que se necesita más memoria para almacenar clases en la RAM, la memoria asignada se aumenta en esta cantidad. Por omisión, el paso de expansión es 32K.
- -Xmco<tamaño>
  - Establece el paso de expansión de la memoria asignada para almacenar la parte de ROM de las clases cargadas. Cada vez que se necesita más memoria para almacenar clases en la ROM, la memoria asignada se aumenta en esta cantidad. Por omisión, el paso de expansión es 128 K.
- -Xmine<tamaño>
  - Establece la cantidad mínima a la que el recopilador de desechos expande el almacenamiento dinámico. Normalmente, el recopilador de desechos expande el almacenamiento dinámico a la cantidad necesaria para restaurar el espacio libre al 30% (o a la cantidad especificada utilizando -Xminf). La opción -Xmine establece la expansión para que sea como mínimo el valor especificado; por ejemplo, `-Xmine50M` establece el tamaño de expansión a un mínimo de 50 MB. Por omisión, el tamaño mínimo de expansión es 1 MB.
- -Xminf<tamaño>
  - Especifica el porcentaje mínimo de almacenamiento dinámico que debe quedar libre después de una recopilación de desechos. Si el espacio libre es menor de esta cantidad, la JVM intenta expandir el almacenamiento dinámico. Especifique el tamaño como un valor decimal en el rango del 0 al 1; por ejemplo, un valor `-Xminf0.3` solicita que el espacio libre mínimo sea el 30% del almacenamiento dinámico. Por omisión, el valor mínimo es 0.3.
- -Xmn<tamaño>
  - Establece el tamaño máximo e inicial del nuevo almacenamiento dinámico (cantera) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. Es equivalente a establecer -Xmns y -Xmnx conjuntamente. |Si establece -Xmns o -Xmnx, no puede establecer -Xmn. Si intenta |establecer -Xmn con -Xmns o -Xmnx, la VM no se iniciará y devolverá un error. Por omisión, -Xmn se selecciona de forma interna según la capacidad del sistema. Puede utilizar la opción -verbose:sizes para averiguar los valores que utiliza actualmente la VM.
- -Xmns<tamaño>
  - Establece el tamaño inicial del nuevo almacenamiento dinámico (cantera) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. Por omisión, esta opción se selecciona de forma interna según la capacidad del sistema. |Esta opción devolverá un error si intenta |utilizarla con -Xmn.
- -Xmnx<tamaño>
  - Establece el tamaño máximo del nuevo almacenamiento dinámico (cantera) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. Por omisión, esta opción se selecciona de forma interna según la capacidad del sistema. |Esta opción devolverá un error si intenta |utilizarla con -Xmn.
- -Xmo<tamaño>
  - Establece el tamaño máximo e inicial del almacenamiento dinámico antiguo (permanencia) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. Es equivalente a establecer -Xmos y -Xmox conjuntamente. |Si establece -Xmos o -Xmox, |no puede establecer -Xmo. Si |intenta establecer -Xmo con -Xmos o |-Xmox, la VM no se iniciará y devolverá un error. Por omisión, -Xmo se selecciona de forma interna según la capacidad del sistema. Puede utilizar la opción -verbose:sizes para averiguar los valores que utiliza actualmente la VM.
- -Xmos<tamaño>
  - Establece el tamaño inicial del almacenamiento dinámico antiguo (permanencia) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. Por omisión, esta opción se selecciona de forma interna según la capacidad del sistema. |Esta opción devolverá un error si intenta |utilizarla con -Xmo.
- -Xmox<tamaño>
  - Establece el tamaño máximo del almacenamiento dinámico antiguo (permanencia) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. Por omisión, esta opción se selecciona de forma interna según la capacidad del sistema. |Esta opción devolverá un error si intenta |utilizarla con -Xmo.
- -Xmoi<tamaño>
  - Establece qué cantidad de almacenamiento dinámico de Java se aumenta cuando se utiliza -Xgcpolicy:gencon. Si establece en cero, no se permite ninguna expansión. Por omisión, el tamaño de incremento se calcula según el tamaño de expansión, -Xmine y -Xminf.
- -Xmr<tamaño>
  - Establece el tamaño del "conjunto recordado" de la recopilación de desechos cuando se utiliza -Xgcpolicy:gencon. Es una lista de objetos en el almacenamiento dinámico antiguo (permanencia) que incluyen referencias a objetos en el almacenamiento dinámico nuevo (cantera). Por omisión, esta opción se establece en 16 kilobytes.
- -Xms<tamaño>
  - Establece el tamaño inicial del almacenamiento dinámico de Java. También puede utilizar -Xmo. El valor por omisión se establece de forma interna según la capacidad del sistema.
- -Xmso<tamaño>
  - Establece el tamaño de pila C para las hebras Java bifurcadas. Por omisión, esta opción se establece en 32 kilobytes para las plataformas de 32 bits y en 256 kilobytes para las plataformas de 64 bits.
- -Xmx<tamaño>
  - Establece el tamaño máximo del almacenamiento dinámico de Java. Por omisión, esta opción se establece de forma interna según la capacidad del sistema.
- -Xnoclassgc
  - Inhabilita la recopilación de desechos de clase. Desactiva la recopilación de desechos del almacenamiento asociado con las clases Java que ya no utiliza la JVM. El comportamiento por omisión es -Xclassgc.
- -Xnocompactgc
  - Inhabilita la compactación del recopilador de desechos. Consulte también -Xcompactgc. Por omisión, la compactación está habilitada.
- -Xnocompactexplicitgc
  - Inhabilita la compactación en una llamada a `System.gc()`. Consulte también -Xcompactexplicitgc. Por omisión, la compactación está habilitada en las llamadas a `System.gc()`.
- -Xnojit
  - Inhabilita el compilador JIT. Consulte también -Xjit. Por omisión, el compilador JIT está habilitado.
- -Xnolinenumbers
  - Inhabilita los números de línea para la depuración. Consulte también -Xlinenumbers. Por omisión, los números de línea están activados.
- |-Xnoloa |
  |
  - Esta opción impide la asignación de un área de objetos grandes (LOA). |Todos los objetos se asignarán en la SOA. Por omisión, la LOA está habilitada para todas las políticas de recopilación de |desechos excepto para la subagrupación, donde la LOA no está disponible. Consulte |también -Xloa.
- -Xnopartialcompactgc
  - Inhabilita la compactación incremental. Consulte también -Xpartialcompactgc. Por omisión, esta opción no está establecida, por lo que todas las compactaciones son completas.
- -Xnosigcatch
  - Inhabilita el código de manejo de señales de la JVM. Consulte también -Xsigcatch. Por omisión, el manejo de señales está habilitado.
- -Xnosigchain
  - Inhabilita el encadenamiento de manejadores de señales. Consulte también -Xsigchain. Por omisión, el encadenamiento de manejadores de señales está habilitado.
- -Xoptionsfile=<archivo>
  - Especifica un archivo que contiene opciones y definiciones de JVM. Por omisión, no se utiliza ningún archivo de opciones.
- -Xoss<tamaño>
  - Establece el tamaño de pila Java y el tamaño de pila C para cualquier hebra. Esta opción se facilita por razones de compatibilidad y es equivalente a establecer -Xss -Xmso en el valor especificado.
- -Xpartialcompactgc
  - Habilita la compactación parcial. Consulte también -Xnopartialcompactgc.
- -Xquickstart
  - Mejora el tiempo de arranque retardando las optimizaciones y la compilación de JIT. Por omisión, el arranque rápido está inhabilitado y no existe ningún retardo en la compilación de JIT.
- -Xrdbginfo:<sistema principal>:<puerto>
  - Carga y pasa las opciones al servidor de información de depuración remoto. Por omisión, el servidor de información de depuración remoto está inhabilitado.
- -Xrs
  - Reduce el uso de señales del sistema operativo. Por omisión, la VM realiza un uso completo de las señales del sistema operativo; consulte el apartado Señales utilizadas por la JVM .
- -Xrun<nombre de biblioteca>[:opciones]
  - Carga las bibliotecas de ayuda. Para cargar varias bibliotecas, especifíquelas más de una vez en la línea de mandatos. Ejemplos de estas bibliotecas son:
    - -Xrunhprof[:help] | [:<opción>=<valor>, ...]
      - Lleva a cabo una definición de perfil de almacenamiento dinámico, CPU o monitor. Para obtener más información, consulte la guía Diagnostics Guide.
    - -Xrunjdwp[:help] | [:<opción>=<valor>, ...]
      - Carga bibliotecas de depuración que dan soporte a la depuración remota de aplicaciones. Esta opción es la misma que -Xdbg. Para obtener más información, consulte el apartado Depuración de aplicaciones Java.
    - -Xrunjnichk[:help] | [:<opción >=<valor>, ...]
      - Realiza comprobaciones adicionales de las funciones JNI, para rastrear errores en los programas nativos que acceden a la JVM utilizando JNI. Para obtener más información, consulte la guía Diagnostics Guide.
- |-Xscmx<tamaño>[k|m|g] |
  |
  - Para obtener más información sobre -Xscmx, consulte el |apartado Utilización de las opciones de la línea de mandatos para el compartimiento de |clases.
- |-Xshareclasses:<subopciones> |
  |
  - Para obtener más información sobre las subopciones de |-Xshareclasses, consulte el apartado |Utilización de las opciones de la línea de mandatos para el compartimiento de |clases.
- -Xsigcatch
  - Habilita el código de manejo de señales de la VM. Consulte también -Xnosigcatch. Por omisión, el manejo de señales está habilitado.
- -Xsigchain
  - Habilita el encadenamiento de manejadores de señales. Consulte también -Xnosigchain. Por omisión, el encadenamiento de manejadores de señales está habilitado.
- |-Xsoftrefthreshold<número> |
  |
  - Esta opción establece el número de GC después del cual se borrará una referencia |de software si no se ha marcado su referente. El valor por omisión es 3, lo que |significa que a la tercera GC en la que no se marque el referente, se borrará la |referencia de software.
- -Xss<tamaño>
  - Establece el tamaño máximo de pila de Java para cualquier hebra. Por omisión, esta opción se establece en 256 KB.Para obtener más información, consulte el apartado Trabajo con pilas flotantes.
- -Xthr:<opciones>
  - Establece las opciones de hebra.
- -Xverbosegclog:<vía de acceso del archivo><nombre de archivo>[X, Y]
  - Hace que la salida de verboseGC se escriba en el archivo especificado. Si el archivo existe, se escribe encima de él. En caso contrario, si no puede abrirse un archivo existente o no puede crearse un nuevo archivo, la salida se redirige a stderr. Si especifica los argumentos X e Y (ambos son enteros) la salida de verboseGC se redirige a un número X de archivos, conteniendo cada uno un número Y de ciclos de gc de la salida de verboseGC. Estos archivos tienen el formato nombrearchivo1, nombrearchivo2, etc. Por omisión, no se realiza ningún registro cronológico de recopilación de desechos verboso.
- -Xverify
  - Habilita la comprobación estricta de clases para todas las clases que se carguen. Por omisión, la comprobación estricta de clases está inhabilitada.
- -Xverify:none
  - Inhabilita la comprobación estricta de clases. Por omisión, la comprobación estricta de clases está inhabilitada.

## Obtención del número de versión y de nivel de compilación de IBM

Para obtener el número de versión y de nivel de compilación de IBM, en el indicador de shell escriba:

    java -version

## Globalización del mandato java

El mandato java y otros mandatos del iniciador java (como javaw) permiten especificar un nombre de clase con cualquier carácter que esté en el juego de caracteres del entorno local actual.

También puede especificar cualquier carácter Unicode en el nombre de clase y argumentos utilizando secuencias de escape Java. Para hacerlo, debe especificar -Xargencoding. Para especificar un carácter Unicode, utilice secuencias de escape con el formato `\u####`, donde # es un dígito hexadecimal (0 a 9, A a F).

De forma alternativa, para especificar que el nombre de clase y los argumentos del mandato están en codificación UTF8, utilice -Xargencoding:utf8, o en la codificación ISO8859_1, utilice -Xargencoding:latin.

Por ejemplo, para especificar una clase denominada "HelloWorld" utilizando la codificación Unicode para las dos letras mayúsculas, utilice este mandato:

    java -Xargencoding '\u0048ello\u0057orld'

Los mandatos java y javaw proporcionan mensajes de salida traducidos. Estos mensajes difieren según el entorno local en el que se ejecute Java. Las descripciones de error y otra información de depuración devuelta por java están en inglés.

## Compilador Just-In-Time (JIT)

El compilador Just-In-Time (JIT) de IBM genera dinámicamente el código máquina utilizado con frecuencia por secuencias de código de bytes en aplicaciones o applets Java durante su ejecución. |El |compilador JIT V5.0 proporciona nuevas optimizaciones como resultado de |las investigaciones del compilador, mejora las optimizaciones |implementadas en las versiones anteriores de JIT y proporciona un mayor |aprovechamiento del hardware.

El IBM SDK y el Runtime Environment incluyen el JIT, que está habilitado por omisión. Generalmente, no es necesario invocar el JIT explícitamente, ya que la compilación de código de bytes Java a código de máquina ocurre de forma transparente. No obstante, si tiene problemas con el Runtime Environment al ejecutar una aplicación Java o un applet, puede inhabilitar el JIT para aislar el problema. La inhabilitación del JIT sólo debe ser una medida temporal; éste es necesario para un rendimiento adecuado.

### Inhabilitación del JIT

Existen tres modos de inhabilitar el JIT:

- Establezca la variable de entorno JAVA_COMPILER en "NONE" o en la hebra vacía antes de ejecutar la aplicación Java.

  Escriba lo siguiente en el indicador de mandatos:

  1. Para el shell de Korn:

     -         export JAVA_COMPILER=NONE

       (En el resto de esta Guía del usuario se utilizan mandatos de shell de Korn.)

  2. Para el shell de Bourne:

     -     JAVA_COMPILER=NONE

     -     export JAVA_COMPILER

  3. Para el shell de C:

     -     setenv JAVA_COMPILER NONE

- Utilice la opción -D en la línea de mandatos de la JVM para establecer la propiedad java.compiler en "NONE" o en la serie vacía:

      java -Djava.compiler=NONE MiApli

- Utilice la opción -Xint en la línea de mandatos de la JVM. Por ejemplo:

      java -Xint MiApli

Ambas opciones de la línea de mandatos alteran temporalmente la variable de entorno JAVA_COMPILER.

### Habilitación del JIT

Para habilitar el JIT explícitamente, establezca la variable de entorno JAVA_COMPILER en "jitc" o utilice la opción -D para establecer la propiedad java.compiler property en "jitc". Alternativamente, utilice la opción -Xjit (y omita la opción -Xint) en la línea de mandatos de la JVM para activar el JIT.

Si la variable de entorno JAVA_COMPILER o la propiedad java.compiler se establecen en "" (la serie vacía), el JIT permanece inhabilitado. Para desestablecer la variable de entorno adecuadamente, escriba `unset JAVA_COMPILER` en el indicador de shell.

### Cómo determinar si el JIT está habilitado

Para determinar si el JIT está habilitado, escriba lo siguiente en un indicador de mandatos:

    java -version

Si el JIT no se está utilizando, aparece un mensaje que incluye lo siguiente:

    (JIT disabled)

Si el JIT se está utilizando, aparece un mensaje que incluye lo siguiente:

    (JIT enabled)

Para obtener más información sobre el JIT, consulte la guía Diagnostics Guide.

## Cómo especificar una política de recopilación de desechos

El recopilador de desechos gestiona la memoria utilizada por Java y las aplicaciones que se ejecutan en la VM.

Cuando el recopilador de desechos recibe una solicitud de almacenamiento, la memoria no utilizada en el almacenamiento dinámico se define aparte: "asignación". El recopilador de desechos también busca áreas de memoria a las que ya no se haga referencia, y las libera para que se puedan reutilizar: "recopilación".

La fase de recopilación puede desencadenarla un error de asignación de memoria, que se produce cuando no queda espacio para una solicitud de almacenamiento, o una llamada explícita a System.gc().

La recopilación de desechos puede afectar significativamente al rendimiento de la aplicación, por lo que la máquina virtual IBM ofrece varios métodos para optimizar la recopilación de desechos y reducir de esta forma el efecto en la aplicación.

Para obtener información más detallada sobre la recopilación de desechos, consulte la guía Diagnostics Guide.

### Opciones de recopilación de desechos

La opción -Xgcpolicy especifica la política de recopilación de desechos.

-Xgcpolicy toma los valores optthruput (el valor por omisión y el recomendado), optavgpause|, subpool| (sólo para PPC y zSeries ) o gencon. La opción controla el comportamiento del recopilador de desechos, realizando intercambios entre la salida de la aplicación y el sistema en general y los tiempos de pausa provocados por la recopilación de desechos.

El formato de la opción y sus valores son:

> -Xgcpolicy:optthruput

> -Xgcpolicy:optavgpause

> -Xgcpolicy:gencon

|

> -Xgcpolicy:subpool (sólo para PPC y zSeries)

### Tiempo de pausa

Cuando un intento de una aplicación de crear un objeto no se puede cumplir inmediatamente con el espacio disponible en el almacenamiento dinámico, corresponde al recopilador de desechos identificar los objetos sin referencia (desechos), suprimirlos y devolver el almacenamiento dinámico a un estado en el que las peticiones de asignación inmediatas y posteriores se puedan satisfacer rápidamente. Estos ciclos de recopilación de desechos provocan pausas inesperadas ocasionales en la ejecución del código de la aplicación. Como el tamaño y la complejidad de las aplicaciones aumenta y los almacenamientos dinámicos crecen en consecuencia, este tiempo de pausa de recopilación de desechos tiende a aumentar en duración e importancia. El valor por omisión de la recopilación de desechos, -Xgcpolicy:optthruput, proporciona una salida muy alta para las aplicaciones, pero al coste de estas pausas ocasionales, que pueden variar de unos pocos milisegundos a varios segundos, en función del tamaño del almacenamiento dinámico y la cantidad de desechos.

### Reducción del tiempo de pausa

La JVM utiliza dos técnicas para reducir los tiempos de pausa:

- Recopilación de desechos concurrente
- Recopilación de desechos generacional

La opción de línea de mandatos -Xgcpolicy:optavgpause solicita el uso de la recopilación de desechos concurrente para reducir significativamente el tiempo invertido en las pausas de recopilación de desechos. La GC concurrente reduce el tiempo de pausa mediante la realización de actividades de recopilación de desechos de forma concurrente durante la ejecución normal del programa, para minimizar la interrupción provocada por la recopilación del almacenamiento dinámico. La opción -Xgcpolicy:optavgpause también limita el efecto de aumentar el tamaño de almacenamiento dinámico en la duración de la pausa de recopilación de desechos. La opción -Xgcpolicy:optavgpause es muy útil en configuraciones con grandes almacenamientos dinámicos. Con el tiempo de pausa reducido, puede experimentarse alguna reducción en el rendimiento de las aplicaciones.

Durante la recopilación de desechos concurrente, se invierte una cantidad importante de tiempo en la identificación de objetos de duración relativamente larga que no se pueden recopilar. Si la GC se concentra sólo en aquellos objetos con más probabilidad de reciclarse, podrá reducir aún más los tiempos de pausa de algunas aplicaciones. Esto es lo que hace la GC generacional al reducir el almacenamiento dinámico en dos "generaciones": las áreas de "cantera" y de "permanencia". Los objetos se colocan en una de estas áreas dependiendo de su antigüedad. La cantera es la menor de las dos y contiene los objetos más jóvenes; la permanencia es mayor y contiene los objetos más antiguos. Los objetos se asignan primero a la cantera; si sobreviven lo suficiente, al final pasan al área de permanencia.

La GC generacional depende que la mayoría de los objetos no duren mucho. La GC generacional reduce los tiempos de pausa al concentrar el trabajo en reclamar el almacenamiento en la cantera, ya que tiene el espacio más reciclable. En lugar de tiempos de pausa ocasionales pero largos para recopilar todo el almacenamiento dinámico, se recopila la cantera con más frecuencia y, si la cantera es lo suficientemente pequeña, los tiempos de pausa son comparativamente cortos. No obstante, la GC generacional tiene el inconveniente de que, con el tiempo, el área de permanencia puede llenarse si muchos objetos duran demasiado tiempo. Si esto ocurre, para minimizar el tiempo de pausa, utilice una combinación de GC concurrente y GC generacional. La opción -Xgcpolicy:gencon solicita el uso combinado de GC concurrente y generacional para minimizar el tiempo invertido en una pausa de recopilación de desechos.

### Entornos con almacenamientos dinámicos muy llenos

Si el almacenamiento dinámico de Java está casi lleno y hay muy pocos desechos que recopilar, es posible que las peticiones de objetos nuevos no se puedan satisfacer rápidamente ya que no hay espacio disponible inmediatamente. Si se trabaja con un almacenamiento dinámico casi lleno, el rendimiento de las aplicaciones puede resentirse sin importar cuál de las opciones anteriores se usa y, si se siguen realizando peticiones de más espacio de almacenamiento dinámico, la aplicación recibe una excepción OutofMemory, que provoca la interrupción de la JVM si esta excepción no se detecta y gestiona. En este punto, la JVM produce un archivo de diagnóstico "javadump". En estas condiciones, se recomienda incrementar el tamaño del almacenamiento dinámico mediante la opción -Xmx o reducir el número de objetos de aplicación en uso. Para obtener más información, consulte la guía Diagnostics Guide.

## Cómo procesa las señales la JVM

Cuando se activa una señal que resulta interesante para la JVM, se llama a un manejador de señales. Este manejador de señales determina si ha sido llamado por una hebra Java o no Java.

Si la señal es de una hebra Java, la JVM toma el control del manejo de la señal. Si se ha instalado un manejador de aplicaciones para esta señal y no ha especificado la opción de línea de mandatos -Xnosigchain, cuando la JVM haya finalizado el proceso, se llamará al manejador de aplicaciones de esta señal.

Si la señal es de una hebra no Java y la aplicación que ha instalado la JVM ha instalado previamente su propio manejador de señales, se pasa el control a ese manejador. De lo contrario, si la JVM o la aplicación Java solicitan la señal, se ignorará la señal o se realizará la acción por omisión.

Para señales de excepción y de error, la JVM:

- Maneja la condición y se recupera, o
- Entra en una secuencia de conclusión controlada en la que:
  1. Lleva a cabo la salida de un Javadump para describir el estado de la JVM en el momento de la anomalía
  2. Llama al manejador de señales de la aplicación que corresponde a esa señal
  3. Llama a cualquier enganche de terminación anormal instalado por la aplicación
  4. Realiza la limpieza necesaria para proporcionar una conclusión limpia

Para obtener información sobre cómo escribir un iniciador que especifique los enganches anteriores, consulte: http://www-106.ibm.com/developerworks/java/library/i-signalhandling/. Este artículo se ha escrito para Java V1.3.1, pero también se aplica a versiones posteriores.

En el caso de las señales de interrupción, la JVM también entra en una secuencia de conclusión controlada, pero esta vez se trata como una terminación normal que:

- Llama al manejador de señales de la aplicación que corresponde a esa señal
- Ejecuta todos los enganches de conclusión de la aplicación
- Llama a cualquier enganche de salida instalado por la aplicación
- Realiza la limpieza necesaria de la JVM

La conclusión es idéntica a la conclusión iniciada por una llamada al método Java `System.exit()`.

Otras señales utilizadas por la JVM son para temas de control interno y no hacen que termine. La única señal de control interesante es SIGQUIT, que hace que se genere un Javadump.

### Señales utilizadas por la JVM

La Tabla 1 siguiente muestra las señales utilizadas por la JVM. Las señales se agrupan en la tabla por tipo o utilización, de la forma siguiente:

- Excepciones: el sistema operativo lanza de forma síncrona una señal de excepción apropiada cada vez que se produce una condición muy grave.
- Errores: la JVM lanza una SIGABRT si detecta una condición de la que no se puede recuperar.
- Interrupciones: las señales de interrupción se lanzan de forma asíncrona, desde fuera de un proceso de JVM, para solicitar la conclusión.
- Controles: otras señales utilizadas por la JVM para temas de control.

Tabla 1. Señales utilizadas por la JVM
Nombre de señal | Tipo de señal | Descripción | Inhabilitada por -Xrs
--- | --- | --- | ---
SIGBUS | Excepción | Acceso incorrecto a la memoria (desalineación de datos) | Sí
SIGSEGV | Excepción | Acceso incorrecto a la memoria (escritura en memoria inaccesible) | Sí
SIGILL | Excepción | Instrucción no permitida (intento de invocar una instrucción de máquina desconocida) | No
SIGFPE | Excepción | Excepción de coma flotante (división por cero) | Sí
SIGABRT | Error | Terminación anormal. La JVM lanza esta señal cada vez que detecta una anomalía en la JVM. | Sí
SIGINT | Interrupción | Atención interactiva (Control-C). La JVM sale normalmente. | Sí
SIGTERM | Interrupción | Petición de terminación. La JVM saldrá normalmente. | Sí
SIGHUP | Interrupción | Cortar. La JVM sale normalmente. | Sí
SIGQUIT | Control | Señal de salida para un terminal. La JVM utiliza esto para tomar Javadumps. | Sí
|SIGTRAP (5) | |Control | |Utilizada por el JIT. | |Sí
|__SIGRTMAX - 2 | |Control | |Utilizada por el SDK. | |No
|SIGCHLD | |Control | |Utilizada por el SDK para el control interno. | |No

Utilice la opción -Xrs (reducir el uso de señales) para evitar que la JVM maneje la mayoría de señales. Para obtener más información, consulte la página del iniciador de aplicaciones de Java de Sun en http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.

Las señales `1 (SIGHUP)`, `2 (SIGINT)`, `4 (SIGILL)`, `7 (SIGBUS)`, `8 (SIGFPE)`, `11 (SIGSEGV)` y `15 (SIGTERM)` en las hebras de JVM hacen que la JVM concluya; por lo tanto, un manejador de señales de la aplicación no debería intentar recuperarse de estas situaciones a menos que ya no necesite la JVM.

### Enlace de un controlador de código nativo con la biblioteca de encadenamiento de señales

El Runtime Environment contiene un encadenamiento de señales. El encadenamiento de señales permite a la JVM interoperar de forma más eficaz con el código nativo que instala sus propios manejadores de señales.

El encadenamiento de señales permite a la aplicación enlazar y cargar la biblioteca compartida libjsig.so antes que las bibliotecas del sistema. La biblioteca libjsig.so garantiza que llamadas como `signal()`, `sigset()` y `sigaction()` sean interceptadas para que sus manejadores no sustituyan a los manejadores de señales de la JVM. En su lugar, estas llamadas guardan los nuevos manejadores de señales o los "encadenan" detrás de los manejadores instalados por la JVM. Más tarde, cuando se lance alguna de estas señales y se determine que no está destinada a la JVM, se invocarán los manejadores preinstalados.

Para utilizar libjsig.so:

- Enlácela con la aplicación que crea o incorpora la JVM:

      gcc -L$JAVA_HOME/bin -ljsig -L$JAVA_HOME/bin/j9vm -ljvm aplicación_java.c

  o bien
- Utilice la variable de entorno LD_PRELOAD:

      export
      LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; aplicación_java (bash y ksh)

      setenv LD_PRELOAD=$JAVA_HOME/bin/libjsig.so; aplicación_java (csh)

  (Asumiendo que `JAVA_HOME` esté configurada; en caso contrario, utilice /opt/ibm/java2-i386-50/jre.)

Si instala manejadores de señales que utilizan `sigaction()`, algunos sa_flags no se observan cuando la JVM utiliza la señal. Estos son:

- SA_NOCLDSTOP - Siempre sin establecer.
- SA_NOCLDWAIT - Siempre sin establecer.
- SA_RESTART - Siempre establecido.

La biblioteca libjsig.so oculta también los manejadores de señales de la JVM de la aplicación. Por lo tanto, llamadas como `signal()`, `sigset()` y `sigaction()` realizadas después de iniciarse la JVM ya no devuelven una referencia al manejador de señales de la JVM y en su lugar devuelven cualquier manejador que haya sido instalado antes del inicio de la JVM.

## Trabajo con pilas flotantes

Algunas distribuciones de Linux (Red Hat, por ejemplo) tienen habilitada una característica GLIBC denominada 'pilas flotantes'. Debido a las limitaciones del kernel de Linux, la JVM no funciona en hardware SMP con pilas flotantes habilitadas si el nivel del kernel es menor de 2.4.10. En este entorno, las pilas flotantes deben inhabilitarse antes de que se inicie la JVM o cualquier aplicación que inicie la JVM. En Red Hat, utilice este mandato para inhabilitar las pilas flotantes exportando una variable de entorno:

    export LD_ASSUME_KERNEL=2.2.5

En un sistema Linux de pilas no flotantes, independientemente de lo que se establezca para -Xss, se proporciona un tamaño mínimo de pilas nativas de 256 KB para cada hebra. En un sistema Linux de pilas flotantes, se respetan los valores de -Xss. Por lo tanto, si realiza la migración de un sistema Linux sin pilas flotantes, debe comprobar que los valores de -Xss son lo bastante grandes y que no se basan en el mínimo de 256 KB.

## Transformación de documentos XML

IBM SDK contiene el procesador XSLT4J y el analizador XML4J que cumplen la especificación JAXP 1.3. Estas herramientas permiten analizar y transformar documentos XML independientemente de la implementación de proceso XML específica. Al utilizar "Factory Finders" (Buscadores de fábricas) para ubicar las implementaciones de SAXParserFactory, DocumentBuilderFactory y TransformerFactory, la aplicación puede cambiar entre las distintas implementaciones sin necesidad de modificar ningún código.

|La tecnología XML incluida en el IBM SDK es similar a |Apache Xerces Java y Apache Xalan Java. Consulte | http://xml.apache.org/xerces2-j/ y |http://xml.apache.org/xalan-j/ para obtener |más información.

El procesador XSLT4J permite elegir entre el procesador XSLT Interpretive original o el nuevo procesador XSLT Compiling. El procesador Interpretive está diseñado para entornos de herramientas y depuración, y da soporte a las funciones de ampliación XSLT que no están soportadas por el procesador XSLT Compiling. El procesador XSLT Compiling está diseñado para entornos de tiempo de ejecución de alto rendimiento; genera un motor de transformación, o translet, desde una hoja de estilo XSL. Este enfoque separa la interpretación de las instrucciones de la hoja de estilo de su aplicación de tiempo de ejecución en datos XML.

El procesador XSLT Interpretive es el procesador por omisión. Para seleccionar el procesador XSLT Compiling, puede:

- Cambiar la entrada en el archivo jaxp.properties (ubicado en /opt/ibm/java2-i386-50/jre/lib), o bien
- Establecer la propiedad del sistema de la clave javax.xml.transform.TransformerFactory en org.apache.xalan.xsltc.trax.TransformerFactoryImpl.

Para implementar las propiedades del archivo jaxp.properties, copie jaxp.properties.sample en jaxp.properties, en /opt/ibm/java2-i386-50/. Este archivo también contiene información detallada completa sobre el procedimiento utilizado para determinar qué implementaciones se deben utilizar para TransformerFactory, SAXParserFactory y DocumentBuilderFactory.

Para aumentar el rendimiento cuando se transforma un objeto StreamSource con el procesador XSLT Compiling, especifique la clase com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager como el proveedor del servicio org.apache.xalan.xsltc.dom.XSLTCDTMManager. Para determinar el proveedor de servicios, pruebe cada uno de estos pasos hasta que encuentre org.apache.xalan.xsltc.dom.XSLTCDTMManager:

1. Compruebe el valor de la propiedad del sistema org.apache.xalan.xsltc.dom.XSLTCDTMManager.
2. Compruebe el valor de la propiedad org.apache.xalan.xsltc.dom.XSLTCDTMManager en el archivo /opt/ibm/java2-i386-50/lib/xalan.properties.
3. Compruebe el contenido del archivo META-INF/services/org.apache.xalan.xsltc.dom.XSLTCDTMManager para un nombre de clase.
4. Utilice el proveedor de servicios por omisión, org.apache.xalan.xsltc.dom.XSLTCDTMManager.

El procesador XSLT Compiling detecta el proveedor de servicios del servicio org.apache.xalan.xsltc.dom.XSLTCDTMManager cuando se crea un objeto javax.xml.transform.TransformerFactory. Los objetos javax.xml.transform.Transformer o javax.xml.transform.sax.TransformerHandler que se crean utilizando ese objeto TransformerFactory utilizarán el mismo proveedor de servicios. Sólo puede cambiar los proveedores de servicio si modifica uno de los valores descritos anteriormente y, a continuación, crea un nuevo objeto TransformerFactory.

### Utilización de una versión anterior de Xerces o Xalan

Si utiliza una versión anterior de Tomcat, puede aplicarse esta limitación.

Si utiliza una versión anterior de Xerces (previa a 2.0) o Xalan (previa a 2.3) en la alteración confirmada, puede obtener una excepción de puntero nulo cuando ejecute la aplicación. Esta excepción se produce porque las versiones anteriores no manejan correctamente el archivo jaxp.properties.

Para evitar este problema, utilice una de las siguientes soluciones provisionales:

- Actualice a una versión más reciente de la aplicación que implemente la última especificación JAXP (Java API for XML Programming) (http://java.sun.com/xml/jaxp/index.html).
- Elimine el archivo jaxp.properties de /opt/ibm/java2-i386-50/jre/lib.
- Descomente las entradas en el archivo jaxp.properties en /opt/ibm/java2-i386-50/jre/lib.
- Establezca explícitamente el analizador SAX, el DocumentBuilder o la fábrica de transformadores utilizando la variable de entorno IBM_JAVA_OPTIONS. Por ejemplo:

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

  o bien

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

  o bien

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

- Establezca la propiedad de sistema de javax.xml.parsers.SAXParserFactory , javax.xml.parsers.DocumentBuilderFactory o javax.xml.transform.TransformerFactory desde el código de la aplicación. Para ver un ejemplo, consulte la especificación JAXP 1.3.

# Utilización del SDK para desarrollar aplicaciones Java

En los siguientes apartados se proporciona información sobre el uso del SDK para Linux para desarrollar aplicaciones Java. Consulte el apartado Herramientas del SDK para obtener información detallada sobre las herramientas disponibles.

## Depuración de aplicaciones Java

Para depurar programas Java, puede utilizar la aplicación Depurador Java (JDB) u otros depuradores que se comuniquen utilizando la JPDA (Java Platform Debugger Architecture) que se proporciona con el SDK para Linux.

### Depurador Java (JDB)

El Depurador Java (JDB) se incluye en el SDK para Linux. El depurador se invoca utilizando el mandato jdb; se "conecta" a la JVM mediante JPDA. Para depurar una aplicación Java:

1. Inicie la JVM con las siguientes opciones:

       java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<puerto>
            MyApp <argumentos de MiApl>

2. La JVM se inicia, pero suspende la ejecución antes de iniciar la aplicación Java. En una sesión aparte, puede conectar el depurador a la JVM:

       jdb -attach <número de puerto>

   El depurador se conectará a la JVM y ya puede emitir una amplia gama de mandatos para examinar y controlar la aplicación Java; por ejemplo, escriba `run` para ejecutar la aplicación Java.

Para obtener más información sobre las opciones de JDB, escriba:

    jdb -help

Para obtener más información sobre los mandatos de JDB:

1. Escriba `jdb`
2. En el indicador de jdb, escriba `help`

También puede utilizar JDB para depurar aplicaciones Java que se estén ejecutando en máquinas remotas. JDPA utiliza un socket TCP/IP para conectarse a la JVM remota.

1. Inicie la JVM como anteriormente.
2. Conecte el depurador a la máquina remota:

       jdb -attach <nombre de máquina o dirección ip>:<número de
       puerto>

Cuando inicie una sesión de depuración utilizando el transporte dt_socket, asegúrese de que los puertos especificados estén libres para su uso.

|Java Virtual Machine Debugging Interface (JVMDI) |no está soportada en este release. Se ha |sustituido por Java Virtual Machine Tool Interface (JVMTI).

Para obtener más información sobre JDB y JPDA, y su utilización, consulte los siguientes sitios 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

## Cómo determinar si la aplicación se está ejecutando en una JVM de 32 bits o 64 bits

Algunas aplicaciones Java deben poder determinar si se están ejecutando en una JVM de 32 bits o en una JVM de 64 bits. Por ejemplo, si la aplicación tiene una biblioteca de código nativo, la biblioteca se debe compilar por separado en formatos de 32 y 64 bits para las plataformas que den soporte a las modalidades de 32 y 64 bits de funcionamiento. En este caso, la aplicación debe cargar la biblioteca correcta en el tiempo de ejecución, ya que no se puede mezclar código de 32 y 64 bits.

La propiedad del sistema com.ibm.vm.bitmode permite a las aplicaciones determinar la modalidad en la que se está ejecutando la JVM. Devuelve los siguientes valores:

- 32 - la JVM se está ejecutando en la modalidad de 32 bits
- 64 - la JVM se está ejecutando en la modalidad de 64 bits

Puede inspeccionar la propiedad del sistema com.ibm.vm.bitmode desde el código de la aplicación utilizando la llamada:

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

## Cómo escribir aplicaciones JNI

Los números de versión de JNI válidos que pueden especificar los programas nativos en la llamada a la API JNI_CreateJavaVM() son:

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

Este número de versión determina sólo el nivel de la interfaz JNI nativa que se va a utilizar. El nivel real de la JVM que se crea viene especificado por las bibliotecas J2SE (esto es, v5.0). La API de la interfaz JNI no afecta a la especificación del lenguaje implementada por la JVM, las API de bibliotecas de clases o cualquier otra área del comportamiento de la JVM. Para obtener más información, consulte http://java.sun.com/j2se/1.5.0/docs/guide/jni.

Si la aplicación necesita dos bibliotecas JNI, una creada para 32 bits y otra para 64 bits, utilice la propiedad del sistema com.ibm.vm.bitmode para determinar si está ejecutando una JVM de 32 o de 64 bits y elegir la biblioteca adecuada.

Para compilar y enlazar una aplicación nativa con el IBM 5.0 SDK, utilice el siguiente mandato:

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

La opción -ljvm especifica que libjvm.so es la biblioteca compartida que implementa la JVM. La opción -lpthread indica que está utilizando el soporte de pthread nativo; si no se enlaza con la biblioteca pthread, se puede provocar un error de segmentación (SIGSEGV de señal) cuando se ejecuta el programa JNI.

Nota:
La Versión 1.1 de Java Native Interface (JNI) no está soportada.
| | |

## Soporte de recuperación de conectores bloqueados a nivel de hebra

|

Se han añadido cuatro nuevas clases de SDK específicas de IBM al paquete |com.ibm.jvm para dar soporte a la recuperación a nivel de hebra de los conectores |bloqueados. Las nuevas clases están empaquetadas en core.jar.

|

Estas clases permiten desbloquear hebras que se han bloqueado en llamadas de red |o de sincronización. Si una aplicación no utiliza estas clases, debe finalizar el |proceso completo, en lugar de interrumpir una hebra bloqueada individual.

|

Las clases son:

|

|
public Interface InterruptibleContext()
|
  Define dos métodos: isblocked() y unblock(). Las otras tres clases |implementan InterruptibleContext. |
|
public class InterruptibleLockContext()
|
  Es una clase de programa de utilidad para interrumpir llamadas de |sincronización. |
|
public class InterruptibleIOContext()
|
  Es una clase de programa de utilidad para interrumpir llamadas de red. |
|
public class InterruptibleThread()
|
  Es una clase de programa de utilidad que amplía java.lang.Thread y permite la |derivación de métodos ejecutables interrumpibles. Utiliza instancias de |InterruptibleLockContext e InterruptibleIOContext para ejecutar los métodos |isblocked() y unblock() necesarios, dependiendo de si la operación que está |bloqueando la hebra es de sincronización o de red. |
|

|

InterruptibleLockContext e InterruptibleIOContext funcionan haciendo referencia a |la hebra actual. Por lo tanto, si no utiliza InterruptibleThread, deberá |proporcionar su propia clase que amplíe java.lang.Thread para poder utilizar estas |nuevas clases.

|

El Javadoc para estas clases se suministra con el SDK en el archivo |docs/apidoc.zip.

## Trabajo con applets

Con el Visor de applets, puede ejecutar uno o varios applets que se invocan mediante referencia en una página Web (archivo HTML) utilizando el código APPLET. El Visor de applets encuentra los códigos APPLET en el archivo HTML y ejecuta los applets, en ventanas independientes, según se especifica en los códigos.

Como el Visor de applets es para ver applets, no puede mostrar una página Web completa que contenga muchos códigos HTML. Sólo analiza los códigos APPLET y no los otros códigos HTML de la página Web.

### Ejecución de applets con el Visor de applets

Para ejecutar un applet con el Visor de applets, escriba lo siguiente en un indicador de shell:

       appletviewer nombre

donde nombre es uno de los siguientes:

- El nombre de un archivo HTML que llama a un applet
- El URL de una página Web que llama a un applet

Por ejemplo, para invocar el Visor de applets en un archivo HTML que llama a un applet, escriba en el indicador de shell:

      appletviewer $HOME/nombrearchivo.html

donde nombrearchivo es el nombre del archivo HTML.

Por ejemplo, `http://java.sun.com/applets/NervousText/example1.html` es el URL de una página Web que llama a un applet. Para invocar el Visor de applets en esta página Web, escriba en el indicador de shell:

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

El Visor de applets no reconoce la opción charset del código <META>. Si el archivo que carga appletviewer no está codificado como el valor por omisión del sistema, se puede producir una excepción de E/S. Para evitar la excepción, utilice la opción -encoding cuando ejecute appletviewer. Por ejemplo:

    appletviewer -encoding JISAutoDetect sample.html

### Depuración de applets con el Visor de applets

Puede depurar applets utilizando la opción -debug del Visor de applets. Cuando se depuran applets, se recomienda invocar el Visor de applets desde el directorio que contiene el archivo HTML que llama al applet. Por ejemplo:

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

Puede encontrar documentación sobre cómo depurar applets utilizando el Visor de applets en el sitio Web de Sun: http://java.sun.com.

| | |

## Configuración de la asignación de memoria con páginas grandes

|

Puede habilitar el soporte de páginas grandes, en aquellos sistemas que |lo admitan, iniciando Java con la opción -Xlp.

|

El propósito principal de utilizar páginas grandes es el de proporcionar mejoras en el rendimiento de las |aplicaciones que asignan gran cantidad de memoria y a la que acceden con frecuencia. |Las mejoras en el rendimiento que ofrecen las páginas grandes se producen principalmente debido a la reducción en el |número de fallos en el TLB (Translation Lookaside Buffer). El TLB correlaciona un |rango mayor de memoria virtual, que es lo que provoca esta mejora.

|

El soporte de páginas grandes debe estar disponible en el kernel, y habilitado, |para que Java pueda utilizar páginas grandes.

|

Para configurar la asignación de memoria con páginas grandes primero deberá asegurarse de que el kernel soporte |páginas grandes. Compruebe que el archivo /proc/meminfo contiene las líneas siguientes:

|

    HugePages_Total:
    |<número de páginas>
    |HugePages_Free:      <número de páginas>
    |Hugepagesize:        <tamaño de página, en kB>

El número de páginas |disponibles y su tamaño varía según la distribución.

|

Si el soporte de páginas grandes no está disponible en el kernel, estas líneas no |existirán en el archivo /proc/meminfo. En este caso, debe instalar un nuevo kernel |que incluya soporte de páginas grandes.

|

Si el soporte de páginas grandes está disponible, pero no habilitado, `HugePages_Total` será 0. En este caso, el administrador debe habilitar el soporte de páginas |grandes. Consulte el manual del sistema operativo para obtener más información.

|

Para que la JVM pueda utilizar páginas grandes, el sistema debe tener un número |adecuado de páginas grandes contiguas disponibles. Si no se pueden asignar |páginas grandes, aunque haya suficientes páginas disponibles, es probable |que las páginas grandes no sean contiguas. Si se |configura el número de páginas grandes en el arranque, se crearán de forma |contigua.

|

Las asignaciones de páginas grandes sólo se realizarán satisfactoriamente si |la JVM tiene acceso como root. Para utilizar páginas grandes, ejecute Java como |root o establezca el bit suid del ejecutable de Java.

## Soporte CORBA

J2SE (Java 2 Platform, Standard Edition) da soporte, como mínimo, a las especificaciones definidas en el soporte de Especificaciones oficiales de CORBA en J2SE (V1.5). En algunos casos, el IBM J2SE ORB da soporte a versiones más recientes de las especificaciones.

### Soporte de GIOP 1.2

Este SDK da soporte a todas las versiones de GIOP, tal como se define en los capítulos 13 y 15 de la especificación CORBA 2.3.1, en el documento de OMG formal/99-10-07, que puede obtener en:

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

El GIOP bidireccional no está soportado.

### Soporte de interceptores portátiles

Este SDK da soporte a los interceptores portátiles, tal como se define en el OMG en el documento ptc/01-03-04, que puede obtener en:

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

Los interceptores portátiles son enganches al ORB mediante los cuales los servicios ORB pueden interceptar el flujo de normal de ejecución del ORB.

### Soporte de Servicio de nombres interoperativo

Este SDK da soporte al Servicio de nombres interoperativo, tal como se define en el OMG en el documento ptc/00-08-07, que puede obtener en:

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

El puerto por omisión que utiliza el Servidor de nombres transitorios (el mandato `tnameserv`), cuando no se proporciona ningún parámetro ORBInitialPort, ha cambiado de 900 a 2809, que es el número de puerto registrado con IANA (Internet Assigned Number Authority) para un Servicio de nombres CORBA. Puede que tenga que actualizar los programas que dependen de este valor por omisión para que funcionen con esta versión.

El contexto inicial que se devuelve del Servidor de nombres transitorios es ahora `org.omg.CosNaming.NamingContextExt`. Los programas existentes que reducen la referencia a un contexto `org.omg.CosNaming.NamingContext` continúan funcionando, y no se tienen que volver a compilar.

El ORB da soporte a los parámetros -ORBInitRef y -ORBDefaultInitRef definidos por la especificación de Servicio de nombres interoperativo, y la operación ORB::string_to_object da soporte ahora a los formatos de serie de ObjectURL (corbaloc: y corbaname:) definidos por la especificación de Servicio de nombres interoperativo.

El OMG especifica un método ORB::register_initial_reference para registrar un servicio con el Servicio de nombres interoperativo. No obstante, este método no está disponible en la API Sun Java Core Versión 5.0. Los programas que necesiten registrar un servicio en la versión actual deben invocar este método en la clase de implementación de ORB interna de IBM. Por ejemplo, para registrar un servicio "MiServicio":

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

donde `orb` es una instancia de `org.omg.CORBA.ORB` que se devuelve de `ORB.init()`, y `serviceRef` es un objeto CORBA que está conectado al ORB. Este mecanismo es provisional, y no es compatible con las próximas versiones ni puede trasladarse a otros ORB que no sean de IBM.

### Propiedades del sistema para rastrear el ORB

Una característica de depuración en tiempo de ejecución proporciona una capacidad de servicio mejorada. Es muy útil para el diagnóstico de problemas o puede solicitarla el personal de servicio de IBM. El rastreo se controla mediante tres propiedades del sistema.

- Para activar el rastreo, establezca `com.ibm.CORBA.Debug=true`.
- Para dar formato y añadirlo a los mensajes de GIOP de rastreo enviados y recibidos, establezca `com.ibm.CORBA.CommTrace=true`. Por omisión, el rastreo de ORB se envía a archivos que tienen nombres con el formato orbtrc.DDMMYYYY.HHmm.SS.txt.
- Para enviarlo a un archivo diferente, establezca `com.ibm.CORBA.Debug.Output=<nombrearchivo>`.

Por ejemplo, para rastrear sucesos y mensajes de GIOP formateados, escriba:

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

No active el rastreo para operaciones normales, ya que puede disminuir el rendimiento. Aunque haya desactivado el rastreo, FFDC (First Failure Data Capture) continúa funcionando, de forma que sólo se notifican los errores graves. Si se genera un archivo de salida de depuración, examínelo para comprobar el problema. Por ejemplo, puede que se haya detenido el servidor sin ejecutar ORB.shutdown().

El contenido y el formato de la salida de rastreo variará según la versión.

### Propiedades del sistema para ajustar el ORB

Las siguientes propiedades permiten ajustar el ORB:

- Para controlar la fragmentación de GIOP 1.2, establezca la propiedad del sistema com.ibm.CORBA.FragmentSize.

  Por ejemplo, para establecer el tamaño de fragmento en 4096 bytes:

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

  El tamaño de fragmento por omisión es 1024 bytes. Para desactivar la fragmentación, establezca el tamaño de fragmento en 0.

- En una red heterogénea, la respuesta a una petición CORBA se puede retrasar o perder. Puede establecer el tiempo máximo de espera utilizando la propiedad del sistema com.ibm.CORBA.RequestTimeout. Asimismo, puede utilizar com.ibm.CORBA.LocateRequestTimeout para controlar el tiempo de espera de LocateRequests. Por ejemplo, para restringir los dos retardos a 30 segundos, escriba:

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

  Por omisión, el ORB espera indefinidamente una respuesta. No establezca el tiempo de espera demasiado bajo y así evitará que las conexiones finalicen de forma innecesaria.

- Si el programa proporciona un servicio en la red, deberá establecer el número del puerto desde el que el ORB lee las peticiones entrantes en un valor conocido. Puede controlarlo utilizando la propiedad del sistema com.ibm.CORBA.ListenerPort.

  Por ejemplo, para que el ORB utilice el puerto 1050, escriba:

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

  Si se establece esta propiedad, el ORB empieza a escuchar tan pronto como se inicializa. De lo contrario, empieza a escuchar sólo cuando sea necesario.

### Permisos de seguridad de Java 2 para el ORB

Cuando se ejecuta con Java 2 SecurityManager, la invocación de algunos métodos en las clases de la API CORBA puede provocar comprobaciones de permisos, que pueden generar una SecurityException. Los métodos afectados son los siguientes:

Tabla 2. Métodos afectados cuando se ejecuta con Java 2 SecurityManager
Clase/Interfaz | Método | Permiso necesario
--- | --- | ---
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 (String, boolean) | java.net.SocketPermission connect
org.omg.CORBA. portable.ObjectImpl | _get_interface_def | java.net.SocketPermission connect
org.omg.CORBA. Request | invoke | java.net.SocketPermission connect
org.omg.CORBA. Request | send_deferred | java.net.SocketPermission connect
org.omg.CORBA. Request | send_oneway | java.net.SocketPermission connect
javax.rmi. PortableRemoteObject | narrow | java.net.SocketPermission connect

Si el programa utiliza alguno de estos métodos, compruebe que tenga los permisos necesarios.

### Clases de implementación de ORB

Las clases de implementación de ORB en este release son:

- 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

Estos son los valores por omisión, y se recomienda no establecer estas propiedades o hacer referencia a las clases de implementación directamente. A efectos de portabilidad, haga referencia sólo a las clases de la API CORBA, y no a la implementación. Estos valores pueden cambiar en próximos releases.

## RMI a través de IIOP

La Invocación a método remoto (RMI) de Java proporciona un mecanismo sencillo para realizar la programación Java distribuida. RMI a través de IIOP (RMI-IIOP) utiliza el protocolo IIOP (Internet Inter-ORB Protocol) estándar de Common Object Request Broker Architecture (CORBA) para ampliar la RMI Java básica para la comunicación. Esto permite dirigir la interacción con otros ORB (Object Request Brokers) de CORBA, siempre que estén implementados en Java o en otro lenguaje de programación.

La siguiente documentación está disponible:

- La guía RMI-IIOP Programmer's Guide es una introducción a la escritura de programas RMI-IIOP. La guía se instala cuando se instala esta documentación.
- El directorio demo contiene:
  - Un ejemplo "Hello World" que puede conmutar entre los protocolos Java Remote Method Protocol (JRMP) e IIOP (demo/rmi-iiop/hello)
  - Un ejemplo "Hello World" que interactúa con un programa IDL estándar (demo/rmi-iiop/idl)
- El documento Java Language to IDL Mapping es una especificación técnica detallada de RMI-IIOP y se puede encontrar en:
  http://www.omg.org/cgi-bin/doc?ptc/00-01-06.pdf

## Implementación de la agrupación de manejadores de conexiones para RMI

La agrupación de hebras para manejadores de conexiones para RMI no está habilitada por omisión.

Para habilitar la agrupación de conexiones implementada a nivel TCPTransport de RMI, establezca la opción

    -Dsun.rmi.transport.tcp.connectionPool=true (o cualquier valor no nulo)

Esta versión del Runtime Environment no tiene ningún valor que pueda utilizarse para limitar el número de hebras en la agrupación de conexiones.

Para obtener más información, consulte el sitio de Java de Sun: http://java.sun.com.

## Soporte BiDireccional mejorado

El IBM SDK incluye el soporte BiDireccional mejorado. Para obtener más información, consulte http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html. El Javadoc para el paquete BiDirectional se suministra con el SDK en el archivo docs/apidoc.zip.

## BigDecimal mejorado

| |

A partir de Java 5.0, la clase IBM BigDecimal ha sido adoptada por Sun como |java.math.BigDecimal. IBM ya no mantiene com.ibm.math.BigDecimal y se ha etiquetado |como desechado. Se recomienda migrar el código Java existente para que utilice |java.math.BigDecimal.

|

El nuevo java.math.BigDecimal utiliza los mismos métodos que los anteriores |java.math.BigDecimal y com.ibm.math.BigDecimal. El código existente que utiliza |java.math.BigDecimal continuará funcionando correctamente.

|

Para migrar el código Java existente para que utilice la clase |java.math.BigDecimal, cambie la sentencia import al principio del archivo java de: |`import com.ibm.math.*;` a `import java.math,*;`.

## Soporte del símbolo de Euro

IBM SDK y Runtime Environment establecen el Euro como la moneda por omisión para los países de la Unión Monetaria Europea (EMU) a partir del 1 de enero de 2002.

Para utilizar la moneda nacional anterior, especifique `-Duser.variant=PREEURO` en la línea de mandatos Java.

Si ejecuta los entornos locales de inglés de Reino Unido, danés o sueco y desea utilizar el Euro, especifique `-Duser.variant=EURO` en la línea de mandatos Java.

# Utilización de la API Java Communications (JavaComm)

El paquete de la interfaz de programas de aplicación (API) Java Communications (JavaComm) es un paquete opcional que se proporciona para su uso con Runtime Environment para Linux en las plataformas IA32, PPC32/PPC64 y AMD64/EM64T. JavaComm se instala de forma independiente del SDK o el Runtime Environment.

La API JavaComm ofrece a las aplicaciones Java un método independiente de la plataforma para ejecutar comunicaciones de puerto paralelo y serie en tecnologías como, por ejemplo, correo de voz, fax y smartcards. Después de grabar comunicaciones de puerto paralelo o serie para la aplicación, puede incluir esos archivos con la aplicación.

La API Java Communications da soporte a puertos serie Electronic Industries Association (EIA)-232 (RS232) y puertos paralelo Institute of Electrical and Electronics Engineers (IEEE) 1284, y está soportada en sistemas con IBM Runtime Environment Versión 5.0.

Utilizando la API Java Communications puede:

- Listar los puertos de un sistema
- Abrir y reclamar la propiedad de los puertos
- Resolver los conflictos de propiedad de puertos entre las aplicaciones que utilizan la API Java Communications.
- Realizar la supervisión de puertos de E/S síncronos y asíncronos mediante la notificación de eventos
- Recibir sucesos de estilo de bean que describen los cambios de estado en el puerto

## Instalación de la API Java Communications

Asegúrese de que hay instalada una copia del SDK o el Runtime Environment antes de instalar la API Java Communications.

Si ha utilizado el paquete de RPM para instalar Java originalmente, instale la API Java Communications desde el archivo de RPM. Para instalar la API Java Communications desde un paquete de RPM:

1. Abra un indicador de shell y compruebe que es usuario root.
2. Utilizando el mandato `rpm -ivh`, instale el archivo de RPM de la API Java Communications. Por ejemplo:

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

   La API Java Communications se instala dentro de la estructura de directorios de /opt/ibm/java2-i386-50/.

Para instalar la API Java Communications desde un archivo .tgz:

1. Guarde el archivo archivador de la API Java Communications, ibm-java2-javacomm-50-linux-<arqui>.tgz, en el directorio que contenga el directorio IBMJava2-50.
2. Desde un indicador de shell, en el directorio que contenga el archivo .tgz, extraiga el contenido:

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

   La API Java Communications se extrae en subdirectorios dentro del directorio IBMJava2-50 existente.

## Ubicación de los archivos de la API Java Communications

Los archivos de la API Java Communications se instalan de la siguiente manera:

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

Si ha realizado la instalación en el directorio por omisión, el archivo comm.jar estará en /opt/ibm/java2-i386-50/jre/lib/ext.

Si ha instalado el paquete en otro directorio, los archivos se guardarán en la misma estructura de directorios, pero /opt/ibm/java2-i386-50/ se sustituirá por el directorio donde haya instalado la API Java Communications.

## Configuración de la API Java Communications

Después de instalar la API Java Communications, debe:

- Cambiar la modalidad de acceso de los puertos serie y paralelo.
- Establecer la variable de entorno PATH, si no la ha establecido al instalar Java. Consulte el apartado Establecimiento de la PATH.

### Cambio de la modalidad de acceso de los puertos serie y paralelo

Después de instalar la API Java Communications, debe cambiar la modalidad de acceso de los puertos serie y paralelo para que los usuarios puedan acceder a estos dispositivos. Debe otorgar al usuario acceso de lectura/grabación a los dispositivos necesarios. Inicie una sesión como root y utilice los siguientes mandatos, según corresponda:

        chmod 666 /dev/ttyS0 (también conocido como el puerto serie COM1)
        chmod 666 /dev/lp0      (también conocido como el puerto paralelo LPT1)
        chmod 666 /dev/ttyS1    (también conocido como el puerto serie COM2)
        chmod 666 /dev/ttyS2    (también conocido como el puerto serie COM3)
        chmod 666 /dev/ttyS3    (también conocido como el puerto serie COM4)

Estos mandatos otorgan acceso de lectura/grabación a todos los usuarios del sistema.

Un método alternativo es crear los permisos 660 y añadir usuarios específicos al grupo en el que residan los dispositivos. Por ejemplo, en un sistema SUSE, los dispositivos están en el grupo `uucp`. De esta forma, los usuarios se pueden añadir al grupo `uucp` para obtener acceso a los dispositivos.

Cambie la modalidad de acceso de los demás puertos según sea necesario.

#### Especificación de dispositivos en el archivo javax.comm.properties

El archivo javax.comm.properties permite especificar los prefijos de los dispositivos que hay disponibles para la API Java Communications y si son serie o paralelo. Los números de puerto se asignan de forma secuencial a todos los dispositivos. Por ejemplo, si especifica `/dev/ttyS=PORT_SERIAL` y existen los dispositivos `/dev/ttyS0` y `/dev/ttyS1`, se les asignará COM1 y COM2, respectivamente.

Para utilizar los conectores serie USB, descomente la línea `/dev/ttyUSB=PORT_SERIAL` en el archivo javax.comm.properties. Si existen los dispositivos `/dev/ttyUSB0` y `/dev/ttyUSB1`, y COM1 y COM2 ya se han definido, los dispositivos serie USB se asignan a los siguientes puertos secuenciales, COM3 y COM4.

## Habilitación de puertos serie en IBM ThinkPads

La mayoría de los ThinkPads tienen sus puertos serie inhabilitados por omisión en el BIOS. Actualmente, no se pueden habilitar los puertos con Linux (el paquete tpctl no habilita los puertos si están inhabilitados en el BIOS).

Para habilitar los puertos en el BIOS, debe utilizar la versión DOS del programa de utilidad ThinkPad Configuration que está disponible en el sitio de descargas de IBM ThinkPad. Para utilizar el programa de utilidad ThinkPad Configuration, necesita un disquete de DOS de autoarranque. Tenga en cuenta que el programa de utilidad ThinkPad Configuration puede que se haya instalado como parte de los Programas de utilidad de ThinkPad en Windows, dependiendo de las opciones de instalación, en cuyo caso podrá ejecutarlo desde un indicador de mandatos en Windows.

La aplicación ThinkPad Configuration que se proporciona con Windows tiene opciones para habilitar o inhabilitar los puertos serie y paralelo, pero no permite cambiar los valores en el BIOS. Por lo tanto, si utiliza esta aplicación con Windows, los puertos estarán disponibles; no obstante, si reinicia la máquina con Linux, los puertos no estarán habilitados.

## Limitaciones de impresión con la API Java Communications

Si imprime con la API Java Communications, puede que tenga que pulsar "Alimentación de papel", "Continuar" u otra opción similar en la impresora.

## Desinstalación de la API Java Communications

El proceso que se utiliza para desinstalar la API Java Communications depende de si se ha instalado el paquete instalable Red Hat Package Manager (RPM) o el paquete comprimido Tape Archive (TAR).

### Desinstalación del paquete instalable Red Hat Package Manager (RPM)

Para desinstalar la API Java Communications si ha instalado el paquete instalable RPM:

1. En el indicador del shell, escriba:

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

   También puede utilizar una herramienta gráfica como, por ejemplo, kpackage o yast2.

2. Si el directorio donde ha instalado la API Java Communications no contiene otras herramientas que necesite, elimine ese directorio de la sentencia PATH.

### Desinstalación del paquete comprimido Tape Archive (TAR)

Para desinstalar la API Java Communications, si ha instalado el paquete comprimido TAR, suprima los siguientes archivos del directorio donde los haya instalado:

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

## Documentación de la API Java Communications

Puede encontrar la documentación y ejemplos de la API Java Communications en el sitio Web de Sun: http://java.sun.com.

# Despliegue de aplicaciones Java

## (Sólo para Linux IA de 32 bits y PPC32) Utilización del Java Plug-in

El Java Plug-in es un plug-in de navegador Web. Si utiliza el Java Plug-in, puede ignorar la JVM por omisión del navegador Web y utilizar en su lugar el Runtime Environment que desee para ejecutar applets o beans en el navegador.

Debe permitir que los applets terminen de cargarse para que el navegador no se 'cuelgue'. Por ejemplo, si utiliza el botón Atrás y, a continuación, el botón Adelante mientras se está cargando un applet, puede que no se puedan cargar las páginas HTML.

El Java Plug-in está documentado por Sun en: http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.

### Navegadores soportados

|Para Linux PPC32, Mozilla 1.6 es el |navegador soportado.

|Para Linux IA32, consulte Tabla 3.

|Tabla 3. Navegadores soportados por el Java Plug-in en Linux IA32
|Distribución | |Versión por omisión de Netscape | |Versiones soportadas de Netscape | |Versión por omisión de Mozilla | |Versiones soportadas de 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

|

### Instalación y configuración del Java Plug-in

|Varias versiones del Java Plug-in se suministran |con el SDK. Seleccione la versión adecuada para el navegador. Las más |corrientes son:

| |
libjavaplugin_oji.so
|
  El Plug-in más común. Se basa en la iniciativa |OJI (Open JVM Integration) de Mozilla y se utiliza |con la mayoría de los productos y subproductos Mozilla, incluido Firefox. |
|
libjavaplugin_ojigtk2.so
|
  El mismo Plug-in que el que aparece anteriormente pero |compilado con el conjunto de herramientas GTK2. |

|Existen instrucciones para instalar el Plug-in en |alguno de los navegadores comunes que aparecen más abajo.

|Debe enlazar simbólicamente el Plug-in, en lugar de |copiarlo, de modo éste que pueda localizar la JVM.

#### Mozilla

|Sólo se da soporte a Mozilla y versiones |posteriores.

Para que el Java Plug-in esté disponible para todos los usuarios:

1. Inicie la sesión como root.
2. Cambie al directorio Plug-ins de Mozilla (puede variar en algunas distribuciones de Linux).

       cd /usr/local/mozilla/plugins/

3. |Cree un enlace simbólico con libjavaplugin_oji.so. |

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

Debe enlazar simbólicamente el Plug-in, en lugar de copiarlo, de modo éste que pueda localizar la JVM.

| | |

#### Firefox

|

Para que el Java Plug-in esté disponible para todos los usuarios:

|

|
1. Inicie la sesión como root.
|
2. Cambie al directorio Plug-ins de Firefox (puede variar en |algunas distribuciones de Linux). |

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

|
3. |Cree un enlace simbólico con libjavaplugin_oji.so. |

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

   |

Debe enlazar simbólicamente el Plug-in, en lugar de copiarlo, |de modo éste que pueda localizar la JVM.

#### Netscape 7.1 y posteriores

Para instalar y configurar el Java Plug-in para Netscape, cree un enlace simbólico entre el archivo de biblioteca /opt/ibm/java2-i386-50/jre/bin/javaplugin_oji.so y el directorio Plug-ins del navegador (/vía-instalación-navegador/plugins).

1. Inicie la sesión como root.
2. Cambie al directorio Plug-ins de Netscape (puede variar en algunas distribuciones de Linux).

       cd /usr/local/netscape/plugins/

3. Cree un enlace simbólico entre javaplugin_oji.so y el directorio Plug-in.

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

Debe enlazar simbólicamente el Plug-in, en lugar de copiarlo, de modo éste que pueda localizar la JVM.

### Soporte de DOM (Document Object Model) común

Debido a limitaciones en determinados navegadores, es posible que no pueda implementar todas las funciones del paquete org.w3c.dom.html.

- Se genera una excepción sun.plugin.dom.exception.NotSupportedException en algunas de estas funciones.
- Se genera una excepción sun.plugin.dom.exception.InvalidStateException cuando el navegador no soporta una función particular.

### Utilización de parámetros DBCS

El Java Plug-in soporta caracteres de doble byte (por ejemplo chino tradicional BIG-5, coreano, japonés) como parámetros para los códigos `<APPLET>`, `<OBJECT>` y `<EMBED>`. Debe seleccionar la codificación de caracteres correcta para el documento HTML para que el Java Plug-in pueda analizar el parámetro. Especifique la codificación de caracteres para el documento HTML utilizando el código `<META>` en la sección `<HEAD>` de esta forma:

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

Este ejemplo indica al navegador que analice el archivo HTML utilizando la codificación de caracteres chinos BIG-5. Todos los parámetros se pasan correctamente al Java Plug-in. Sin embargo, es posible que algunas versiones antiguas de navegadores no entiendan correctamente este código. En este caso, puede forzar que el navegador ignore este código, pero deberá cambiar la codificación manualmente.

Para especificar la codificación que desea utilizar para analizar el archivo HTML:

- Netscape 4: menú Ver -> Juego de caracteres
- Mozilla: menú Ver -> Codificación de caracteres

## (Sólo para Linux IA de 32 bits, PPC32 y PPC64) Utilización de Web Start

Puede utilizar Java Web Start para desplegar aplicaciones Java. Web Start permite al usuario iniciar y gestionar aplicaciones directamente desde la Web. Utilizando Java Web Start, puede iniciar aplicaciones fácilmente desde la Web, con la garantía de que ejecuta la última versión, lo que elimina los procedimientos de instalación o actualización. Java Web Start elimina la necesidad de descargar e instalar software, lo que permite ahorrar el tiempo de las opciones de instalación.

|Además de los java-vm-args que se describen en |http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, |Web Start da soporte a -Xgcpolicy para establecer la política |de recopilación de desechos.

Para obtener información sobre los navegadores que dan soporte a Web Start, consulte el apartado Navegadores soportados.

Para obtener más información sobre Web Start, consulte: http://java.sun.com/products/javawebstart y http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Para obtener más información sobre el despliegue de aplicaciones, consulte: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.

### Ejecución de Web Start

Java Web Start v5.0 se instala automáticamente cuando se instala Java utilizando los paquetes .rpm o .tgz.

|Si extrae Java del paquete .tgz, ejecute el script de shell |jre/lib/javaws/updateSettings.sh para actualizar los archivos .mailcap y .mime.types |en el sistema.

Puede invocar Web Start de tres formas:

1. Seleccionar un enlace en una página Web que haga referencia a un archivo .jnlp.
2. En el indicador de shell, escriba `javaws <URL>`, donde `<URL>` es la ubicación de un archivo .jnlp.
3. |Si ya ha utilizado Java Web Start para abrir la |aplicación, ejecute javaws |desde el directorio |jre/bin, para iniciar |el Visor de antememoria de aplicaciones Java.

Una vez descargada una aplicación, ésta se almacena en la Antememoria de aplicaciones Java. Si se vuelve a acceder a la aplicación, Java Web Start descarga una versión más reciente de la aplicación, si está disponible, y si no, utiliza la versión que hay en la antememoria.

Si se produce un error en un archivo .jnlp (como un nombre de código no válido), Web Start falla sin mostrar un mensaje de error.

## Envío de aplicaciones Java

Una aplicación Java, a diferencia de un applet Java, no se puede basar en un navegador Web para los servicios de instalación y tiempo de ejecución. Cuando se envía una aplicación Java, el paquete de software suele estar formado por los siguientes componentes:

- Sus propios archivos de datos, recursos y clases
- Un programa o un procedimiento de instalación

Para ejecutar la aplicación, un usuario necesita el Runtime Environment para Linux. El software de SDK para Linux contiene un Runtime Environment. Sin embargo, no puede suponer que los usuarios tienen instalado el software de SDK para Linux.

La licencia de software de SDK para Linux no permite redistribuir ninguno de los archivos del SDK con la aplicación. Asegúrese de que la máquina de destino tenga instalada una versión con licencia de SDK para Linux.

| | |

# Compartimiento de datos de clases entre JVM

|

IBM Virtual Machine (VM) permite compartir clases de aplicación y de rutina de |carga entre VM, almacenándolas en la antememoria en una memoria compartida. El |compartimiento de clases reduce el consumo general de memoria virtual cuando más de |una VM comparte una antememoria. El compartimiento de clases también reduce el |tiempo de arranque de una VM una vez creada la antememoria. La antememoria de clases |compartidas es independiente de la VM activa y persiste después del tiempo de vida |de la VM que ha iniciado la antememoria.

| |

## Visión general del compartimiento de |clases

|

El IBM SDK permite compartir tantas clases como sea posible, de forma |transparente para el usuario.

| |

### Contenido de la antememoria

|

La antememoria de clases compartidas contiene datos y metadatos de clases |estáticas de sólo lectura que describen las clases. Cualquier VM puede leer o |actualizar la antememoria. Las VM que comparten clases deben ser del mismo release. |Debe tener cuidado si utiliza la modificación del código de bytes en el |tiempo de ejecución. (Consulte Modificación del código de bytes en el tiempo de ejecución.)

| |

### Actualización dinámica de la antememoria

|

Como la antememoria de clases compartidas persiste después del tiempo de vida de |la VM, la antememoria se actualiza dinámicamente para reflejar las modificaciones |realizadas en los JAR o en las clases del sistema de archivos. La actualización |dinámica hace que la antememoria sea transparente para la aplicación que la |utiliza.

| |

### Habilitación del compartimiento de clases

|

Habilite el compartimiento de clases utilizando la opción |-Xshareclasses cuando inicie una VM, para que la VM se conecte |a una antememoria existente o cree una si no existe. Todas las clases de |aplicación y de rutina de carga cargadas por la VM se comparten por omisión. Los |cargadores de clases personalizados se comparten automáticamente si amplían el |cargador de clases de la aplicación; de lo contrario, deben utilizar la API Helper |de Java que se proporciona con la VM para acceder a la antememoria. (Consulte el |apartado Adaptación de cargadores de clases personalizados para compartir clases.)

| |

### Seguridad de antememoria

|

El acceso a la antememoria de clases compartidas está limitado por |permisos del sistema operativo y permisos de la seguridad Java. |La memoria de clases compartidas se crea con el acceso |de usuario por omisión a menos que se utilice la subopción de la línea de |mandatos groupAccess . Sólo un cargador de |clases que se haya registrado para compartir clases puede añadir clases a |la antememoria de clases compartidas. Si un Java SecurityManager está |instalado, los cargadores de clases, excepto los cargadores de clases por |omisión de la extensión, la aplicación o la rutina de carga, deben obtener |permiso para compartir clases añadiendo SharedClassPermissions al archivo |java.policy. (Consulte Utilización de SharedClassPermissions.) |El RuntimePermission "createClassLoader" limita la creación de nuevos |cargadores de clases y, por lo tanto, restringe el acceso a la |antememoria.

| |

### Ciclo de vida de la antememoria

|

En un sistema pueden existir varias antememorias, que se especifican por el |nombre como una subopción del mandato -Xshareclasses. |Una VM sólo puede conectarse a una antememoria cada vez. El tamaño de la antememoria se |especifica en el arranque utilizando -Xscmx<n>[k|m|g], |pero después este tamaño se fija para el tiempo de vida de la antememoria. Las |antememorias existen hasta que se destruyen de forma explícita utilizando una |subopción en el mandato -Xshareclasses o hasta que se reinicia |el sistema.

| |

### Programas de utilidad de antememoria

|

Todos los programas de utilidad de antememoria son |subopciones en el mandato -Xshareclasses. Utilice |-Xshareclasses:help para ver una lista de las subopciones |disponibles.

| |

## Utilización de las opciones de la línea de mandatos para el compartimiento de |clases

|

El compartimiento de clases se habilita y se configura utilizando las opciones de |la línea de mandatos -Xshareclasses y -Xscmx.

|

|
- -Xscmx<tamaño>[k|m|g] |
  |
  - Especifica el tamaño de la antememoria. Esta opción se aplica sólo si |se está creando una antememoria y no existe ninguna antememoria con el |mismo nombre. El tamaño por omisión |de la antememoria depende de la plataforma. Para averiguar el valor de |tamaño que se está utilizando, añada -verbose:sizes como un argumento de línea de mandatos. El tamaño mínimo de la antememoria es 4 |KB. El tamaño máximo de la antememoria depende también de la plataforma. (Consulte el |apartado Límites del tamaño de antememoria.)
|
- -Xshareclasses:<subopción1>[,<subopción2>...] |
  |
  - Habilita el compartimiento de clases. Puede utilizar varias subopciones, algunas |de las cuales son programas de utilidad de antememoria. Los programas de utilidad de |antememoria ejecutan la operación necesaria en la antememoria especificada, sin |iniciar la VM. Puede combinar varias subopciones, separadas por comas, pero los |programas de utilidad de antememoria son mutuamente excluyentes.
  Puede utilizar las siguientes subopciones con la opción |-Xshareclasses, por ejemplo, -Xshareclasses:help |
  |
  - help |
    |
    - Enumera todas las opciones de la línea de mandatos.
  |
  - name=<nombre> |
    |
    - Se conecta a una antememoria con un nombre determinado, y la crea si no existe |previamente. Utilice la opción de programa de utilidad |listAllCaches para mostrar qué antememorias hay |disponibles actualmente. Si no especifica un nombre, el nombre por omisión |"sharedcc_" se combina con el nombre del usuario actual para crear el |nombre de la antememoria.
  |
  - groupAccess |
    |
    - Establece los permisos del sistema operativo de una antememoria nueva |para permitir el acceso del grupo a la antememoria. El valor por omisión |es sólo de acceso de usuario.
  |
  - verbose |
    |
    - Verbose proporciona una salida detallada sobre la actividad de E/S de |la antememoria y enumera la información sobre las clases que se almacenan |y se encuentran. Se proporciona un ID exclusivo a cada cargador de clases (el cargador de |clases de rutina de carga es siempre 0) y la salida muestra la jerarquía de |cargadores de clases en el trabajo, donde los cargadores de clases deben solicitar |una clase a sus padres para poder cargarla ellos. Es normal ver muchas |solicitudes anómalas; este comportamiento es el esperado para la jerarquía |de cargadores de clases. Tenga en cuenta que la opción estándar |-verbose:class también habilita la salida verbosa |del compartimiento de clases si el compartimiento de clases está |habilitado.
  |
  - modified=<contexto modificado> |
    |
    - Esta opción es necesaria si se instala un agente de código de bytes que puede |modificar el código de bytes en el tiempo de ejecución. Si no especifica esta opción |y se instala un agente de código de bytes, no se almacena ni se encuentra ninguna |clase en la antememoria. El <contexto modificado> es un |descriptor elegido por el usuario; por ejemplo, "miModificación1". Esto particiona |la antememoria, de forma que sólo las JVM que utilicen el contexto miModificación1 |pueden compartir las mismas clases. Por ejemplo, si se ejecuta "HelloWorld" con un |contexto de modificación y, a continuación, se vuelve a ejecutar con un contexto de |modificación diferente, aparecerán todas las clases almacenadas dos veces en la |antememoria.
  |
  - destroy (opción de programa de utilidad) |
    |
    - Destruye una antememoria utilizando el nombre especificado en la subopción |name=<nombre>. Si no se especifica |el nombre, se destruye la antememoria por omisión. Una |antememoria sólo se puede destruir si se concluyen todas las VM que la utilizan y el |usuario tiene permisos suficientes.
  |
  - destroyAll (opción de programa de utilidad) |
    |
    - Intenta destruir todas las antememorias disponibles para el usuario. Una |antememoria sólo se puede destruir si se concluyen todas las VM que la utilizan y el |usuario tiene permisos suficientes.
  |
  - expire=<tiempo en minutos> |(opción de programa de utilidad) |
    |
    - Destruye todas las antememorias que no se han utilizado el tiempo especificado.
  |
  - listAllCaches (opción de programa de utilidad) |
    |
    - Enumera todas las antememorias del sistema, indicando si se están |utilizando y cuándo se utilizaron por última vez.
  |
  - printStats (opción de programa de utilidad) |
    |
    - Muestra información estadística de resumen sobre la antememoria especificada en |la subopción name=<nombre>. Si |no se especifica el nombre, se muestran las estadísticas de la antememoria por |omisión. La información más útil que se muestra es cómo está de llena la antememoria y |cuántas clases contiene. Tenga en cuenta que las clases "obsoletas" son clases que |se han actualizado en el sistema de archivos y que, por lo tanto, la antememoria ha |marcado como "obsoletas". Las clases obsoletas no se depuran de la antememoria. Consulte la guía |Diagnostics Guide para obtener más información.
  |
  - printAllStats (opción de programa de utilidad) |
    |
    - Muestra información detallada sobre el contenido de la antememoria especificada |en la subopción name=<nombre>. Si |no se especifica el nombre, se muestran las estadísticas de la antememoria por |omisión. Cada clase aparece en orden cronológico junto con una referencia a la |ubicación desde la que se ha cargado. Consulte la guía |Diagnostics Guide para obtener más información.

| |

## Cómo crear, llenar, supervisar y suprimir una antememoria

|

Para habilitar el compartimiento de clases, añada |-Xshareclasses[:name=<nombre>] en la línea de mandatos de la |aplicación. La VM se conectará a una antememoria existente con el nombre |proporcionado o creará una nueva antememoria con ese nombre. Si se crea |una nueva antememoria, se llenará con todas las clases de aplicación y de |rutina de carga que se están cargando hasta que se llena la antememoria. Si se inician dos o más VM simultáneamente, todas llenarán la |antememoria de forma simultánea.

|

Para comprobar que se ha creado la antememoria, ejecute `java |-Xshareclasses:listAllCaches`. Para ver cuántas clases y |cuántos datos de clases se están compartiendo, ejecute `java |-Xshareclasses:[name=<nombre>],printStats`. (Estos programas de utilidad se |pueden ejecutar cuando la VM de aplicación haya terminado o en otra ventana de |mandatos).

|

Para ver las clases que se están cargando desde la antememoria o que se han |almacenado en la antememoria, añada |`-Xshareclasses:[name=<nombre>],verbose` en la línea de mandatos de la |aplicación.

|

Para suprimir la antememoria creada, ejecute `java |-Xshareclasses:[name=<nombre>],delete`. Las antememorias sólo se deben |suprimir si contienen muchas clases obsoletas o si la antememoria está llena y desea |crear una antememoria mayor.

|

Se recomienda que ajuste el tamaño de antememoria para la aplicación |específica porque es poco probable que el valor por omisión sea el tamaño |óptimo. La mejor forma de determinar el tamaño óptimo de antememoria es |especificar una antememoria grande mediante -Xscmx, |ejecutar la aplicación y, a continuación, utilizar printStats para |determinar cuántos datos de clases se han almacenado. Añada una pequeña |cantidad al valor mostrado en printStats por si se produce alguna |contingencia. Tenga en cuenta que como las clases se pueden cargar en |cualquier momento durante la vida de la VM, es mejor realizar este |análisis después de que la aplicación haya finalizado. No |obstante, una antememoria completa no tiene ningún impacto |negativo en el rendimiento o capacidad de cualquier VM conectada a |ella, de modo que es legítimo decidir un tamaño de antememoria menor |que el necesario.

|

Si se llena una antememoria, se emite un mensaje a la línea de |mandatos de todas las VM que utilicen la antememoria y éstas cargan |cualquier otra clase en su propia memoria de proceso. Las clases de una antememoria llena todavía se |pueden compartir, pero una antememoria llena es de sólo lectura y no se |puede actualizar con nuevas clases.

| |

## Rendimiento y consumo de memoria

|

El compartimiento de clases es particularmente útil en los sistemas que |utilizan más de una VM con un código similar, ya que éstos se benefician |del consumo reducido de memoria virtual. También es útil en los sistemas |que arrancan y concluyen las VM con frecuencia, ya que éstos se benefician |de la mejora en el tiempo de arranque.

|

La carga adicional que supone crear y llenar una nueva antememoria es mínima. |El coste del tiempo de arranque de la VM para una única VM se encuentra |normalmente entre el 0 y el 5%, dependiendo de cuántas clases se carguen. La mejora en |el tiempo de arranque de la VM con una antememoria que se ha llenado de |clases se encuentra normalmente entre el 10% y el 40%, dependiendo del |sistema operativo y del número de clases cargadas. Varias VM en ejecución |de forma concurrente mostrarán más ventajas relacionadas con el tiempo de |arranque global.

|

Cuando se ejecuta la aplicación con el compartimiento de clases, se pueden |utilizar las herramientas del sistema operativo para ver la reducción en el consumo |de la memoria virtual.

| |

## Limitaciones y consideraciones al utilizar el |compartimiento de clases

| |

### Límites del tamaño de antememoria

|

La antememoria para compartir clases se asigna |utilizando el mecanismo System V IPC Shared Memory.

|

El tamaño máximo de antememoria teórico es 2GB. El tamaño de antememoria que puede |especificar está limitado por la cantidad de espacio físico y de |paginación |disponible en el sistema.

|

Como el espacio de direcciones virtuales es un proceso |que se comparte entre la antememoria de clases compartidas y el |almacenamiento dinámico de Java, si aumenta el tamaño máximo del |almacenamiento dinámico Java, se reducirá el tamaño de la antememoria de |clases compartidas que puede crear.

|

El tamaño de antememoria está limitado por los valores de |SHMMAX, que limita la cantidad de memoria compartida que se |puede asignar. Puede encontrar estos valores en el archivo /proc/sys/kernel/shmmax. |SHMMAX se establece normalmente en 30 MB.

| |

### Modificación del código de bytes en el tiempo de ejecución

|

Una VM que utiliza un agente JVMTI que puede modificar el código de bytes no |puede compartir clases, a menos que se utilice la subopción |modified=<contexto_modificado> en la línea de mandatos (ver arriba). El contexto |modificado es un descriptor especificado por el usuario que describe el tipo de |modificación que se está realizando. Todas las VM que utilicen un determinado |contexto modificado deben modificar el código de bytes de forma predecible y |repetible para cada clase, para que las clases modificadas almacenadas en la |antememoria tengan las modificaciones esperadas cuando las cargue otra VM. |El motivo por el que una modificación debe ser predecible es que el agente |no puede volver a modificar las clases cargadas desde la antememoria de |clases compartidas. Tenga en |cuenta que el código de bytes modificado y no modificado se puede almacenar en la |misma antememoria. Consulte la guía Diagnostics |Guide para obtener más información sobre este tema.

| |

### Limitaciones del sistema operativo

|

En los sistemas operativos que pueden ejecutar aplicaciones de |32 bits y 64 bits, el compartimiento de clases no está permitido entre VM de 32 bits |y 64 bits. La subopción listAllCaches listará las antememorias |de 32 bits o 64 bits, dependiendo de la modalidad de dirección de la VM que se está |utilizando.

|

La antememoria de clases compartidas necesita espacio de disco para almacenar |información de identificación acerca de las antememorias que existen en el sistema. |Esta información se encuentra en |/tmp/javasharedresources. Si se suprime el directorio de información de |identificación, la VM no podrá identificar las clases compartidas en el sistema y |deberá volver a crear la antememoria. Utilice el mandato |`ipcs` para ver los segmentos de memoria utilizados por una VM o una |aplicación.

|

Los usuarios que ejecuten una JVM deberán estar en el mismo grupo para poder |utilizar una antememoria de clases compartidas. Los permisos para |acceder a una antememoria de clases compartidas vienen determinados por el |sistema operativo. Si no se especifica un nombre de antememoria, se añade el nombre de |usuario al nombre por omisión para que varios usuarios en el mismo sistema puedan |crear sus propias antememorias por omisión.

| |

### Utilización de SharedClassPermissions

|

Si un SecurityManager se está utilizando junto con el compartimiento |de clases y la aplicación en ejecución utiliza sus propios cargadores de |clases, éstos deben obtener SharedClassPermissions antes de que puedan |compartir clases. Debe añadir SharedClassPermissions |al archivo java.policy utilizando el nombre de clase del cargador de |clases (se pueden utilizar comodines) y "read", "write" o "read,write" |para determinar el acceso otorgado. Por ejemplo:

|

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

Si un cargador de clases no tiene el SharedClassPermission correcto |e intenta compartir clases, se generará una excepción AccessControlException. |No puede cambiar o reducir los permisos de los cargadores de clases de la |extensión, la aplicación o la rutina de carga.

| |

## Adaptación de cargadores de clases personalizados para compartir clases

|

La mayoría de aplicaciones Java utilizarán los propios cargadores de clases de la |VM o tendrán cargadores de clases personalizados que amplíen |java/net/URLClassLoader. Las aplicaciones que utilicen estos cargadores de |clases podrán compartir clases de rutina de carga y de aplicación |automáticamente. Los cargadores de clases |personalizados que no amplíen java/net/URLClassLoader requerirán modificaciones para |poder utilizar el compartimiento de clases. Todos los cargadores de clases |personalizados deberán obtener SharedClassPermissions si se está |utilizando un SecurityManager; para ello, consulte |Utilización de SharedClassPermissions. IBM proporciona |varias interfaces Java para los distintos tipos de cargadores de clases |personalizados, que permiten a los cargadores de clases buscar y almacenar |clases en la antememoria de clases compartidas. |Estas clases están en el paquete com.ibm.oti.shared. El Javadoc para este |paquete se suministra con el SDK en el archivo docs/apidoc.zip. Consulte la guía |Diagnostics Guide para obtener más información |sobre cómo utilizar estas interfaces.

# Servicio y soporte de proveedores de software independientes

Si tiene el derecho de servicios del código de programa según se establece en IBM Solutions Developer Program, póngase en contacto con IBM Solutions Developer Program a través de su método normal de acceso o en la Web en: http://www-1.ibm.com/partnerworld/.

Si ha adquirido un contrato de servicio (por ejemplo, la Línea de soporte de IBM Personal Systems o un servicio equivalente por país), los términos y condiciones de ese contrato de servicio determinan qué servicios, si existen, tiene derecho a recibir de acuerdo con el programa.

# Accesibilidad

Las Guías del usuario que se suministran con este SDK y el Runtime Environment se han probado utilizando lectores de pantalla. Puede utilizar un lector de pantalla como Home Page Reader o el lector de pantalla JAWS con estas Guías del usuario.

Para cambiar los tamaños de font en las Guías del usuario, utilice la función que se proporciona con el navegador, que normalmente se encuentra en la opción de menú Ver.

Los usuarios que necesiten el desplazamiento mediante teclas pueden consultar la descripción de las pulsaciones más útiles para las aplicaciones Swing en "Swing Key Bindings" (Enlaces de teclas de Swing) en http://www-128.ibm.com/developerworks/java/jdk/additional/

## Accesibilidad de iKeyman

|Además de la GUI, la herramienta iKeyman proporciona la |herramienta de línea de mandatos IKEYCMD, que tiene |las mismas funciones que la GUI de iKeyman. IKEYCMD permite |gestionar claves, certificados y peticiones de certificado. Puede invocar |IKEYCMD desde scripts de shell nativos y desde los programas |que se utilizan cuando las aplicaciones necesitan añadir interfaces personalizadas a |las tareas de gestión de claves y certificados. |IKEYCMD puede crear archivos de base de datos de claves para |todos los tipos que admite actualmente iKeyman. IKEYCMD |también puede crear peticiones de certificado, importar certificados firmados por CA |y gestionar certificados autofirmados.

Para ejecutar un mandato IKEYCMD, entre:

    java
    [-Dikeycmd.properties=<archivo de propiedades>]com.ibm.gsk.ikeyman.ikeycmd
    <objeto> <acción> [opciones]

donde:

<objeto>
  es uno de los siguientes:
  -keydb
    Las acciones que se realizan en la base de datos de claves (ya sea un archivo de base de datos de claves CMS, un archivo de conjunto de claves WebDB o una clase SSLight)
  -cert
    Acciones que se van a llevar a cabo en un certificado de una base de claves
  -certreq
    Acciones que se van a llevar a cabo en una petición de certificado de una base de datos de claves
  -version
    Muestra información de versión de IKEYCMD
  -help
    Muestra la ayuda de las invocaciones de IKEYCMD.
<acción>
  |La acción específica que se va a llevar a cabo en el objeto. |Para ver las acciones disponibles para un objeto, invoque |IKEYCMD pasando sólo el objeto como argumento. La |ayuda sensible al contexto se mostrará indicando las acciones |disponibles para ese objeto.
-Dikeycmd.properties
  Especifica el nombre de un archivo de propiedades opcional que se utiliza en esta invocación Java. Se proporciona un archivo de propiedades por omisión, ikeycmd.properties, como archivo de ejemplo que cualquier aplicación Java puede cambiar y utilizar.

Nota:
Las palabras claves de objeto y acción deben aparecer en la secuencia especificada. No obstante, las opciones no son posicionales y pueden estar en cualquier secuencia, siempre que se especifiquen como un par de opción y operando.

Para obtener más información, consulte la Guía de usuario de iKeyman en: http://www.ibm.com/developerworks/java/jdk/security/index.html.

## Recorrido del teclado de componentes JComboBox en Swing

Si recorre la lista desplegable de un componente JComboBox con las teclas del cursor, el botón o el campo editable del recuadro combinado no cambia de valor hasta que se selecciona un elemento. Este es el comportamiento deseado para este release, ya que mejora la accesibilidad y la utilización, al garantizar que el comportamiento del recorrido del teclado sea coherente con el comportamiento del recorrido del ratón.

## (Sólo para Linux IA de 32 bits, PPC32 y PPC64) Accesibilidad de Web Start

IBM Java Web Start v5.0 contiene varias mejoras de accesibilidad y utilización con respecto al release anterior, incluido un soporte mejorado de lectores de pantalla y un desplazamiento mediante teclas optimizado.

Puede utilizar la línea de mandatos sólo para iniciar una aplicación Java habilitada para Web Start. Para cambiar las opciones de preferencias, debe editar un archivo de configuración, .java/.deployment/.deployment.properties en el directorio local del usuario. Realice una copia de seguridad antes de editar este archivo. No todas las preferencias que se pueden establecer en el Visor de antememoria de aplicaciones Java están disponibles en el archivo de configuración.

# Limitaciones conocidas

Los apartados siguientes explican las limitaciones conocidas del SDK y Runtime Environment para Linux.

## Limitaciones aplicables a todas las plataformas Linux excepto donde se indique

- |Es posible que el administrador de ventanas altere |temporalmente algunos de los accesos directos de teclado Java. Si es |necesario que utilice un acceso directo de teclado Java alterado |temporalmente, consulte el manual del sistema operativo y modifique los |accesos directos de teclado del administrador de ventanas. |

- |El Sistema X Windows no puede utilizar los descriptores de |archivo por encima de 255. Como la JVM contiene descriptores de |archivo para archivo jar abiertos, X puede ejecutarse fuera de los |descriptores de archivo. Como solución, puede establecer la variable de |entorno JAVA_HIGH_ZIPFDS para que indique a la JVM |que utilice un número mayor de descriptores de archivo para los archivos |jar. |

  Para utilizar la variable de entorno JAVA_HIGH_ZIP, |establézcala en un valor entre 0 y 512. La JVM abrirá los primeros |archivos jar utilizando los descriptores de archivos hasta 1024. Por ejemplo, |si el programa puede cargar 300 archivos jar:

  `export JAVA_HIGH_ZIPFDS=300` |

  Los 300 primeros archivos jar se cargarán utilizando los |descriptores de archivo desde 724 a 1023. Cualquier archivo jar abierto |posteriormente, se abrirá en el rango normal.

- Es posible que no pueda utilizar el portapapeles del sistema con juegos de caracteres de doble byte (DBCS) para copiar información entre las aplicaciones Linux y Java si está ejecutando K Desktop Environment (KDE).

- En RHEL3, SLES9 y distribuciones más recientes, la biblioteca de hebras por omisión es NPTL, que implementa hebras Java como hebras nativas. En distribuciones anteriores, la biblioteca de hebras por omisión es LinuxThreads, que implementa hebras como procesos nuevos. Si el número de hebras Java sobrepasa el número máximo de procesos permitidos, puede que el programa se cuelgue.

  El número máximo de hebras disponibles está determinado por el valor más pequeño de:

  - El valor de procesos del usuario (ulimit -u) en /etc/security/limits.conf
  - El límite que está definido en /proc/sys/kernel/threads_max
  - El límite PTHREAD_THREADS_MAX definido en libpthreads.so (cambiar este valor requiere volver a compilar glibc)

  Sin embargo, puede que agote el almacenamiento virtual antes de llegar al número máximo de hebras.

- Si termina una aplicación Java con Control-C, es posible que algunos procesos queden huérfanos.

- Los resultados de KeyEvent que incluyan la tecla ALT son diferentes cuando se utilizan administradores de ventanas distintos en Linux. También serán diferentes de los resultados obtenidos en otros sistemas operativos. En el administrador de ventanas Enlightenment, Alt+A y Mayús+Alt+A generan modificadores distintos y Control+Alt+A no genera ningún suceso de teclas. Sin embargo, si se utiliza el administrador de ventanas WindowMaker, Control+Alt+A genera un suceso de teclas.

- En el sistema X Window de Linux, la correlación de teclado está establecida en: 64 0xffe9 (Alt_L) 0xffe7 (Meta_L) y 113 0xffea (Alt_R) 0xffe8 (Meta_R). Puede comprobarlo escribiendo lo siguiente en el indicador de shell:

      xmodmap -pk

  Este es el motivo por el cual el SDK para Linux considera que se ha pulsado Meta + Alt simultáneamente. Como solución provisional, puede eliminar la correlación Meta_x escribiendo lo siguiente en el indicador de shell:

      xmodmap -e "keysym Alt_L = Alt_L" -e "keysym Alt_R = Alt_R"

  Nota:
  Esta solución provisional puede afectar a otras aplicaciones X-Window que se ejecuten en la misma pantalla si utilizan la misma Meta-tecla que se ha eliminado.

- La creación de pares de claves DSA de longitudes inusuales puede tardar una cantidad de tiempo considerable en las máquinas lentas. El retardo no debe interpretarse como que se ha colgado porque el proceso se completará si se le deja el tiempo suficiente. El algoritmo de generación de claves DSA se ha optimizado para generar longitudes de claves estándar (por ejemplo, 512, 1024) más rápidamente que otras.

- Los programas nativos no pueden crear una VM con interfaces JNI_VERSION_1_1(0x00010001). No puede llamar a JNI_CreateJavaVM() y pasar una versión de JNI_VERSION_1_1(0x00010001). Las versiones que se pueden pasar son:
  - JNI_VERSION_1_2(0x00010002)
  - JNI_VERSION_1_4(0x00010004)

  La VM creada viene determinada por las bibliotecas Java presentes (es decir, 1.2.2, 1.3.x, 1.4.x, 5.x), no la indicada por la versión pasada de la interfaz JNI.

  La versión de la interfaz no afecta al comportamiento de la VM salvo a las funciones disponibles para el código nativo.

- Una llamada a JNI_CreateJavaVM() desde una aplicación JNI puede provocar un error de segmentación (SIGSEGV de señal); para evitar este error, vuelva a crear el programa JNI especificando la opción -lpthread.

- Sólo para usuarios de chino tradicional, las teclas de función Intro, Espacio, Retroceso y Escape no funcionan como se espera cuando se utilizan los IME LinYi ZhuYin, YiTian ZhuYin y Bosham para la entrada de caracteres TCH. La tecla Intro inserta una nueva línea, la tecla Escape se utiliza para cancelar las series editadas previamente o la ventana candidata, y la Barra espaciadora inserta un espacio. La ventana candidata deberá desaparecer después de pulsar la tecla consignada y no deberá aparecer al pulsar la tecla Retroceso mientras se utilizan los IME LinYi ZhuYin, YiTian ZhuYin y Bosham para la entrada de caracteres chinos tradicionales.

- Si durante la ejecución utiliza gran cantidad de hebras concurrentes, puede aparecer un mensaje de aviso: `java.lang.OutOfMemoryError`. Esto indica que la máquina se queda sin recursos del sistema y los mensajes pueden venir provocados por las razones siguientes:
  1. No pueden crearse nuevas hebras porque:
     - El número de procesos creados supera el límite del usuario. (Si la instalación de Linux utiliza LinuxThreads en lugar de NPTL).
     - No hay recursos del sistema suficientes para crear nuevas hebras. En este caso, podrían aparecer también otras excepciones Java, dependiendo sobre qué se esté ejecutando la aplicación.
  2. Se agota la memoria del kernel o está fragmentada. Puede ver los mensajes correspondientes de Memoria agotada del kernel en /var/log/messages que tiene el ID de proceso en que se ha ejecutado kill.
  Intente ajustar el sistema para aumentar los recursos del sistema correspondientes.

- Durante la instalación, si ya ha instalado una versión anterior de este producto distribuido por Red Hat, Red Hat Package Manager (RPM) informará que el paquete de IBM es más antiguo que cualquiera de las versiones del producto distribuidas por Red Hat. Esta situación se produce porque Red Hat añade un "número de serie" al paquete de RPM que altera el esquema de versiones del producto en el paquete y, por omisión, RPM rechaza instalar un paquete que parece ser más antiguo que el que ya está instalado. La opción --oldpackage del mandato rpm le permite instalar el nuevo paquete de IBM.

- Cuando se ejecuta una aplicación Java AWT/Swing en una máquina Linux y exporta la pantalla a una segunda máquina, puede tener problemas al visualizar algunos diálogos si el conjunto de fonts cargado en la máquina cliente X es diferente del conjunto cargado en la máquina servidor X. Este problema es evidente en especial con SLES8 en entornos locales chinos, en los que la instalación por omisión de la versión del servidor instala fonts arphic, pero no así en la instalación por omisión del cliente. Para evitar este problema, instale los mismos fonts en ambas máquinas.

- Si el entorno local de su sistema utiliza codificación UTF-8, algunas herramientas del SDK pueden generar una sun.io.MalformedInputException. Para determinar si el sistema está utilizando codificación UTF-8, examine las variables de entorno específicas del entorno local como LANG o LC_ALL para ver si terminan con el sufijo ".UTF-8". Si se produce esta sun.io.MalformedInputException, cambie los caracteres que no estén dentro del rango ASCII de 7 bits (0x00 - 0x7f) y que no estén representados como literales de caracteres Unicode de Java por literales de caracteres Unicode de Java (por ejemplo: '\u0080'). También puede solucionar este problema eliminando el sufijo ".UTF-8" de las variables de entorno específicas del entorno local; por ejemplo, si la máquina tiene el entorno local por omisión "en_US.UTF-8", establezca LANG en "en_US".
  Nota:
  Algunas distribuciones de Red Hat, incluidas Red Hat 9 y RHEL3, utilizan por omisión la codificación UTF-8.

- Si utiliza AMI y xcin en un entorno de plataforma cruzada (por ejemplo, si intenta exportar la pantalla entre un sistema de 32 bits y uno de 64 bits, o entre un sistema big-endian y un little-endian) pueden producirse algunos problemas. Si tienes este tipo de problema, póngase en contacto con el distribuidor de Linux.

- En Red Hat Enterprise Linux 3, es posible que los caracteres chinos no se muestren en componentes de texto AWT excepto los caracteres GB2312 en el entorno local GB18030 chino.

- |En la herramienta JConsole de IBM, la pestaña |Local que permite conectarse con otras máquinas |virtuales del mismo sistema no está disponible. En su lugar, utilice la |pestaña Remota de la JConsole para conectarse con la |máquina virtual que desee supervisar. Cuando inicie la aplicación que |desee supervisar, establezca las opciones de línea de mandatos: |
  |
  - -Dcom.sun.management.jmxremote.port=<valor> para especificar el |puerto en el que debe escuchar el agente de gestión.
  |
  - -Dcom.sun.management.jmxremote.authenticate=false para inhabilitar la |autenticación a menos que haya creado un archivo de nombre de usuario.
  |
  - -Dcom.sun.management.jmxremote.ssl=false para inhabilitar el cifrado |SSL.
  |

- |Para los usuarios de los idiomas Chino, Coreano y Japonés |de Red Hat Enterprise Linux 4 sólo, si está utilizando IIIMF |(Internet/Intranet Input Method Framework), utilice los paquetes IIIMF que |se incluyen en Red Hat Enterprise Linux 4 Actualización 2 o posterior. |Asimismo, tenga en cuenta el siguiente problema. Si lo experimenta, |póngase en contacto con Red Hat para obtener instrucciones en |http://www.redhat.com . |
  |
  - En Linux zSeries de 64, es posible que experimente anomalías de IIIMF |o una anomalía al iniciarse. Consulte Red Hat Bugzilla número RIT73533 |para los usuarios japoneses sólo.
  |

- |Para usuarios del idioma chino simplificado de Red Hat |Enterprise Linux 4 sólo. El entorno local zh_CN.GB18030 no está soportado |por xlib en RHEL4. xterm no puede activar el método de entrada para la |entrada de los caracteres GB18030. Utilice el entorno local |zh_CN.UTF8 en su lugar. Si tiene programas heredados o datos codificados |con GB2312, GBK, o GB18030 y desea migrarlos a RHEL4, debe procesarlos |previamente con iconv para convertirlos a la codificación utf-8 de modo que |los programas puedan ejecutarse y los datos puedan visualizarse |correctamente en RHEL4 con el entorno local zh_CN.UTF8. |

- |En RHEL 3, con miniChinput (servidor XIM de chino |simplificado) en entorno de 64 bits como, por ejemplo, las plataformas |AMD64 o zSeries de 64 bits, es posible que experimente un comportamiento |inesperado con Java. Póngase en contacto con Red Hat para obtener |instrucciones en http://www.redhat.com. |Consulte Red Hat Bugzilla número RIT75701. |

- |En RHEL 3, con ami (servidor XIM de coreano), es posible |que experimente un comportamiento imprevisto con Java en los entornos de |64 bits como, por ejemplo, las plataformas AMD64 o zSeries de 64 bits. |Póngase en contacto con Red Hat para obtener instrucciones en | http://www.redhat.com. Consulte Red Hat |Bugzilla números RIT73605 y RIT75708. |

- |En RHEL 4, con xcin (servidor XIM de chino tradicional), |es posible que experimente un comportamiento imprevisto como, por ejemplo, |un error de segmentación con Java en los entornos de 64 bits, por ejemplo, |las plataformas AMD64 o zSeries de 64 bits. Póngase en contacto con Red |Hat para obtener instrucciones en |http://www.redhat.com. |Consulte Red Hat Bugzilla número RIT78430. |

- |Para los usuarios de los idiomas japonés, chino y coreano, no puede |utilizar XIM para la entrada de sus propios caracteres en componentes de |texto de un applet Java de un explorador Web. Estas limitaciones ocurren |porque XEmbed requiere un arreglo para el archivo de biblioteca X11. Para |evitar esta situación, especifique el parámetro de sistema |-Dsun.awt.noxembed=true para inhabilitar XEmbed. |Puede establecer esta opción utilizando el panel de control. |
  |
  1. Abra el panel de control de Java Plug-in y vaya a la pestaña |Java.
  |
  2. Pulse el botón Ver que aparece en los Valores de |Java Applet Runtime.
  |
  3. Entre -Dsun.awt.noxembed=true en los Parámetros |de Runtime de Java y pulse Aceptar.
  |
  4. Pulse Aplicar
  |
  5. Inicie un servidor.
  |

## Limitaciones de Linux IA de 32 bits

- Para los usuarios de textos árabes, cuando se utiliza Linux con una tarjeta de vídeo Matrox y la aceleración habilitada, pueden verse caracteres distorsionados cuando se utiliza drawString para mostrar fonts grandes. Este problema está causado por el controlador de esas tarjetas. La solución provisional sugerida es inhabilitar la aceleración del dispositivo.

- En SLES 9 NPTL, el controlador del puerto paralelo provoca un error del kernel y echa abajo una hebra Java. La JVM detecta este error cuando intenta suspender la hebra para la recopilación de desechos y provoca un error produciendo un archivo de imagen de memoria y el mensaje "JVMLH030: threads are disappearing when trying to suspend all threads".

  Se ha creado el informa 47947 de SUSE Bugzilla para solucionar este problema. Este error se ha arreglado en SLES 9 Service Pack 1.

## Limitaciones de Linux AMD64

| |
- Nota importante sobre los valores de BIOS en los sistemas AMD64 |SMP: |

  El valor de BIOS Node memory interleaving debe |establecerse en `DISABLED`. De lo contrario, se pueden producir errores |imprevisibles como, por ejemplo, que Java se cuelgue o termine anormalmente. Esta |instrucción está de acuerdo con la recomendación de AMD.

## Limitaciones de Linux PPC de 32 bits y 64 bits

- Si su código Java realiza llamadas a la JNI y alguna llamada específica tiene más de ocho parámetros flotantes o dobles, el código C debe compilarse con el nivel gcc-2.95.3 Free Software Foundation (FSF) de GNU C Compiler (GCC).

- Si ejecuta XFree86 versión 3.x, puede recibir un error SIGSEGV error. Para evitar este problema, se recomienda utilizar XFree86 versión 4.x.

- Si se establece una fecha anterior a 1970, se produce un error de excepción cuando se intenta iniciar Java. Para solucionar provisionalmente este problema, establezca manualmente la fecha actual de la máquina.

- El paquete JavaComm no puede soportar las operaciones de puerto paralelo en los kernels SLES 9 GA y SP1. Esta limitación está resuelta en el kernel SP2. El número de SUSE Bugzilla es 50028.

- Debido a una función IOCTL no implementada en la modalidad de 32 bits del kernel de 64 bits, JavaComm no puede soportar las operaciones de puerto serie en SLES 9 y RHEL 4. Esta limitación está resuelta en SLES 9 SP2 (número de Bugzilla 49787) y en RHEL 4 actualización 1 (número de Bugzilla 144904).

## Limitaciones de Linux PPC de 64 bits

- El compilador cruzado gcc por omisión (versión 3.2-49) provoca varios errores. Para generar la biblioteca compartida libFileStat.so, ejecute `/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so -I<Vía_SDK>/include FileStat.c` donde `<Vía_SDK>` es la vía de acceso del directorio del SDK instalado.

## Limitaciones de Linux zSeries de 64 bits

Las siguientes limitaciones se aplican a los usuarios del idioma chico y taiwanés en Linux zSeries de 64 bits:

- El servidor de métodos de entrada (xcin) chino y taiwanés no se ha comprobado con la Versión 5.0.

## Limitaciones de Linux zSeries de 31 y 64 bits

- Si utiliza audio en una máquina sin una tarjeta de sonido, puede producirse un mensaje de error que indica que no hay memoria cuando Java intenta reproducir un sonido. El mensaje se muestra en la consola, pero no afecta a la aplicación Java.

- Aunque el kernel de Linux de las distribuciones actuales proporciona soporte para el protocolo de Internet versión 6 (IP6), puede encontrarse con problemas al utilizarlo. El soporte de IP6 por parte de Java está incluido en este release, pero se recomienda desactivar el soporte con la opción -Djava.net.preferIPv4Stack=true del mandato Java. Si instala un kernel que soporte completamente IP6, no necesita esta opción.

- |Si está usando Java para zSeries de 31 ó 64 bits con un |servidor X utilizando un valor de alta resolución, es posible que |aparezcan cortados los fonts de glifos de un componente AWT Choice con |Motif AWT. Para evitar esta situación, reduzca el valor de resolución |o utilice XAWT en lugar de Motif AWT. |

# Comentarios sobre esta Guía del usuario

Si tiene algún comentario acerca de la utilidad, o no utilidad, de esta Guía del usuario, estaremos encantados de conocer su opinión a través de uno de estos canales. Tenga en cuenta que estos canales no están destinados a responder consultas técnicas, sólo son para comentarios acerca de documentación. Envíe sus comentarios:

- Por correo electrónico a idrcf@hursley.ibm.com.
- Por fax:
  - Desde el Reino Unido: 01962 842327
  - Desde otro lugar:<código internacional>44 1962 842327
- Por correo a:
  IBM United Kingdom Ltd
  User Technologies,
  Mail Point 095
  Hursley Park
  Winchester
  Hampshire
  SO21 2JN Reino Unido

La letra pequeña. Si elige enviar un mensaje a IBM, acepta que toda la información contenida en su mensaje, incluidos los datos de respuesta, como preguntas, comentarios, sugerencias, etc., se considerarán no confidenciales e IBM no tendrá ningún tipo de obligación sobre dicha información y será libre de reproducir, utilizar, revelar y distribuir la información a otros sin limitaciones. Además, IBM será libre de utilizar cualquier idea, concepto, conocimiento o técnica contenido en dicha información para cualquier tipo de propósito, incluyendo, pero sin limitarse al desarrollo, fabricación y marketing de productos que incluyan dicha información.

# Avisos

Esta información se ha desarrollado para productos y servicios que se ofrecen en los EE.UU. IBM puede que no ofrezca los productos, servicios o características que se discuten en este documento en otros países. Consulte a su representante local de IBM para obtener información acerca de los productos y servicios actualmente disponibles en su zona. Cualquier referencia a un producto, programa o servicio de IBM no pretende afirmar ni implica que sólo se pueda utilizar dicho producto, programa o servicio de IBM. En su lugar, puede utilizarse cualquier producto, programa o servicio funcionalmente equivalente que no infrinja ninguno de los derechos de propiedad intelectual de IBM. Sin embargo, la evaluación y la verificación del funcionamiento conjuntamente con otros productos, programas o servicios que no son de IBM es responsabilidad del usuario.

IBM puede tener aplicaciones patentadas o pendientes de patente que cubran el tema tratado en este documento. La posesión de este documento no le otorga ninguna licencia sobre estas patentes. Puede enviar consultas de licencias por escrito a la dirección siguiente:

- IBM Director of Licensing
  IBM Corporation
  North Castle Drive, Armonk
  NY 10504-1758 EE.UU.

Para consultas de licencias relacionadas con la información de doble byte (DBCS), póngase en contacto con el Departamento de la propiedad intelectual de IBM de su país o envíe las consultas por escrito a la dirección siguiente:

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

El párrafo siguiente no se aplica al Reino Unido ni a cualquier otro país en el que tales disposiciones sean incoherentes con la legislación nacional:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL" SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLICITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN, COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunos estados no contemplan la limitación de responsabilidades, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no sea aplicable en su caso.

Esta información puede contener imprecisiones técnicas o errores tipográficos. Periódicamente se realizarán modificaciones en la información aquí contenida; dichos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta información en cualquier momento y sin previo aviso.

Cualquier referencia hecha en esta información a sitios Web que no son de IBM se proporciona únicamente para su comodidad y no debe considerarse en modo alguno como promoción de dichos sitios Web. Los materiales de estos sitios Web no forman parte de los materiales de IBM para este producto y el uso que se haga de estos sitios Web es de la entera responsabilidad del usuario.

IBM puede utilizar o distribuir la información que facilite de la manera que considere apropiada sin incurrir en obligaciones con el remitente.

Los poseedores de la licencia de este programa que deseen obtener información acerca del mismo con el propósito de permitir (i) el intercambio de información entre programas creados independientemente y otros programas (incluido éste) y (ii) la utilización mutua de la información intercambiada, deben ponerse en contacto con la dirección siguiente:

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

Esta información estará disponible, sujeta a los términos que correspondan, lo que en algunos casos incluirá el pago de una cuota.

IBM proporciona el programa con licencia descrito en este documento y todo el material con licencia disponible para el mismo bajo los términos del Acuerdo de cliente de IBM, el Acuerdo internacional de licencia de programas IBM o cualquier acuerdo equivalente entre las dos partes.

Cualquier información acerca del rendimiento que contenga el presente documento se ha determinado en un entorno controlado. Por lo tanto, los resultados obtenidos en otros entornos operativos pueden variar significativamente. Es posible que algunas medidas se hayan tomado en sistemas de nivel de desarrollo y no hay garantías de que estas medidas serán iguales en los sistemas habitualmente disponibles. Asimismo, algunas mediciones pueden haber sido estimadas mediante la extrapolación. Los resultados reales pueden variar. Los usuarios de este documento deben verificar los datos aplicables para su entorno específico.

La información relativa a productos que no son de IBM se ha obtenido de los proveedores de estos productos, de los anuncios públicos o de otras fuentes disponibles públicamente. IBM no ha probado esos productos y no puede confirmar la precisión del rendimiento, su compatibilidad o cualquier otra afirmación relacionada con productos que no son de IBM. Las preguntas sobre las posibilidades de los productos que no son de IBM deben dirigirse a los proveedores de dichos productos.

## Marcas registradas

IBM, iSeries, pSeries y zSeries son marcas registradas de International Business Machines Corporation en los Estados Unidos y/o en otros países.

Intel es una marca registrada de Intel Corporation en los Estados Unidos y/o en otros países.

Java y todas las marcas y logotipos basados en Java son marcas comerciales o marcas registradas de Sun Microsystems, Inc. en los Estados Unidos y/o en otros países.

Linux es una marca registrada de Linus Torvalds en los Estados Unidos y/o en otros países.

Otros nombres de empresas, productos o servicios pueden ser marcas registradas o de servicio de otros.

Este producto también está basado en parte del trabajo de FreeType Project. Para obtener más información sobre Freetype, consulte http://www.freetype.org.

Este producto incluye software desarrollado por Apache Software Foundation http://www.apache.org/.