IBM SDK para plataformas Linux, Java Technology Edition, Versión 6

Guía de SDK y Runtime

Versión 6 Release 0

Copyright International Business Machines Corporation 2003, 2007. Reservados todos los derechos.

Contenido

Prefacio
Visión general
Convenios
Compatibilidad de versiones
Migración desde otras IBM JVM
Hardware soportado para System z
Contenido de SDK y Runtime Environment
Clases y herramientas de Runtime Environment
Herramientas e información de referencia de SDK
Instalación y configuración del SDK y Runtime Environment
Actualización del SDK
Instalación en Red Hat Enterprise Linux (RHEL) 4
Instalación en Red Hat Enterprise Linux (RHEL) 5
Ejecución de Java con SELinux en RHEL 5
Instalación de un SDK de 32 bits en una arquitectura de 64 bits
Instalación desde un archivo RPM
Instalación desde un archivo .tgz
Utilización de un formato compatible con JPackage
Configuración del SDK y Runtime Environment para Linux
Configuración de la vía de acceso
Establecimiento de la vía de acceso de clases
Desinstalación del SDK y Runtime Environment para Linux
Desinstalación del paquete RPM (Red Hat Package Manager)
Desinstalación del paquete comprimido TAR (Tape Archive)
Ejecución de aplicaciones Java
Los mandatos java y javaw
Obtención de la información de versión
Especificación de opciones Java y propiedades del sistema
Opciones estándar
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 recogida de basura
Opciones de recogida de basura
Tiempo de pausa
Reducción del tiempo de pausa
Entornos con almacenamientos dinámicos muy llenos
Soporte del símbolo de Euro
Archivos de configuración de font de reserva
| |
Utilización de los métodos de entrada de India y Tailandia
Utilización del SDK para desarrollar aplicaciones Java
| |
Utilización de XML
| |
Migración a XL-TXE-J
| |
Información de referencia XML
Depuración de aplicaciones Java
JDB (Java Debugger)
Cómo determinar si la aplicación se está ejecutando en una JVM de 32 bits o de 64 bits
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
Cómo escribir aplicaciones JNI
Soporte para recuperación a nivel de hebra de conectores bloqueados
Configuración de la asignación de memoria con páginas grandes
Soporte CORBA
Propiedades del sistema para rastrear el ORB
Propiedades del sistema para ajustar el ORB
Permisos de seguridad Java 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
BigDecimal mejorado
Plug-in, Applet Viewer y Web Start
(Sólo Linux IA de 32 bits y PPC32) Utilización del Plug-in Java
Navegadores soportados
Instalación y configuración del plug-in Java
Soporte de DOM (Document Object Model) común
Utilización de parámetros DBCS
Trabajo con applets
Ejecución de applets con el Visor de applets
Depuración de applets con el Visor de applets
(Sólo Linux IA de 32 bits, PPC32 y PPC64) Utilización de Web Start
Ejecución de Web Start
(Sólo Linux IA de 32 bits) WebStart Secure Static Versioning
Envío de aplicaciones Java
Datos de clases compartidos entre las JVM
Visión general de la función de compartir datos de clases
Habilitación y configuración de la función de compartir datos de clases
Cómo crear, llenar, supervisar y suprimir una memoria caché
Rendimiento y consumo de memoria
Consideraciones y limitaciones a la hora de utilizar la función de compartir datos de clases
Límites del tamaño de la memoria caché
Modificación del código bytecode en el tiempo de ejecución
Limitaciones del sistema operativo
Utilización de SharedClassPermission
Adaptación de cargadores de clases personalizados para compartir clases
Utilización de la API Java Communications (JavaComm)
Instalación de la API Java Communications desde un archivo comprimido
Instalación de la API Java Communications desde un archivo RPM
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
Especificación de dispositivos en el archivo javax.comm.properties
Habilitación de puertos serie en IBM ThinkPads
Limitación de la impresión con la API Java Communications
Desinstalación de la API Java Communications
Desinstalación del paquete RPM (Red Hat Package Manager)
Desinstalación del paquete comprimido TAR (Tape Archive)
Documentación de la API Java Communications
Servicio y soporte de proveedores de software independientes
Accesibilidad
Recorrido del teclado de componentes JComboBox en Swing
Accesibilidad de Web Start (sólo Linux IA de 32 bits PPC32 y PPC64)
Comentarios sobre esta guía del usuario
Apéndice A. Opciones no estándar
Apéndice B. Limitaciones conocidas
Avisos
Marcas registradas

Prefacio

Esta guía del usuario proporciona información general sobre IBM SDK y Runtime Environment para plataformas Linux, Java Technology Edition, Versión 6 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 en las que se han comprobado SDK y Runtime Environment paraLinux, consulte: http://www-106.ibm.com/developerworks/java/jdk/linux/tested.html.

(Sólo plataformas Intel de 32 bits) Se da soporte a estos entornos virtuales:

La Guía de diagnósticos proporciona información más detallada acerca de IBM Virtual Machine para Java.

Esta guía del usuario forma parte de un release y sólo se puede aplicar a dicho release en concreto. Asegúrese de que tiene la guía del usuario correspondiente al release que está utilizando.

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 de esta versión de la guía del usuario, que no sean cambios menores u obvios, se indican en azul cuando se visualizan en un Information Center, en rojo con barras verticales situadas a la izquierda de los cambios |cuando se visualizan en HTML, o bien en una copia impresa en color o mediante barras verticales situadas a la izquierda de los cambios cuando se visualizan como PDF.

El código del programa no está diseñado para su uso en aplicaciones de tiempo real, como por ejemplo, en el control en línea de aviones, tráfico aéreo, navegación aérea o comunicaciones de transporte aéreo ni tampoco en el diseño, construcción, operación o mantenimiento de complejos nucleares, entre otras.

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

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

Runtime Environment contiene Java Virtual Machine y archivos de soporte, incluidos los archivos .so no depurables y de clases. 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 los programas Java. Runtime Environment para Linux no incluye ninguna de las herramientas de desarrollo como, por ejemplo, appletviewer o el compilador Java (javac), o clases que únicamente sean para sistemas de desarrollo.

Asimismo, para las plataformas IA32, PPC32/PPC64 y AMD64/EM64T, se proporciona el paquete de la interfaz de programación de aplicaciones (API) Java Communications para utilizarlo junto con Runtime Environment para Linux. Puede encontrar información acerca del mismo en el Utilización de la API Java Communications (JavaComm).

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

Convenios

En esta guía del usuario se hace referencia al directorio de instalación predeterminado del SDK como /opt/ibm/java-i386-60/. Si no está utilizando Linux IA de 32 bits, el directorio de instalación predeterminado será distinto.

Las plataformas que se listan a continuación tienen directorios de instalación predeterminados diferentes; cuando vea /opt/ibm/java-i386-60/, sustitúyalo por el directorio de la plataforma que esté utilizando:

En esta guía del usuario se utilizan mandatos del shell Korn.

Compatibilidad de versiones

En general, cualquier applet o aplicación que se haya ejecutado con una versión anterior de SDK debería ejecutarse correctamente con IBM SDK para Linux, v6. No se garantiza que las clases compiladas con este release funcionen en releases anteriores.

Para obtener información sobre los problemas de compatibilidad entre releases, consulte el sitio web de Sun en:

|http://java.sun.com/javase/6/webnotes/compatibility.html

http://java.sun.com/j2se/5.0/compatibility.html

http://java.sun.com/j2se/1.4/compatibility.html

http://java.sun.com/j2se/1.3/compatibility.html

Si utiliza el SDK como parte de otro producto (por ejemplo, IBM WebSphere Application Server) y realiza una actualización desde un nivel anterior del SDK, quizá v5.0, es posible que las clases serializadas no sean compatibles. No obstante, las clases sí son compatibles entre renovaciones de servicio.

Migración desde otras IBM JVM

A partir de la versión 5.0, the IBM Runtime Environment paraLinux contiene versiones nuevas de IBM Virtual Machine para Java y el compilador JIT (Just-In-Time).

Si va a migrar desde un IBM Runtime Environment anterior, tenga en cuenta que:

Hardware soportado para System z

Los SDK y Runtime Environments de 31 bits y 64 bits para System z se ejecutan en hardware de System z9 y zSeries.

Los SDK y Runtime Environments se ejecutan en los servidores siguientes o equivalentes:

Contenido de SDK y Runtime Environment

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

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

Las guías del usuario, Javadoc, y los archivos de licencia, copyright, javadoc y el directorio demo son la única documentación incluida 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, http://java.sun.com.

Clases y herramientas de Runtime Environment

Una lista de las clases y herramientas que puede utilizar con Runtime Environment estándar.

Herramientas e información de referencia de SDK

Con el SDK estándar se incluye una lista de herramientas e información de referencia.

Las siguientes herramientas forman parte del SDK y se encuentran en el directorio /opt/ibm/java-i386-60/bin:
appletviewer (Visor de applets de Java)
Prueba y ejecuta applets fuera de un navegador web.
apt (Herramienta de proceso de anotaciones)
Busca y ejecuta los procesadores de anotaciones basándose en las anotaciones existentes en el conjunto de archivos de origen especificado que se está examinando.
extcheck (Programa de utilidad Extcheck)
Detecta conflictos de versión entre un archivo jar de destino y archivos jar de ampliación instalados actualmente.
(Sólo Linux IA de 32 bits, PPC32 y PPC64)HtmlConverter (Conversor HTML del plug-in Java)
Convierte una página HTML que contiene applets en un formato que puede utilizar el plug-in Java.
idlj (Compilador IDL a Java)
Genera enlaces Java desde un archivo IDL determinado.
ikeycmd (Programa de utilidad de la línea de mandatos iKeyman)
Permite gestionar claves, certificados y peticiones de certificado desde la línea de mandatos. Para obtener más información, consulte la Guía de seguridad y el sitio http://www.ibm.com/developerworks/java/jdk/security.
jar (Herramienta de archivo Java)
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.
java-rmi.cgi (herramienta de envío de peticiones de HTTP a CGI)
Acepta las peticiones RMI sobre HTTP y las envía al servidor RMI que escucha en cualquier puerto.
javac (Compilador Java)
Compila programas escritos en el lenguaje de programación Java en códigos bytecode (código Java compilado).
javadoc (Generación de documentación 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.
javap (Desensamblador de archivos de clases)
Desensambla los archivos compilados y permite imprimir una representación de los códigos bytecode.
javaw (Java Interpreter)
Ejecuta las clases Java del mismo modo que el mandato java, pero no utiliza una ventana de consola.
(Sólo para Linux IA de 32 bits, PPC32 y PPC64)javaws (Java Web Start)
Habilita el despliegue y el mantenimiento automático de las aplicaciones Java. Para obtener más información, consulte el apartado Ejecución de Web Start.
jconsole (Herramienta de gestión y supervisión JConsole)
Supervisa las JVM locales y remotas mediante una GUI. Compatible con JMX.
jdb (Depurador Java)
Permite depurar los programas Java.
jdmpview (Formateador de vuelcos entre plataformas)
Analiza vuelcos. Para obtener más información, consulte la Guía de diagnósticos.
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 stubs de invocación a método remoto (RMI) de Java)
Genera stubs, skeletons y ties de objetos remotos. Incluye el soporte RMI-IIOP (RMI a través de Internet Inter-ORB Protocol).
schemagen
Crea un archivo de esquemas para cada espacio de nombres referenciado en las clases Java.
serialver (Mandato de versión de serie)
Devuelve el identificador serialVersionUID de una o varias clases en un formato adecuado para copiarlo en una clase en evolución.
wsgen
Genera artefactos portátiles JAX-WS que se utilizan en servicios web JAX-WS.
wsimport
Genera artefactos portátiles JAX-WS a partir de un archivo WSDL.
xjc
Compila archivos de esquemas XML.
Archivos de inclusión
Cabeceras C de programas JNI.
Demos
El directorio demo incluye varios subdirectorios que contienen código fuente de ejemplo, demostraciones, aplicaciones y applets que puede utilizar. |A partir de la versión 6, la demo RMI-IIOP no está incluida con el SDK.
copyright
El aviso de copyright del SDK para el softwareLinux.
License

El archivo License, /opt/ibm/java-i386-60/docs/content/<entorno_local>/LA_<entorno_local>, contiene el acuerdo de licencia para el software SDK para Linux (donde <entorno_local> es el nombre del entorno local, por ejemplo, es). Para ver o imprimir el acuerdo de licencia, abra el archivo en un navegador web.

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 permitir el acceso de todos los usuarios de la máquina a esta instalación de Java, utilice el método de instalación .tgz. Si no tiene acceso root, utilice el archivo .tgz.

Si realiza la instalación mediante un archivo RPM, los archivos Java se instalan en /opt/ibm/java-i386-60/. En los ejemplos de esta guía se presupone que ha instalado Java en este directorio.

Actualización del SDK

Si va a actualizar el SDK desde 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 iniciar la actualización.

Después de la actualización, es posible que tenga que restaurar o volver a configurar estos archivos porque durante el proceso de actualización se pueden haber sobrescrito. Compruebe la sintaxis de los nuevos archivos antes de restaurar los archivos originales porque el formato o las opciones de los archivos puede haber cambiado.

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

El SDK depende de bibliotecas compartidas que no se instalan de forma predeterminada para Red Hat Enterprise Linux (RHEL).

En RHEL 4, los RPM que contienen estas bibliotecas son:

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

  1. Cuando llegue a la pantalla Paquetes predeterminados, seleccione Personalizar el conjunto de paquetes a instalar.
  2. En la pantalla Selección de grupos de paquetes, bajo Sistema X Windows, seleccione Detalles y asegúrese de seleccionar xorg-x11-deprecated-libs
  3. Bajo las opciones de Desarrollo, seleccione Desarrollo de software anticuado.

Instalación en Red Hat Enterprise Linux (RHEL) 5

El SDK depende de bibliotecas compartidas que no se instalan de forma predeterminada para Red Hat Enterprise Linux (RHEL).

En RHEL 5, los RPM que contienen estas bibliotecas son:

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

  1. En la pantalla de selección de software, seleccione Personalizar ahora.
  2. En la pantalla siguiente, en el panel de la izquierda, seleccione Sistema base; en el panel de la derecha, seleccione Soporte para software anticuado. Estas selecciones instalarán los paquetes compat-libstdc++.
  3. El paquete libXp es necesario pero no está disponible para su selección para instalación desde la GUI de instalación. Cuando se haya completado la instalación, abra un shell, localice el paquete libXp en el soporte de instalación de Red Hat e instálelo. Por ejemplo, para instalarlo en una plataforma Intel de 32 bits: rpm -i /media/cdrom/Server/libXp-1.0.0-8.i386.rpm

Ejecución de Java con SELinux en RHEL 5

Para ejecutar el IBM SDK para Java en Red Hat Enterprise Linux Versión 5 con SELinux habilitado, Java debe estar instalado en el directorio predeterminado o debe entrarse un mandato.

Si Java no está instalado en el directorio predeterminado, entre:

chcon -R -t texrel_shlib_t <vía_acceso_del_sdk>

Donde <vía_acceso_del_sdk> es la vía de acceso en la que se ha instalado Java.

Para obtener más información sobre SELinux, consulte Introduction to SELinux en la documentación de Red Hat.

Instalación de un SDK de 32 bits en una arquitectura de 64 bits

Para ejecutar el SDK, debe instalar las versiones correctas de todas las bibliotecas que requiere el SDK, ya sean de 32 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

Un procedimiento para instalar desde un archivo RPM.

Para actualizar la JVM utilizando la herramienta rpm, debe desinstalar cualquier versión anterior. Para instalar dos versiones de la JVM en ubicaciones distintas, utilice la opción --force de rpm para hacer caso omiso del conflicto de versiones o instale la JVM desde el archivo .tgz.

  1. Abra un indicador de shell asegurándose de iniciar la sesión como usuario root.
  2. En un indicador de shell, escriba rpm -ivh <archivo RPM>. Por ejemplo:
    rpm -ivh ibm-java2-<arch>-sdk-6.0-0.0.<arch>.rpm
    o bien
    rpm -ivh ibm-java2-<arch>-jre-6.0-0.0.<arch>.rpm

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

Instalación desde un archivo .tgz

Un procedimiento para instalar desde un archivo .tgz.

  1. Cree un directorio para almacenar los archivos del paquete de Java. Los ejemplos de esta guía presuponen que ha realizado la instalación en /opt/ibm/java-i386-60/. En el resto de esta guía, sustituya /opt/ibm/java-i386-60/ por el directorio en el que ha instalado Java.
  2. En un indicador de shell, escriba tar -zxvf <archivo .tgz>.
    tar -zxvf ibm-java2-sdk-60-linux-<arch>.tgz
    o bien
    tar -zxvf ibm-java2-jre-60-linux-<arch>.tgz

    Donde <arch> representa la arquitectura: 386, x86_64, ppc, ppc64, s390 o s390x.

  3. Si está ejecutando Security-Enhanced Linux (SELinux), debe identificar las bibliotecas compartidas de Java ante el sistema. Escriba:
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/jre
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/bin
    chcon -R -t texrel_shlib_t /opt/ibm/java2-i386-60/lib

Utilización de un formato compatible con JPackage

El paquete IBM Java también está disponible en un formato compatible con JPackage.

Para simplificar la gestión del SDK, los diversos componentes del mismo están ahora disponibles como RPM independientes: el Java Runtime Environment básico, Development Kit, Plug-in, JDBC, Demo, Sound, Source y Fonts. El RPM "jpackage-utils" (que se puede descargar desde http://jpackage.org), que permite gestionar múltiples RPM de Java en un sistema, también es un prerrequisito para los IBM SDK. Para obtener más información sobre la especificación JPackage, consulte http://jpackage.org.

Configuración del SDK y Runtime Environment para Linux

Incoherencias en las codificaciones de fonts en Red Hat Advanced Server

Nota: (Sólo para usuarios de Linux IA de 32 bits en chino) Debido a incoherencias en las codificaciones de fonts en Red Hat Advanced Server, cuando realice la instalación en un entorno en el que desee que el chino sea el idioma predeterminado, es mejor realizar la instalación con el inglés como idioma predeterminado y luego cambiar a chino después de finalizar la instalación. De lo contrario, es posible que no se muestren los fonts en chino.

Configuración de la vía de acceso

Si altera la variable de entorno PATH, alterará temporalmente los iniciadores Java existentes en la vía de acceso.

La variable de entorno PATH permite que Linux busqueprogramas y programas de utilidad, como, por ejemplo, javac, java y javadoc, desde cualquier directorio actual. Para visualizar el valor actual de PATH, escriba lo siguiente en un indicador de mandatos:

echo $PATH

Para añadir iniciadores Java a la vía de acceso:

  1. Edite el archivo de arranque del 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/java-i386-60/bin:/opt/ibm/java-i386-60/jre/bin:$PATH
  2. Vuelva a iniciar una sesión o ejecute el script de shell actualizado para activar la nueva variable de entorno PATH.

Después de configurar la vía de acceso, puede ejecutar una herramienta escribiendo su nombre en el indicador de mandatos desde cualquier directorio. Por ejemplo, para compilar el archivo Myfile.Java, en una solicitud de mandatos, escriba lo siguiente:

javac Myfile.Java

Establecimiento de la vía de acceso de clases

La vía de acceso de clases indica a las herramientas de SDK como, por ejemplo, java, javac y javadoc, dónde encontrará las bibliotecas de las clases Java.

Sólo necesita establecer la vía de acceso de clases de forma explícita:

Para visualizar el valor actual de la variable de entorno CLASSPATH, escriba el mandato siguiente en un indicador del shell:

  echo $CLASSPATH

Si desarrolla y ejecuta aplicaciones que utilicen entornos de ejecución diferentes, incluyendo otras versiones que haya instalado por separado, debe establecer CLASSPATH y PATH de forma explícita para cada aplicación. Si ejecuta varias aplicaciones simultáneamente y utiliza entornos de ejecución diferentes, cada aplicación debe ejecutarse en su propio indicador del shell.

Desinstalación del SDK y Runtime Environment para Linux

El proceso utilizado para eliminar el SDK y Runtime Environment para Linux depende del tipo de instalación que se haya realizado.

Consulte Desinstalación del paquete RPM (Red Hat Package Manager) o Desinstalación del paquete comprimido TAR (Tape Archive) para obtener instrucciones.

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

Un procedimiento para desinstalar el paquete RPM (Red Hat Package Manager).

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

  1. Para consultar qué paquetes RPM ha instalado, entre: rpm -qa | grep -i java

    Verá una lista de todos los paquetes IBM Java que ha instalado, por ejemplo:

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

    Esta salida le indica qué paquetes puede desinstalar, utilizando el mandato rpm -e; por ejemplo:

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

    O también 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 Plug-in Java, elimine los archivos del Plug-in Java del directorio del navegador web.

Desinstalación del paquete comprimido TAR (Tape Archive)

Una lista de los pasos para eliminar el IBM SDK para Linux, v6 que se ha extraído del paquete comprimido.

  1. Elimine el Runtime Environment o los archivos del 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 Plug-in Java, elimine los archivos del Plug-in Java del directorio del navegador web.

Ejecución de aplicaciones Java

Las aplicaciones Java se pueden iniciar mediante el iniciador java o mediante JNI. Los valores pasan a una aplicación Java utilizando argumentos de línea de mandatos, variables de entorno y archivos de propiedades.

Los mandatos java y javaw

Una breve descripción de los mandatos java y javaw.

Finalidad

Las herramientas java y javaw inician una aplicación Java iniciando un Java Runtime Environment y cargando una clase especificada.

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

Utilización

La JVM busca la clase inicial (y otras clases utilizadas) en tres conjuntos de ubicaciones: la vía de acceso de clases de la rutina de carga, las extensiones instaladas y la vía de acceso de clases 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.

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

Parámetros

[opciones]
Opciones de línea de mandatos que se han de pasar al entorno de ejecución.
<clase>
La clase de arranque. La clase debe contener un método main().
<archivo.jar>
Nombre del archivo jar que se va a invocar. Se utiliza únicamente con la opción -jar. El archivo jar con nombre debe contener los archivos de clases y recursos de la aplicación y la clase de arranque indicada por la cabecera del manifiesto Main-Class.
[argumentos ...]
Los argumentos de línea de mandatos que se han de pasar a la función main() de la clase de arranque.

Obtención de la información de versión

El número de versión y compilación de IBM de la instalación Java se obtiene utilizando la opción -version. |También puede obtener información sobre la versión para todos los archivos jar de la vía de acceso de clases utilizando la opción -Xjarversion.

  1. Abra un indicador del shell.
  2. Escriba el siguiente mandato:
    java -version
    Verá información similar a la siguiente:
    java version "1.6.0-internal"
    Java(TM) SE Runtime Environment (build 20070329_01)
    IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20070326_12091 (JIT enabled)
    J9VM - 20070326_12091_lHdSMR
    JIT  - dev_20070326_1800
    GC   - 20070319_AA)
    Las fechas y versiones exactas de la compilación se modificarán.

| |

También puede ver información de la versión de todos los archivos jar disponibles en la vía de acceso de clases, la vía de acceso de clases de arranque y el directorio de extensiones; escriba el mandato siguiente:

|
java -Xjarversion
|

Verá información similar a la siguiente:

|
...
|/opt/ibm/java-i386-60/jre/lib/ext/ibmpkcs11impl.jar  VERSION: 1.0 build_20070125
|/opt/ibm/java-i386-60/jre/lib/ext/dtfjview.jar
|/opt/ibm/java-i386-60/jre/lib/ext/xmlencfw.jar  VERSION: 1.00, 20061011  LEVEL: -20061011
|
|...
|

La información disponible varía para cada archivo |jar y procede de las propiedades de |Implementation-Version y Build-Level del manifiesto del archivo jar.

Especificación de opciones Java y propiedades del sistema

Puede especificar las opciones Java y las propiedades del sistema en la línea de mandatos, mediante un archivo de opciones o una variable de entorno.

Los métodos para especificar las opciones Java se listan por orden de prioridad:

  1. Especificando la opción o propiedad en la línea de mandatos. Por ejemplo:
    java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
  2. Creando un archivo que contenga las opciones y especificándolo en la línea de mandatos utilizando -Xoptionsfile=<archivo>.
  3. Creando una variable de entorno denominada IBM_JAVA_OPTIONS que contenga las opciones. Por ejemplo:
    export IBM_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 la izquierda. Por ejemplo, si especifica:

java -Xint -Xjit myClass

La opción -Xjit tiene prioridad.

Opciones estándar

Las definiciones de las opciones estándar.

-agentlib:<nombre biblioteca>[=<opciones>]
Carga una biblioteca nativa del agente <nombre biblioteca>; 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 biblioteca[=<opciones>]
Carga una biblioteca nativa del agente mediante el nombre de vía de acceso completo.
-cp <directorios y archivos zip o jar separados por :>
Establece la vía de acceso de búsqueda de clases y recursos de aplicaciones. Si -classpath y -cp no se utilizan y no se ha establecido la variable de entorno CLASSPATH, la vía de acceso de clases del usuario predeterminada es el directorio actual (.).
-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 -classpath y -cp no se utilizan y no se ha establecido la variable de entorno CLASSPATH, la vía de acceso de clases del usuario predeterminada es el directorio actual (.).
-D<nombre propiedad>=<valor>
Establece una propiedad de sistema.
-help o -?
Imprime un mensaje de uso.
-javaagent:<vía de acceso de jar>[=<opciones>]
Carga un agente de lenguaje de programación Java. Para obtener más información, consulte la documentación de la API java.lang.instrument.
-jre-restrict-search
Incluye los JRE privados en la búsqueda de versión.
-no-jre-restrict-search
Excluye los JRE privados en la búsqueda de versión.
-showversion
Imprime la versión del producto y prosigue.
-verbose:<opción>
Habilita la salida verbosa. Las opciones disponibles son:
class
Graba una entrada en stderr para cada clase cargada.
gc
Graba la información de recogida de basura verbosa en stderr. Utilice -Xverbosegclog para controlar la salida. Consulte la Guía de diagnósticos para obtener más información.
jni
Graba información en stderr que describe los servicios JNI que invocan la aplicación y la JVM.
sizes
Graba información en stderr que describe los valores de uso de la memoria activos.
stack
Graba información en stderr que describe el uso de la pila C y Java de cada hebra.
-version
Imprime la versión del producto.
-version:<valor>
Requiere la versión especifica que se ha de ejecutar, por ejemplo, "1.5".
-X
Imprime ayuda sobre las opciones no estándar.

Globalización del mandato java

El mandato java y otros iniciadores javaw aceptan argumentos y y nombres de clase que contienen 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, utilice la opción de línea de mandatos -Xargencoding.

-Xargencoding
Utilice la codificación de argumentos. 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).
-Xargencoding:utf8
Utilice la codificación UTF8.
-Xargencoding:latin
Utilice la codificación ISO8859_1.

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 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á en inglés.

Compilador Just-In-Time (JIT)

El compilador JIT (IBM Just-In-Time) genera dinámicamente código máquina para las secuencias de código bytecode que se utilizan con frecuencia en las aplicaciones y applets Java durante su ejecución. El compilador JIT v6 proporciona nuevas optimizaciones como resultado de la investigación en compilación, mejora las optimizaciones implementadas en versiones anteriores de la JIT y permite un mejor aprovechamiento del hardware.

Tanto IBM SDK como Runtime Environment incluyen JIT, que está habilitado de forma predeterminada en las aplicaciones de usuario y herramientas SDK. Normalmente, no se invoca JIT de forma explícita, la compilación Java con el código máquina se produce de forma transparente. Puede inhabilitar el JIT para intentar aislar el problema. Si se produce un problema mientras ejecuta una aplicación Java o un applet, puede inhabilitar elJIT para intentar aislar el problema. Inhabilitar JIT es sólo una medida temporal. JIT se necesita para optimizar el rendimiento.

Para obtener más información sobre el compilador JIT, consulte la Guía de diagnósticos.

Inhabilitación del JIT

El JIT se puede inhabilitar de varios modos diferentes. Las dos opciones de línea de mandatos alteran temporalmente la variable de entorno JAVA_COMPILER.

Desactivar el JIT es una medida temporal que puede ayudarle a aislar problemas de depuración de las aplicaciones Java.

Habilitación del JIT

El JIT está habilitado de forma predeterminada. Puede habilitar de forma explícita el JIT de varias formas diferentes. Las dos opciones de línea de mandatos alteran temporalmente la variable de entorno JAVA_COMPILER.

Cómo determinar si el JIT está habilitado

Puede determinar el estado del JIT utilizando la opción-version.

Ejecute el iniciador java con la opción -version. Escriba lo siguiente en un indicador del shell:

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 de diagnósticos.

Cómo especificar una política de recogida de basura

El recopilador de basura gestiona la memoria que utiliza Java y las aplicaciones que se ejecutan en la JVM.

Cuando el recopilador de basura recibe una solicitud de almacenamiento, la memoria no utilizada en el almacenamiento dinámico se define aparte en un proceso denominado "asignación". El recopilador de basura también busca áreas de memoria a las que ya no se haga referencia, y las libera para que se puedan reutilizar. Esta acción se denomina "recogida".

La fase de recogida 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 recogida de basura puede afectar de forma importante el rendimiento de la aplicación, por lo que la máquina virtual IBM ofrece varios métodos para optimizar el modo en que ésta se realiza y reducir de esta forma su efecto en la aplicación.

Para obtener información más detallada sobre la recogida de basura, consulte la Guía de diagnósticos.

Opciones de recogida de basura

Las opciones -Xgcpolicy controlan el comportamiento del recopilador de basura. Equilibran el rendimiento de la aplicación y del sistema en general y los tiempos de pausa que genera la recogida de basura.

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

-Xgcpolicy:optthruput
(El valor predeterminado y recomendado.) Proporciona un rendimiento muy elevado para las aplicaciones con el inconveniente de pausas ocasionales.
-Xgcpolicy:optavgpause
Reduce el tiempo invertido en estas pausas de recogida de basura y limita el efecto de aumentar el tamaño del almacenamiento dinámico durante la pausa de recogida de basura. Utilice optavgpause si la configuración tiene un almacenamiento dinámico muy grande.
-Xgcpolicy:gencon
Solicita el uso combinado de una recogida de basura simultánea y generacional para minimizar el tiempo invertido en una pausa de recogida de basura.
-Xgcpolicy:subpool
(sólo PPC y zSeries.) Utiliza un algoritmo mejorado de asignación de objetos para obtener un mayor rendimiento en la asignación de objetos al almacenamiento dinámico. Esta opción puede aumentar el rendimiento en los sistemas SMP de gran tamaño.

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 basura identificar los objetos sin referencia (basura), 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 recogida de basura 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 recogida de basura tiende a aumentar en duración e importancia.

El valor predeterminado de la recogida de basura, -Xgcpolicy:optthruput, proporciona un rendimiento muy alto a las aplicaciones, pero con el 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 basura.

Reducción del tiempo de pausa

La JVM utiliza dos técnicas para reducir los tiempos de pausa: la recogida de basura simultánea y la recogida de basura generacional.

La opción de línea de mandatos -Xgcpolicy:optavgpause solicita el uso de la recogida de basura simultánea para reducir significativamente el tiempo invertido en las pausas de recogida de basura. La recogida de basura simultánea reduce estas pausas ya que realiza las actividades de recogida de basura de forma simultánea durante la ejecución normal del programa, minimizando así la interrupción que ocasiona la recogida 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 recogida de basura. 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 recogida de basura simultánea, 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 recogida de basura 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. La recogida de basura generacional reduce los tiempos de pausa ya que divide el almacenamiento dinámico en dos "generaciones": las áreas de "vivero" y de "almacén". Los objetos se colocan en una de estas áreas dependiendo de su antigüedad. El vivero es la menor de las dos y contiene los objetos más recientes; el almacén es más grande y contiene los objetos más antiguos. Los objetos se asignan primero al vivero; si sobreviven el tiempo suficiente, al final pasarán al área de almacén.

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

Entornos con almacenamientos dinámicos muy llenos

Si el almacenamiento dinámico de Java está casi lleno y hay muy poca basura para 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 de recopilación de basura se usa; y, si se siguen realizando peticiones de más espacio de almacenamiento dinámico, la aplicación recibe una excepción OutOfMemoryError, que provoca la interrupción de la JVM si esta excepción no se detecta y gestiona. Llegado este punto, la JVM genera un archivo de vuelco java para utilizarlo durante los diagnósticos. 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 que se utilizan.

Para obtener más información, consulte la Guía de diagnósticos.

Soporte del símbolo de Euro

IBM SDK y Runtime Environment establecen el euro como la moneda predeterminada para los países de la Unión Monetaria Europea (UME) a partir del 1 de Enero de 2002. Desde el 1 de enero de 2008, Chipre y Malta también tendrán el Euro como moneda predeterminada.

Para utilizar la moneda nacional antigua, 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.

Archivos de configuración de font de reserva

Los archivos de configuración de font de reserva de Linux (fontconfig.RedHat.bfc y fontconfig.SuSE.bfc) se instalan para proporcionar un ajuste de fonts adecuado a las nuevas distribuciones comerciales de Linux.

Estos archivos se entregan sólo para su comodidad. Su presencia no implica que la nueva distribución de Linux sea una plataforma soportada para IBM SDK y Runtime Environment para plataformas Linux, Java Technology Edition, Versión 6.

| | |

Utilización de los métodos de entrada de India y Tailandia

|
|

A partir de la versión 6, los métodos de entrada de India y Tailandia no están disponibles de forma |predeterminada. Se deben incluir manualmente los archivos jar del método de entrada en la vía de acceso de extensiones Java para utilizar los métodos de entrada de India y Tailandia.

|

En la Versión 5.0, se incluían los archivos jar del método de entrada en el directorio jre/lib/ext y la JVM los cargaba automáticamente. En la Versión 6, los archivos jar del método de entrada se incluyen en el directorio jre/lib/im y se deben añadir manualmente a la vía de acceso de las extensiones Java para habilitar los métodos de entrada de India y Tailandia. Esto se puede realizar mediante uno de los métodos siguientes:

| |

|

Si ha instalado SDK o Runtime Environment en un directorio diferente, sustituya /opt/ibm/java-i386-60/ por el directorio en el que ha instalado SDK o Runtime Environment.

Utilización del SDK para desarrollar aplicaciones Java

SDK para Linux contiene muchas herramientas y bibliotecas necesarias para el desarrollo del software Java.

Consulte el apartado Herramientas e información de referencia de SDK para obtener información detallada sobre las herramientas disponibles.

| | |

Utilización de XML

|
|

IBM SDK contiene los analizadores XML4J y |XL XP-J, el compilador XL TXE-J 1.0 XSLT y el intérprete XSLT4J XSLT. |Estas herramientas permiten analizar, validar, transformar y serializar documentos XML independientemente |de la implementación de proceso XML específica.

|

|

Utilice buscadores de factoría para localizar implementaciones de las clases de factoría abstractas tal como se ha descrito en el apartado |Selección de un procesador XML. |Mediante buscadores de factoría, puede seleccionar una biblioteca XML diferente sin cambiar el código |Java.

|

| |

Bibliotecas XML disponibles

|

IBM SDK para Java contiene las bibliotecas XML siguientes.

|
|
XML4J 4.5
|
|

XML4J es un analizador con validación que proporciona soporte para los siguientes estándares: |

|
    |
  • XML 1.0 (Cuarta edición)
  • |
  • Namespaces in XML 1.0 (Segunda edición)
  • |
  • XML 1.1 (Segunda edición)
  • |
  • Namespaces in XML 1.1 (Segunda edición)
  • |
  • W3C XML Schema 1.0 (Segunda edición)
  • |
  • XInclude 1.0 (Segunda edición)
  • |
  • OASIS XML Catalogs 1.0
  • |
  • SAX 2.0.2
  • |
  • DOM Level 3 Core, Load and Save
  • |
  • DOM Level 2 Core, Events, Traversal and Range
  • |
  • JAXP 1.4
| |

XML4J 4.5 está basado en Apache Xerces-J 2.9.0. Consulte http://xerces.apache.org/xerces2-j/ para obtener más información.

|
|
XL XP-J 1.1
|
|

XL XP-J 1.1 es un analizador de alto rendimiento sin validación que proporciona soporte |para StAX 1.0 (JSR 173); una API bidireccional para serialización de modalidad continua y de análisis directo (pull-parsing) |de documentos XML 1.0 y XML 1.1. Consulte el apartado Información de referencia XL XP-J para obtener más detalles |sobre lo que XL XP-J 1.1 soporta.

|
|
XL TXE-J 1.0.1 Beta
|
|

Para la versión 5.0, IBM SDK para Java ha incluido el compilador y el intérprete XSLT4J. |El intérprete XSLT4J se utilizaba de forma predeterminada.

| |

Para la versión 6,IBM SDK para Java incluye |XL TXE-J. XL TXE-J incluye el intérprete XSLT4J 2.7.8 y un compilador XSLT nuevo. |El nuevo compilador se utiliza de forma predeterminada. El compilador XSLT4J ya no está incluido con |IBM SDK |para Java, |consulte el apartado Migración a XL-TXE-J para obtener información sobre migración a |XL TXE-J.

| |

XL TXE-J incluye soporte para los siguientes estándares: |

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

| |

Selección de un procesador XML

|

La selección del procesador XML se realiza utilizando los proveedores de servicio. Cuando se utiliza un buscador de factoría, Java mira en los lugares siguientes para ver qué proveedor de servicios va a utilizar: |

|
    |
  1. La propiedad del sistema con el mismo nombre que el proveedor de servicios.
  2. |
  3. Únicamente para XMLEventFactory, XMLInputFactory, |y XMLOutputFactory. El valor del proveedor de servicios en el archivo/opt/ibm/java-i386-60/jre/lib/stax.properties.
  4. |
  5. Para otras factorías. El valor del proveedor de servicios del archivo /opt/ibm/java-i386-60/jre/lib/jaxp.properties.
  6. |
  7. El contenido del archivo META-INF/services/<service.provider>.
  8. |
  9. El proveedor de servicios predeterminado.
|

Los siguientes proveedores de servicio controlan las bibliotecas de proceso XML que utiliza Java: |

|
|
javax.xml.parsers.SAXParserFactory
|
Selecciona el analizador SAX. De forma predeterminada, se utiliza org.apache.xerces.jaxp.SAXParserFactoryImpl de la biblioteca |XML4J. |
|
javax.xml.parsers.DocumentBuilderFactory
|
Selecciona el creador de documentos. De forma predeterminada, se utiliza org.apache.xerces.jaxp.DocumentBuilderFactoryImpl de la biblioteca |XML4J. |
|
javax.xml.datatype.DatatypeFactory
|
Selecciona la factoría de tipo de datos. De forma predeterminada, se utiliza org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl de la biblioteca XML4J. |
|
javax.xml.stream.XMLEventFactory
|
Selecciona la factoría de sucesos StAX. De forma predeterminada, se utiliza com.ibm.xml.xlxp.api.stax.XMLEventFactoryImpl de la biblioteca XL XP-J. |
|
javax.xml.stream.XMLInputFactory
|
Selecciona el analizador StAX. De forma predeterminada, se utiliza com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl de la biblioteca XL XP-J. |
|
javax.xml.stream.XMLOutputFactory
|
Selecciona el serializador StAX. De forma predeterminada, se utiliza com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl de la biblioteca XL XP-J. |
|
javax.xml.transform.TransformerFactory
|
Selecciona el procesador XSLT. Los valores posibles son: | |
|
com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl
|
Utiliza el compilador XL TXE-J. Este es el valor predeterminado. |
|
org.apache.xalan.processor.TransformerFactoryImpl
|
Utiliza el intérprete XSLT4J. |
|
|
|
javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema
|
Selecciona la factoría de esquema para el lenguaje de esquema W3C XML. De forma predeterminada, se utiliza org.apache.xerces.jaxp.validation.XMLSchemaFactory de la biblioteca XML4J. |
|
javax.xml.xpath.XPathFactory
|
Selecciona el procesador XPath. De forma predeterminada, se utiliza org.apache.xpath.jaxp.XPathFactoryImpl de la biblioteca |XSLT4J. |
|

| |

Migración a XL-TXE-J

|
|

El compilador XL TXE-J ha sustituido el intérprete XSLT4J como procesador |XSLT predeterminado. Siga estos pasos para preparar la aplicación para la biblioteca nueva.

|

|

El compilador XL TXE-J es más rápido que el intérprete XSLT4J cuando se aplica la misma |transformación más de una vez. Si sólo realiza cada transformación individual una vez, el compilador XL TXE-J es más lento que el |intérprete XSLT4J debido a la sobrecarga de la compilación y la optimización.

|

Para continuar utilizando el intérprete XSLT4J como procesador XSLT, establezca el |proveedor de servicios javax.xml.transform.TransformerFactory en org.apache.xalan.processor.TransformerFactoryImpl.

|

Para efectuar la migración al compilador XL-TXE-J, siga estos pasos:

|
    |
  1. Utilice com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl cuando establezca el proveedor de servicios de javax.xml.transform.TransformerFactory.
  2. |
  3. Vuelva a generar los archivos de clases generados por el compilador XSLT4J. XL TXE-J no puede ejecutar los archivos de clases generados por el compilador XSLT4J.
  4. |
  5. Es posible que algunos métodos generados por el compilador excedan el límite de tamaño del método JVM, en cuyo caso el compilador intentará dividir estos métodos en métodos más pequeños. | |
      |
    • Si el compilador divide el método correctamente, recibirá el siguiente |aviso: "Algunas funciones generadas sobrepasan el límite de tamaño del método JVM y se han dividido automáticamente en funciones más pequeñas. Es posible que obtenga un mejor rendimiento dividiendo manualmente las plantillas muy grandes en plantillas más pequeñas, utilizando la opción 'splitlimit' en el mandato Process o Compile, o estableciendo el atributo de TransformerFactory 'http://www.ibm.com/xmlns/prod/xltxe-j/split-limit'." Puede utilizar las clases compiladas, pero es posible que obtenga un mejor rendimiento si controla el límite de división manualmente.
    • |
    • Si el compilador no divide el método correctamente, recibirá una de las siguientes |excepciones: "com.ibm.xtq.bcel.generic.ClassGenException: |El desplazamiento del destino de la bifurcación es demasiado grande para abreviar" o "tamaño de matriz de código bytecode > 65535 |en desplazamiento=#####". Intente establecer el límite de división manualmente, utilizando un límite de división inferior.
    Para establecer el límite de división, utilice la opción -SPLITLIMIT cuando utilice los mandatos |Process o Compile, o bien el atributo de TransformerFactory http://www.ibm.com/xmlns/prod/xltxe-j/split-limit cuando utilice |TransformerFactory. El |límite de división puede estar entre 100 y 2000. Cuando establezca el límite de división manualmente, utilice el límite de división más elevado posible para obtener el mejor rendimiento.
  6. |
  7. Es posible que XL TXE-J necesite más memoria que el compilador XSLT4J. Si se está agotando la memoria o si el rendimiento es lento, aumente el tamaño del almacenamiento dinámico utilizando la opción -Xmx.
  8. |
  9. Migre la aplicación para que utilice las nuevas claves de atributos. Las claves de atributos antiguas de TransformerFactory han quedado obsoletas. Los nombres antiguos se aceptarán pero con un aviso. | | |||||||||||||||||||||||||||||||||||||||||||||||||||
    Tabla 1. Cambios en las claves de atributos del compilador XSL4J al compilador XL TXE-J
    Atributo del compilador XSL4J Atributo del compilador XL TXE-J
    translet-name http://www.ibm.com/xmlns/prod/xltxe-j/translet-name
    destination-directory http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory
    package-name http://www.ibm.com/xmlns/prod/xltxe-j/package-name
    jar-name http://www.ibm.com/xmlns/prod/xltxe-j/jar-name
    generate-translet http://www.ibm.com/xmlns/prod/xltxe-j/generate-translet
    auto-translet http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet
    use-classpath http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath
    debug http://www.ibm.com/xmlns/prod/xltxe-j/debug
    indent-number http://www.ibm.com/xmlns/prod/xltxe-j/indent-number
    enable-inlining Obsoleto en el nuevo compilador
  10. |
  11. Opcional: Para mejorar el rendimiento, asegúrese de que no vuelve a compilar transformaciones XSLT que puedan |reutilizarse. Utilice uno de los siguientes métodos para reutilizar las transformaciones |compiladas: | |
      |
    • Si la hoja de estilo no cambia en tiempo de ejecución, compile la hoja de estilo como parte del proceso |de compilación y especifique las clases compiladas en la variable CLASSPATH. |Utilice el mandato org.apache.xalan.xsltc.Compile para compilar la hoja de estilo y |establezca el atributo de fábrica del transformador http://www.ibm.com/xmlns/prod/xltxe-j/use-classpath |en true para cargar las clases desde la variable CLASSPATH.
    • |
    • Si la aplicación utilizará la misma hoja de estilo durante varias ejecuciones, establezca el |atributo de fábrica del transformador http://www.ibm.com/xmlns/prod/xltxe-j/auto-translet |en true para guardar automáticamente la hoja de estilo compilada en disco |para su reutilización. El compilador utilizará una hoja de estilo compilada si está disponible y la compilará si no está |disponible o está desfasada. Utilice el atributo de fábrica del transformador http://www.ibm.com/xmlns/prod/xltxe-j/destination-directory |para establecer el directorio utilizado para almacenar las hojas de estilo compiladas. |De forma predeterminada, las hojas de estilo compiladas se almacenan en el mismo directorio que la hoja de estilo.
    • |
    • Si su aplicación se ejecuta durante mucho tiempo y reutiliza la misma hoja de estilo, |utilice la fábrica del transformador para compilar la hoja de estilo y cree un |objeto Templates. Puede utilizar el objeto Templates para crear |objetos Transformer sin tener que volver a compilar la hoja de estilo. |Los objetos Transformer también pueden reutilizarse pero no ofrecen hebras |seguras.
| |

Información de referencia XML

|
|

Las bibliotecas XL XP-J y XL TXE-J XML son nuevas en la versión 6 del |SDK. Esta información de referencia describe las características que admiten estas bibliotecas.

| | |

Información de referencia XL XP-J

|
|

XL XP-J 1.1 es un analizador de alto rendimiento sin validación que proporciona soporte |para StAX 1.0 (JSR 173); una API bidireccional para serialización de modalidad continua y de análisis directo (pull-parsing) |de documentos XML 1.0 y XML 1.1.

|

| |

Características no soportadas
|

Las siguientes características opcionales StAX |no están soportadas en XL XP-J: |

|

|

| |

Referencia XMLInputFactory
|

Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLInputFactory, tal como se ha descrito enXMLInputFactory Javadoc.

| |||||||||||||||||||||||||||||||||||||||||||
Tabla 2.
Nombre de la propiedad Soportada
javax.xml.stream.isValidating No. El escáner XL XP-J no admite validación.
javax.xml.stream.isNamespaceAware Sí (admite verdadero y falso). Para XMLStreamReader creados |a partir de DOMSource, el proceso de espacio de nombres depende de los métodos |que se utilizaron para crear el árbol DOM y este valor no surtirá efecto.
javax.xml.stream.isCoalescing
javax.xml.stream.isReplacingEntityReferences Sí. Para XMLStreamReader creados a partir de |DOMSource, si las entidades ya se han sustituido en el árbol DOM, |establecer este parámetro no surte ningún efecto.
javax.xml.stream.isSupportingExternalEntities
javax.xml.stream.supportDTD No. Siempre se da soportea las DTD. Establecer el valor en falso no tiene ningún efecto.
javax.xml.stream.reporter
javax.xml.stream.resolver
|

XL XP-J también admite el método opcional createXMLStreamReader(javax.xml.transform.Source), lo que permite que los lectores |StAX se creen a partir de fuentes DOM y SAX.

|

| |

Referencia XMLStreamReader
|

Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLStreamReader, |tal como se ha descrito en XMLStreamReader Javadoc.

| |||||||||||||||||||
Tabla 3.
Nombre de la propiedad Soportada
javax.xml.stream.entities
javax.xml.stream.notations
|

XL XP-J también admite la propiedad javax.xml.stream.isInterning, que devuelve un booleano que indica si las URI de nombres XML y espacio de nombres |que devuelven las llamadas de la API las ha incluido el analizador.

|

| |

Referencia XMLOutputFactory
|

Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLOutputFactory, tal como se ha descrito en XMLOutputFactory Javadoc.

| |||||||||||||||
Tabla 4.
Nombre de la propiedad Soportada
javax.xml.stream.isRepairingNamespaces
|

| |

Referencia XMLStreamWriter
|

Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLStreamWriter, tal como se ha descrito en XMLStreamWriter Javadoc.

| |||||||||||||||
Tabla 5.
Nombre de la propiedad Soportada
javax.xml.stream.isRepairingNamespaces
|

Las propiedades sobre objetos XMLStreamWriter son de sólo lectura.

| | |

Información de referencia XL TXE-J

|
|

XL TXE-J es una biblioteca XSLT que contiene el intérprete XSLT4J 2.7.8 y un compilador |XSLT.

|

| |

Tabla de comparación de características

| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tabla 6. Comparación de las características en el intérprete XSLT4J, el compilador XSLT4J y el compilador XL TXE-J.
Característica Intérprete XSLT4J (incluido) Compilador XSLT4J (no incluido) Compilador XL TXE-J (incluido)
Característica http:// |javax.xml.transform.stream.StreamSource |/feature
Característica http:// |javax.xml.transform.stream.StreamResult |/feature
Característica http://javax.xml.transform.dom.DOMSource/feature
Característica http://javax.xml.transform.dom.DOMResult/feature
Característica http://javax.xml.transform.sax.SAXSource/feature
Característica http://javax.xml.transform.sax.SAXResult/feature
Característica http://javax.xml.transform.stax.StAXSource/feature No
Característica http://javax.xml.transform.stax.StAXResult/feature No
Característica http:// |javax.xml.transform.sax. |SAXTransformerFactory/feature
Característica http:// |javax.xml.transform.sax. |SAXTransformerFactory/feature/ |xmlfilter
Característica http://javax.xml.XMLConstants/feature/secure-processing
Atributo http://xml.apache.org/xalan/features/incremental No No
Atributo http://xml.apache.org/xalan/features/optimize No No
Atributo http://xml.apache.org/xalan/properties/source-location No No
Atributo translet-name N/D Sí (con el nombre nuevo)
Atributo destination-directory N/D Sí (con el nombre nuevo)
Atributo package-name N/D Sí (con el nombre nuevo)
Atributo jar-name N/D Sí (con el nombre nuevo)
Atributo generate-translet N/D Sí (con el nombre nuevo)
Atributo auto-translet N/D Sí (con el nombre nuevo)
Atributo use-classpath N/D Sí (con el nombre nuevo)
Atributo enable-inlining No No (obsoleto en TL TXE-J)
Atributo indent-number No Sí (con el nombre nuevo)
Atributo debug No Sí (con el nombre nuevo)
Extensiones Java Sí (sólo sintaxis abreviada, las construcciones xalan:component/xalan:script no están soportadas)
Extensiones JavaScript No No
Elementos de extensión No No
Funciones de extensión EXSLT Sí (excepto dynamic) Sí (excepto dynamic)
Extensión redirect Sí (excepto redirect:open y redirect:close)
Extensión output No
Extensión nodeset
Funciones de extensión NodeInfo No No
Extensión de biblioteca SQL No No
Extensión pipeDocument No No
Extensión evaluate No No
Extensión tokenize No No
XML 1.1
|

| |

Notas
|

Con el mandato Process, utilice -FLAVOR |sr2sw para realizar la transformación mediante el proceso de corrientes StAX y -FLAVOR |er2ew para el proceso de sucesos StAX.

|

El nuevo compilador no busca el proveedor de servicios org.apache.xalan.xsltc.dom.XSLTCDTMManager. En su lugar, si se utiliza StreamSource el compilador pasa a un analizador XML de alto rendimiento.

|

En XL |TXE-J, inlining ha quedado obsoleto. |

| |

La clase org.apache.xalan.xsltc.trax.SmartTransformerFactoryImpl ya no está soportada.

| |

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

|
|

Si utiliza una versión anterior de Xerces (previa a 2.0) o Xalan (previa a 2.3) |en la aplicación sustituida utilizada, puede recibir una excepción NullPointerException cuando |inicie 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: |

|

Depuración de aplicaciones Java

Para depurar programas Java, puede utilizar la aplicación JDB (Java Debugger) u otros depuradores que se comuniquen utilizando JDPA(Java Platform Debugger Architecture) que se proporciona mediante SDK paraLinux.

Para obtener más información acerca del diagnóstico de problemas mediante Java consulte la Guía de diagnósticos.

JDB (Java Debugger)

JDB (Java Debugger) se incluye en 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> <clase>
    La JVM se inicia, pero suspende la ejecución antes de iniciar la aplicación Java.
  2. En una sesión aparte, puede conectar el depurador a la JVM:
    jdb -attach <puerto>
    El depurador se conectará a la JVM y podrá emitir una serie de mandatos para examinar y controlar la aplicación Java, por ejemplo, escriba run para que la aplicación Java se inicie.

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

jdb -help

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

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

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

  1. Inicie la JVM con las siguientes opciones:
    java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<puerto> <clase>
    La JVM se inicia, pero suspende la ejecución antes de iniciar la aplicación Java.
  2. Conecte el depurador a la JVM remota:
    jdb -attach <sistema principal>:<puerto>

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

Para obtener más información acerca de JDB y JPDA, y su utilización, consulte los siguientes sitios web:

Cómo determinar si la aplicación se está ejecutando en una JVM de 32 bits o de 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 funcionamiento de 32 y de 64 bits. En este caso, la aplicación debe cargar la biblioteca correcta en el tiempo de ejecución, ya que no se puede mezclar el código de 32bits y el de 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:

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

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

Cómo procesa las señales la JVM

Cuando se activa una señal que resulta de interés 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 se 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 predeterminada.

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

Para obtener información sobre cómo crear un iniciador que especifique los enganches anteriores, consulte: http://www.ibm.com/developerworks/java/library/i-signalhandling/. Este artículo se ha escrito para Java Versión 1.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:

  1. Llama al manejador de señales de la aplicación para dicha señal
  2. Ejecuta todos los enganches de conclusión de la aplicación
  3. Llama al enganche de salida que haya instalado la aplicación
  4. 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 están relacionadas con el control interno y no hacen que termine. La única señal de control de interés es SIGQUIT, que hace que se genere un Javadump.

Señales utilizadas por la JVM

Los tipos de señales son Excepciones, errores, Interrupciones y controles.

La Tabla 7 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 genera de forma síncrona una señal de excepción apropiada cada vez que se produce una condición muy grave.
Errores
La JVM genera una SIGABRT si detecta una condición de la que no se puede recuperar.
Interrupciones
Las señales de interrupción se generan de forma asíncrona, desde fuera de un proceso de la JVM, para solicitar la conclusión.
Controles
Otras señales que utiliza la JVM con fines de control.

Tabla 7. Señales utilizadas por la JVM
Nombre de señal Tipo de señal Descripción Inhabilitada por -Xrs
SIGBUS (7) Excepción Acceso incorrecto a la memoria (desalineación de datos)
SIGSEGV (11) Excepción Acceso incorrecto a la memoria (escritura en memoria inaccesible)
SIGILL (4) Excepción Instrucción no permitida (intento de invocar una instrucción de máquina desconocida) No
SIGFPE (8) Excepción Excepción de coma flotante (división por cero)
SIGABRT (6) Error Terminación anormal. La JVM lanza esta señal cada vez que detecta una anomalía en la JVM.
SIGINT (2) Interrupción Atención interactiva (Control-C). La JVM sale normalmente.
SIGTERM (15) Interrupción Petición de terminación. La JVM saldrá normalmente.
SIGHUP (1) Interrupción Cortar. La JVM sale normalmente.
SIGQUIT (3) Control Señal de salida para un terminal. De forma predeterminada, esto activa un Javadump.
SIGTRAP (5) Control La utiliza la JIT.
__SIGRTMAX - 2 Control La utiliza el SDK. No
SIGCHLD (17) Control La utiliza el SDK para 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 Java de Sun.

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

Runtime Environment contiene un encadenamiento de señales. El encadenamiento de señales permite a la JVM interactuar 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.

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

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.

Para utilizar libjsig.so:

La variable de entorno JAVA_HOME debe establecerse en la ubicación del SDK, por ejemplo, /opt/ibm/java-i386-60/.

Para utilizar libjsig.a:

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) y JNI_VERSION_1_4(0x00010004).

Restricción: La versión 1.1 de JNI (Java Native Interface) no está soportada.

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 lo especifican las bibliotecas JSE, esto es, v6. 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/javase/6/docs/technotes/guides/jni/.

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

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

gcc -I/opt/ibm/java-i386-60/include -L/opt/ibm/java-i386-60/jre/lib/<arch>/j9vm 
-ljvm -ldl -lpthread <nombre archivo 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.

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

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 conectores bloqueados. Las nuevas clases están empaquetadas en core.jar.

Estas clases le 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 todo el proceso, 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
Una clase de utilidad para interrumpir llamadas de sincronización.
public class InterruptibleIOContext
Una clase de utilidad para interrumpir llamadas de red.
public class InterruptibleThread
Una clase de utilidad que amplía java.lang.Thread, para permitir la encapsulación de métodos 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.

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

El Javadoc de estas clases se proporciona con el SDK en el directorio docs/content/apidoc.

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 un número de páginas grandes, durante 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 root. Para utilizar páginas grandes, ejecute Java como root o establezca el bit suid del iniciador de Java.

Soporte CORBA

JSE(Java Platform, Standard Edition) da soporte como mínimo a las especificaciones definidas en el documento de conformidad de Sun. En algunos casos, IBM JSE ORB da soporte a versiones más recientes de las especificaciones.

Las especificaciones mínimas soportadas están definidas en la sección Especificaciones oficiales para el soporte de CORBA en Java SE 6.

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.

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 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 predeterminado 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 predeterminado 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 Java Core de Sun en Versión 6. 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 se conecta al ORB. Este mecanismo es provisional y no es compatible con futuras versiones ni se puede trasladar a otros ORB que no son 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.

Propiedades de rastreo

com.ibm.CORBA.Debug=true
Activa el rastreo de ORB.
com.ibm.CORBA.CommTrace=true
Añade mensajes GIOP (enviados y recibidos) al rastreo.
com.ibm.CORBA.Debug.Output=<archivo>
Especifique el archivo de salida de rastreo. De forma predeterminada, tiene el formato orbtrc.DDMMAAAA.HHmm.SS.txt.

Ejemplo de rastreo de ORB

Por ejemplo, para rastrear sucesos y mensajes de GIOP formateados, en la línea de mandatos, escriba:

java -Dcom.ibm.CORBA.Debug=true
     -Dcom.ibm.CORBA.CommTrace=true <miaplic>

Limitaciones

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 se notifican los errores graves. Si se genera un archivo de salida de depuración, examínelo para controlar 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

El ORB se puede ajustar para que funcione debidamente con una red específica. Las propiedades necesarias para ajustar el ORB se describen a continuación.

com.ibm.CORBA.FragmentSize=<tamaño en bytes>
Se utiliza para controlar la fragmentación de GIOP 1.2. El tamaño predeterminado es de 1024 bytes.

Para inhabilitar la fragmentación, establezca el tamaño del fragmento en 0 bytes:

java -Dcom.ibm.CORBA.FragmentSize=0 <miapli>
com.ibm.CORBA.RequestTimeout=<tiempo en segundos>
Establece el tiempo de espera máximo para una petición CORBA. De forma predeterminada, el ORB espera de forma indefinida. No establezca el tiempo de espera demasiado bajo para que las conexiones no finalicen de forma innecesaria.
com.ibm.CORBA.LocateRequestTimeout=<tiempo en segundos>
Establece el tiempo de espera máximo para una petición CORBA. De forma predeterminada, el ORB espera de forma indefinida.
com.ibm.CORBA.ListenerPort=<número de puerto>
Establece el puerto para el ORB para que lea las peticiones de entrada. Si se establece esta propiedad, el ORB empieza a escuchar tan pronto como se inicializa. De lo contrario, empezará a escuchar sólo cuando sea necesario.

Permisos de seguridad Java para el ORB

Cuando se ejecuta con Java 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. Si el programa utiliza alguno de estos métodos, compruebe que tenga los permisos necesarios.

Tabla 8. Métodos afectados cuando se ejecuta con Java 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

Clases de implementación de ORB

Una lista de las clases de implementación de ORB.

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

Estos son los valores predeterminados, 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

Java RMI (Remote Method Invocation) proporciona un sencillo mecanismo para la programación Java distribuida. RMI-IIOP (RMI over IIOP) utiliza el protocolo IIOP (Internet Inter-ORB Protocol) estándar de CORBA (Common Object Request Broker Architecture) para ampliar Java RMI básico de modo que pueda realizar comunicaciones. Esto permite la interacción directa con cualquier otro ORB(Object Request Brokers) de CORBA, tanto si se implementa en Java o en cualquier otro lenguaje de programación.

La siguiente documentación está disponible:

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 de forma predeterminada.

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

-Dsun.rmi.transport.tcp.connectionPool=true

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

BigDecimal mejorado

A partir de Java 5.0, la clase IBM BigDecimal ha sido adoptada por Sun como java.math.BigDecimal. La clase com.ibm.math.BigDecimal está reservada para uso futuro de IBM y está obsoleta actualmente. Migre el código Java existente para que utilicejava.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. Las dos clases no se serializan.

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

Plug-in, Applet Viewer y Web Start

El plug-n de Java se utiliza para ejecutar aplicaciones Java en el navbegador. The appletviewer sirve para probar aplicaciones diseñadas para que se ejecuten en un navegador. Java Web Start se utiliza para desplegar aplicaciones Java de escritorio sobre una red y proporciona un mecanismo para mantenerlas actualizadas. a mechanism for keeping them up-to-date.

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

El Plug-in Java es un plug-in de navegador web. El Plug-in Java se utiliza para ejecutar applets en el navegador.

Debe dejar que los applets terminen de cargarse para evitar que el navegador 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, es posible que las páginas HTML no se puedan cargar.

El Plug-in Java está documentado por Sun en: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.

Navegadores soportados

El plug-in Java soporta SeaMonkey,Mozilla, y Mozilla Firefox.

Tabla 9. Navegadores soportados por el plug-in Java en Linux IA32
Navegador Versiones soportadas
Mozilla 1.7.12, 1.8
Firefox 1.5, 2.0
Tabla 10. Navegadores soportados por el plug-in Java en Linux PPC32
Navegador Versiones soportadas
Mozilla 1.6
|SeaMonkey |1.0.8

Los releases menores posteriores de los navegadores también están soportados.

Instalación y configuración del plug-in Java

Para instalar el plug-in Java, enlácelo simbólicamente al directorio de plug-ins de su navegador.

El plug-in Java se basa en la iniciativa Open JVM Integration de Mozilla, que se utiliza con la mayoría de los productos Mozilla y derivados, incluido Firefox.

A continuación encontrará instrucciones para instalar el plug-in en algunos navegadores comunes.

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

Mozilla

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

  1. Inicie la sesión como usuario root.
  2. Vaya al directorio de plug-ins de Mozilla (este directorio puede ser diferente en algunas distribuciones Linux).
  3. Cree un enlace simbólico al plug-in.
     ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .
    Donde <arch> es la arquitectura de su sistema.

Para verificar que el Plug-in Java está disponible y habilitado, seleccione Ayuda -> Acerca de Plug-ins en Mozilla.

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

Restricción: Sólo puede tener una biblioteca compartida de Plug-in Java en /usr/local/mozilla/plugins/. Mozilla intenta cargar cualquier cosa que hay en ese directorio (o en los subdirectorios dentro del mismo) como un Plug-in, y los resultados son imprevisibles si se cargan dos versiones del Plug-in Java.

Firefox

Estos pasos harán que el plug-in Java esté disponible para todos los usuarios

  1. Inicie la sesión como usuario root.
  2. Vaya al directorio de plug-ins de Firefox (este directorio puede ser diferente en algunas distribuciones Linux).
    cd /usr/local/mozilla-firefox/plugins/
  3. Cree un enlace simbólico al plug-in.
     ln -s /opt/ibm/java-i386-60/jre/plugin/<arch>/ns7/libjavaplugin_oji.so .
    Donde <arch> es la arquitectura de su sistema.

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

Soporte de DOM (Document Object Model) común

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

Se generará uno de los errores siguientes:

Utilización de parámetros DBCS

El plug-in Java 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 plug-in Java 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 este modo:

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

Este ejemplo le indica al navegador que utilice la codificación de caracteres chinos BIG-5 para analizar el archivo HTML.

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

Utilice el mandato siguiente para ejecutar un applet con el visor de applets.

En un indicador del shell, escriba:

   appletviewer <nombre>

donde <nombre> es uno de los siguientes:

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

  appletviewer $HOME/<nombrearchivo>.html

Donde nombrearchivo es el nombre del archivo HTML.

Para invocar el Visor de applets en una página web, escriba en un indicador del 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 el Visor de applets no está codificado como el valor predeterminado 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.

Por ejemplo:

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

Puede documentación sobre cómo depurar applets utilizando el Visor de applets en el sitio web de Sun: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html.

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

Java Web Start se utiliza para el despliegue de aplicaciones Java.

Web Start permite iniciar y gestionar aplicaciones directamente desde la Web. Las aplicaciones se colocan en la memoria caché para minimizar los tiempos de instalación. Las aplicaciones se actualizan automáticamente cuando hay versiones nuevas disponibles.

Web Start soporta estos java-vm-args que se describen en http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html#resources:

IBM Web Start también da soporte a -Xgcpolicy para establecer la política de recogida de basura.

Para obtener información acerca de los navegadores que dan soporte a Web Start, consulte la sección Navegadores soportados.

Para obtener más información acerca de Web Start, consulte:

Para obtener más información acerca del despliegue de aplicaciones, consulte:

Ejecución de Web Start

Web Start puede ejecutarse desde una página web o desde la línea de mandatos. Las aplicaciones Web Start se almacenan en la memoria caché de aplicaciones de Java.

Java Web Start Versión 6 se instala automáticamente cuando se instala Java utilizando los paquetes .rpm o .tgz. Si extrae Java desde el paquete .tgz, ejecute el script del shell jre/lib/javaws/updateSettings.sh para actualizar los archivos .mailcap y .mime.types en el sistema.

Puede invocar Web Start de varias formas diferentes.

(Sólo Linux IA de 32 bits) WebStart Secure Static Versioning

La creación de versiones estáticas permite que las aplicaciones Web Start soliciten su ejecución en una versión específica de la JVM. Dado que esta solución permite que las aplicaciones se aprovechen de las antiguas vulnerabilidades de seguridad de los sistemas que se han actualizado a una nueva JVM, de forma predeterminada ahora se utiliza SSV (Secure Static Versioning).

Con SSV, se avisa al usuario antes de ejecutar cualquier aplicación Web Start no firmada que solicite el uso de una JVM específica. Las aplicaciones firmadas y las aplicaciones que solicitan la versión más reciente de la JVM se ejecutan con normalidad.

Puede inhabilitar SSV estableciendo la propiedad deployment.javaws.ssv.enabled del archivo deployment.properties en false.

Envío de aplicaciones Java

Las aplicaciones Java suelen constar de archivos de datos, recursos y clases.

Cuando se envía una aplicación Java, el paquete de software suele estar formado por los siguientes componentes:

Para ejecutar la aplicación, los usuarios necesitan 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 de 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.

Datos de clases compartidos entre las JVM

Esta solución permite que varias JVM compartan un solo espacio de la memoria.

Java Virtual Machine (JVM) permite compartir datos de clases entre las JVM almacenándolos en un archivo de la memoria caché correlacionado por la memoria en el disco. Al compartir los datos de clases se disminuye el consumo global de memoria virtual cuando más de una JVM comparte una memoria caché. También se disminuye el tiempo de arranque de una JVM después de que se ha creado la memoria caché. La memoria caché de clases compartidas es independiente de cualquier JVM activa y persiste hasta que se destruye.

Una memoria caché compartida puede contener:

Visión general de la función de compartir datos de clases

Compartir datos de clases proporciona un método transparente de reducir el espacio de memoria y mejorar el tiempo de inicio de JVM. |Java 6 |proporciona características nuevas y mejoradas en cuanto a gestión, aislamiento y rendimiento de la memoria caché.

Habilitar la función de compartir datos de clases

Utilice la opción -Xshareclasses para permitir que se compartan datos cuando se inicia una JVM. La JVM se conectará a una memoria caché existente o creará una nueva memoria caché con ese nombre.

Todas las clases de aplicación y de rutina de carga cargadas por la JVM se comparten de forma predeterminada. Los cargadores de clases personalizados comparten clases 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 JVM para acceder a la memoria caché. (Consulte el apartado Adaptación de cargadores de clases personalizados para compartir clases.)

|La JVM también puede almacenar código compilado AOT (ahead-of-time) en la memoria caché para que determinados métodos mejoren el tiempo de arranque en las JVM posteriores. El código compilado AOT no se comparte de hecho entre las JVM, pero se almacena en caché para reducir el tiempo de compilación cuando se inicia la JVM. La cantidad de código AOT almacenado en la memoria caché se determina de forma heurística. No puede controlar qué métodos se almacenan en la memoria caché, pero puede establecer los límites superiores e inferiores |en la cantidad de espacio de memoria caché para el código AOT o puede elegir inhabilitar el almacenamiento en caché AOT por completo. |Consulte el apartado Habilitación y configuración de la función de compartir datos de clases para obtener más información.

Acceso a la memoria caché

|Una JVM |puede acceder a una memoria caché con acceso de sólo escritura o sólo lectura. Cualquier JVM conectada a una memoria caché con acceso de escritura-lectura puede actualizar la memoria caché. Cualquier número de JVM puede leerse simultáneamente desde la memoria caché, incluso mientras otra JVM esté escribiendo en ella.

Debe prestar atención si utiliza la modificación del código bytecode en el tiempo de ejecución. Consulte el apartado Modificación del código bytecode en el tiempo de ejecución para obtener más información.

Actualización dinámica de la memoria caché

Como la memoria caché de clases compartidas persiste después de la vida útil de la JVM, la memoria caché 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 memoria caché sea transparente para la aplicación que la utiliza.

Seguridad de memoria caché

El acceso a la memoria caché de las clases compartidas se limita mediante permisos del sistema operativo y permisos de seguridad Java. La memoria caché de clases compartida se crea de forma predeterminada con acceso de usuario, a menos que se utilice la subopción de línea de mandatos groupAccess. Sólo un cargador de clases que se haya registrado para compartir datos de clases puede actualizar la memoria caché de clases compartidas.

|La memoria caché está protegida de la corrupción accidental o deliberada utilizando la protección de página de memoria. Esto no garantiza en absoluto que se corrompan los datos porque la JVM debe desproteger las páginas para poder escribir en ellas. La única manera de garantizar que una memoria caché no pueda modificarse es abrirla en sólo lectura.

Si se instala Java SecurityManager, se debe conceder permiso a los cargadores de clases, excepto a los cargadores de clases predeterminados de rutina de carga, aplicación y extensión, para que puedan compartir clases, añadiendo líneas SharedClassPermission al archivo java.policy. (Consulte el apartado Utilización de SharedClassPermission.) Con RuntimePermission "createClassLoader" se limita la creación de nuevos cargadores de clases y, por lo tanto, se limita también el acceso a la memoria caché.

Ciclo de vida de la memoria caché

En un sistema pueden existir varias memorias caché, que se especifican por el nombre como una subopción del mandato -Xshareclasses. Una JVM puede conectarse únicamente con una memoria caché cada vez.

Puede alterar temporalmente el tamaño de la memoria caché predeterminado durante el arranque utilizando -Xscmx<n><size>; este tamaño queda fijo mientras dure la memoria caché. Las memorias caché existen hasta que se destruyen de forma explícita utilizando una subopciónen el mandato -Xshareclasses o el archivo de memoria caché se suprime manualmente.

Programas de utilidad de memoria caché

Todos los programas de utilidad de memoria caché son subopciones en el mandato -Xshareclasses. Consulte el apartado Habilitación y configuración de la función de compartir datos de clases o utilice -Xshareclasses:help para obtener una lista de las subopciones disponibles.

Habilitación y configuración de la función de compartir datos de clases

Los programas de utilidad para compartir datos de clases y gestionar la memoria caché se controlan mediante opciones de la línea de mandatos en el iniciador java.

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

-Xscmaxaot<tamaño>
Establece el número máximo de bytes de la memoria caché que se puede utilizar para los datos AOT. Utilice esta opción para garantizar que una determinada cantidad del espacio de la memoria caché está disponible para los datos que no son AOT. De forma predeterminada, el límite máximo para los datos AOT es la cantidad de espacio libre de la memoria caché. El valor de esta opción debe ser más pequeño que el valor de -Xscminaot y no debe ser mayor que el valor de -Xscmx.
-Xscminaot<tamaño>
Establece el número mínimo de bytes de la memoria caché que se reserva para datos AOT. De forma predeterminada, no se reserva espacio para los datos AOT, aunque los datos AOT se graban en la memoria caché hasta que ésta se llena o hasta que se alcanza el límite de -Xscmaxaot. El valor de esta opción no debe superar el valor de -Xscmx o -Xscmaxaot. El valor de -Xscminaot siempre debe ser considerablemente menor que el tamaño total de la memoria caché, ya que los datos AOT sólo se pueden crear para las clases guardadas en la memoria caché. Si el valor de -Xscminaot es igual al valor de -Xscmx, no se almacenan datos de clases ni datos AOT porque los datos AOT deben asociarse con una clase en la memoria caché.
-Xscmx<tamaño>
Especifica el tamaño de la memoria caché. Esta opción sólo se aplica si se está creando una memoria caché y no existe ninguna memoria caché con el mismo nombre. El tamaño de la memoria caché predeterminado depende de la plataforma. Puede averiguar el valor del tamaño que se está utilizando si añade -verbose:sizes como argumento de línea de mandatos. El tamaño mínimo de la memoria caché es de 4 KB. El tamaño máxio de la memoria caché también depende de la plataforma. (Consulte el apartado Límites del tamaño de la memoria caché.)
-Xshareclasses:<subopción>[,<subopción>...]
Habilita la función de compartir datos de clases. Puede utilizar varias subopciones, algunas de las cuales son programas de utilidad de memoria caché. Los programas de utilidad de memoria caché ejecutan la operación necesaria en la memoria caché especificada, sin iniciar la VM. Puede combinar varias subopciones, separadas por comas, pero los programas de utilidad de memoria caché son mutuamente excluyentes. Cuando se ejecutan programas de utilidad de memoria caché, se espera el mensaje "No se ha podido crear la máquina virtual Java". Los programas de utilidad de memoria caché no crean la máquina virtual.

Algunos programas de utilidad de memoria caché pueden funcionar con memorias caché de versiones Java anteriores o de memorias caché creadas por las JVM con diferentes anchos de bits. Se hace referencia a estas memorias caché como memorias caché "incompatibles".

Puede utilizar las subopciones siguientes con la opción -Xshareclasses:

help
Lista todas las subopciones de la línea de mandatos.
name=<nombre>
Se conecta a una memoria caché con un nombre determinado y la crea si no existe previamente. También se utiliza para indicar la memoria caché que han de modificar los programas de utilidad de memoria caché, por ejemplo, destroy. Utilice el programa de utilidad listAllCaches para mostrar qué memorias caché con nombres están disponibles actualmente. Si no especifica un nombre, se utiliza el nombre predeterminado "sharedcc_%u". %u en el nombre de memoria caché insertará el nombre de usuario actual. Puede especificar %g en el nombre de memoria caché para insertar el nombre de grupo actual.
|cacheDir=<directorio>
|Establezca el directorio en el que se leerán y escribirán los datos de la memoria caché. De forma predeterminada,<directorio> es /tmp/javasharedresources. El usuario debe tener permisos adecuados dentro del <directorio>. De forma predeterminada, la JVM escribe los archivos de memoria caché persistentes directamente en el directorio especificado. Los archivos de memorias caché persistentes se pueden mover de forma segura y suprimirse del sistema de archivos. Las memorias caché persistentes se almacenan en memoria compartida y tienen archivos de control que describen la ubicación de la memoria. Los archivos de control se almacenan en un subdirectorio javasharedresources delcacheDir especificado. |Los archivos de control en este directorio no debe moverse ni suprimirse manualmente. El programa de utilidad listAllCaches, el programa de utilidad destroyAll y la subopción expire sólo funcionan en el ámbito de un |determinado cacheDir.
|readonly
|Abre una memoria caché existente con permisos de sólo lectura. La JVM no creará una memoria |caché nueva con esta subopción. Si abre una memoria caché de sólo lectura impide que la JVM |efectúe las actualizaciones a la memoria caché. También permite que la JVM se conecte a las memorias |caché creadas por otros usuarios o grupos sin precisar acceso de escritura. De forma predeterminada, esta |subopción no está especificada.
|nonpersistent
|Utiliza una memoria caché no persistente. De forma predeterminada, la JVM crea un archivo de memoria caché en el disco |que persiste después de que se reinicie el sistema operativo. La subopción nonpersistent crea la memoria caché en la memoria compartida que se pierde cuando concluye el sistema operativo. Las memorias caché persistentes y no persistentes tienen el mismo nombre, la subopción |nonpersistent se debe utilizar siempre cuando se ejecutan programas de utilidad, tales como |destroy en una memoria caché no persistente. De forma predeterminada, esta opción no está especificada.
groupAccess
Establece los permisos del sistema operativo en una memoria caché nueva para permitir el acceso de grupo a la memoria caché. El valor predeterminado es sólo acceso de usuario.
verbose
Habilita la salida verbosa, que proporciona estado global sobre la memoria caché de la clase compartida y más mensajes de error detallados.
|verboseAOT
|Habilita la salida en modalidad verbosa cuando se encuentra o se almacena en la memoria caché el código AOT compilado. El código AOT se genera de modo heurístico. Es posible que no vea ningún código AOT generado para una aplicación pequeña. El almacenamiento en caché AOT se puede inhabilitar utilizando la subopción noaot.
verboseIO
Proporciona salida detallada de la actividad de E/S de la memoria caché, que lista información sobre las clases almacenadas y encontradas. 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 activa, 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 está previsto para la jerarquía de ClassLoader.
verboseHelper
Habilita la salida en modalidad verbosa para la API Java Helper. Esta salida muestra cómo ClassLoader utiliza la API Helper.
silent
Inactiva todos los mensajes de clases compartidos, incluidos los mensajes de error.
nonfatal
Permite que la JVM se inicie incluso cuando se producen errores al compartir datos de clases. El comportamiento normal de la JVM es negarse a reiniciarse si falla la función de compartir datos de clases. Si se selecciona nonfatal y la memoria caché de clases compartidas no se puede inicializar, la JVM intentará conectarse a la memoria caché en modalidad de sólo lectura. Si esto falla, la JVM se inicia sin la función de compartir datos de clases.
none
Se puede añadir al final de una línea de mandatos para inhabilitar la función de compartir datos de clases. Esta subopción altera temporalmente los argumentos para compartir clases que aparecen al principio en la línea de mandatos.
modified=<contexto modificado>
Se utiliza cuando se instala un agente JVMTI que puede modificar el código bytecode en tiempo de ejecución. Si no especifica esta subopción y se ha instalado un agente de modificación de código bytecode, las clases se compartirán con seguridad pero con un coste adicional para el rendimiento. El <contexto modificado> es un descriptor que selecciona el usuario, por ejemplo, "myModification1". Esta opción particiona la memoria caché, de modo que sólo las JVM que utilizan el contexto myModification1 pueden compartir las mismas clases. Por ejemplo, si ejecuta HelloWorld con un contexto de modificación y luego vuelve a ejecutarlo con un contexto de modificación diferente, verá todas las clases almacenadas dos veces en la memoria caché. Consulte el apartado Modificación del código bytecode en el tiempo de ejecución para obtener más información.
|reset
|Hace que se destruya una memoria caché y, a continuación, se vuelva a crear cuando se inicie la JVM. Se puede añadir al final de una línea de mandatos como -Xshareclasses:reset.
destroy (opción de programa de utilidad)
Destruye una memoria caché especificada por las subopciones name, cacheDir y nonpersistent. Una memoria caché sólo se puede destruir si todas las JVM que la utilizan han concluido y el usuario tiene permisos suficientes.
destroyAll (opción de programa de utilidad)
Intenta destruir todas las memorias caché disponibles utilizando las subopciones cacheDir ynonpersistent. Una memoria caché sólo se puede destruir si todas las JVM que la utilizan han concluido y el usuario tiene permisos suficientes.
expire=<período de tiempo en minutos>
estruye todas las memorias caché que no se han utilizado durante el período de tiempo especificado antes de que se carguen las clases compartidas. No se trata de una opción de programa de utilidad porque no hace que la JVM salga.
listAllCaches (opción de programa de utilidad)
Lista todas las memorias caché compatibles y no compatibles que existen en el directorio de la memoria caché especificada. Si no se ha especificado cacheDir, se utiliza el directorio predeterminado. La información de resumen, como por ejemplo la versión de Java y el uso actual se muestran para cada memoria caché.
printStats (opción de programa de utilidad)
Muestra información de resumen para la memoria caché especificada por las subopciones name, cacheDir y nonpersistent. La información más útil que se muestra es cómo está de llena la memoria caché y cuántas clases contiene. Las clases obsoletas son clases que se han actualizado en el sistema de archivos y que, por lo tanto, la memoria caché ha marcado como "obsoletas". Las clases obsoletas no se depuran de la memoria caché y se pueden volver a utilizar. Consulte la Guía de diagnósticos para obtener más información.
printAllStats (opción de programa de utilidad)

Muestra información detallada para la memoria caché especificada por las subopciones name, cacheDir y nonpersistent. Cada clase aparece en orden cronológico junto con una referencia a la ubicación desde la que se ha cargado. El código AOT para métodos de clases también se lista.

Consulte la

Guía de diagnósticos para obtener más información.

|mprotect=[ all || default | none ]
|De forma predeterminada, las páginas de la memoria que contienen la memoria caché |está protegidas en todo momento, a menos que se esté actualizando una determinada página. Esto contribuye a proteger |la memoria caché de una corrupción de datos deliberada o accidental. La cabecera de la memoria caché no está protegida |de forma predeterminada puesto que tiene un coste pequeño de rendimiento. Si especifica "all" se garantiza que |todas las páginas de la memoria caché estén protegidas, incluida la cabecera. Si especifica "none" se inhabilita la protección de la página.
|noBootclasspath
|Impide el almacenamiento de las clases cargadas por el classloader |de programas de arranque en la memoria caché de clases compartidas. Se puede utilizar con la API SharedClassURLFilterpara controlar exactamente qué clases se almacenan en la memoria caché. Consulte la Guía de diagnósticos para obtener más información acerca de cómo filtrar las clases compartidas.
|cacheRetransformed
|Habilita el almacenamiento en memoria caché de las clases que se han transformado utilizando la función RetransformClasses de JVMTI.
|noaot
|Inhabilita el almacenamiento en caché y la carga de código AOT.

Cómo crear, llenar, supervisar y suprimir una memoria caché

Una visión general del ciclo de vida de una memoria caché de datos de clases compartidos incluidos ejemplos de los programas de utilidad de gestión de la memoria caché.

Para permitir que se puedan compartir los datos de clases, añada -Xshareclasses[:name=<nombre>] en la línea de mandatos de la aplicación.

La JVM se conectará a una memoria caché existente con el nombre proporcionado o creará una nueva memoria caché con ese nombre. Si se crea una nueva memoria caché, se llenará con todas las clases de aplicación y de rutina de carga que se estén cargando hasta que se llene ésta. Si se inician a la vez dos o más VM, llenarán la memoria caché de forma simultánea.

Para comprobar que se ha creado la memoria caché, 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 JVM de aplicación haya terminado o en otra ventana de mandatos).

Para obtener más información acerca del uso de la memoria caché cuando se ejecuta la JVM, utilice la subopción verbose. Por ejemplo, java -Xshareclasses:[name=<nombre>],verbose.

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

Para suprimir la memoria caché creada, ejecute java -Xshareclasses:[name=<nombre>],destroy. Las memorias caché sólo se deben suprimir si contienen muchas clases obsoletas o si la memoria caché está llena y desea crear una memoria caché mayor.

Se recomienda ajustar el tamaño de la memoria caché para la aplicación específica ya que el valor predeterminado probablemente no sea el tamaño óptimo. El mejor modo de determinar el tamaño óptimo de la memoria caché es especificar una memoria caché grande (utilizando -Xscmx), ejecutar la aplicación y luego utilizar printStats para determinar cuántos datos de clases se han almacenado. Añada una pequeña cantidad al valor que aparece en printStats para prevenir contingencias. Tenga en cuenta que debido a que las clases se pueden cargar en cualquier momento durante la vida útil de la JVM, es mejor realizar este análisis después de que la aplicación haya finalizado. No obstante, una memoria caché llena no tiene un impacto negativo en el rendimiento ni en la capacidad de cualquier JVM que esté conectada a la misma, por lo tanto, resulta legítimo optar por un tamaño de memoria caché más pequeño de lo necesario.

Si una memoria caché se llena, se muestra un mensaje en la línea de mandatos de cualquier JVM que utilice la subopción verbose. Todas las JVM que compartan la memoria caché llena cargarán las clases adicionales en su propia memoria de proceso. Las clases de una memoria caché llena se pueden compartir pero una memoria caché llena es de sólo lectura y no se puede actualizar con clases nuevas.

Rendimiento y consumo de memoria

Compartir datos de clases resulta especialmente útil en sistemas que utilizan más de una JVM que ejecute código similar, ya que el sistema se beneficia de la reducción en el consumo de memoria virtual. También resulta útil en los sistemas que arrancan y concluyen las JVM con frecuencia, ya que se benefician de un mejor tiempo de arranque.

La carga adicional que supone crear y llenar una nueva memoria caché es mínima. Generalmente, el tiempo de arranque que emplea una sola JVM resulta de un 0 a un 5 por cien más lento comparado con un sistema que no comparte los datos de clases, dependiendo del número de clases cargadas. Cuando la memoria caché está llena, el tiempo de arranque de la JVM mejora su velocidad entre un 10 y un 40 por ciento comparado con un sistema que no comparte datos de clases, dependiendo del sistema operativo y del número de clases cargadas. Si se ejecutan varias JVM al mismo tiempo las ventajas del tiempo global de arranque serán mayores.

Las clases duplicadas se consolidan en la memoria caché de clases compartidas. Por ejemplo, una clase A cargada desde myClasses.jar y una clase A cargada desde myOtherClasses.jar (con contenido idéntico) se almacena sólo una vez en la memoria caché. El programa de utilidad printAllStats muestra varias entradas para las clases duplicadas y cada una de las entradas apunta a la misma clase.

Cuando ejecuta la aplicación compartiendo los datos de clases, puede utilizar las herramientas del sistema operativo para ver cómo disminuye el consumo de la memoria virtual.

Consideraciones y limitaciones a la hora de utilizar la función de compartir datos de clases

Factores que hay que tener en cuenta a la hora de desplegar compartir datos de clases en un productos y compartir datos de clases en un entorno de desarrollo.

Límites del tamaño de la memoria caché

En teoría, el tamaño máximo de la memoria caché es 2 GB. El tamaño de la memoria caché que puede especificar queda limitado por la cantidad de memoria física y de espacio de paginación disponible en el sistema.

La memoria caché para compartir clases se asigna utilizando el mecanismo de memoria compartida System V IPC.

Dado que el espacio de direcciones virtuales de un proceso se comparte entre la memoria caché de clases compartidas y el almacenamiento dinámico de Java, si se aumenta el tamaño máximo del almacenamiento dinámico de Java puede disminuir el tamaño de la memoria caché de clases compartidas que puede crear.

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

Modificación del código bytecode en el tiempo de ejecución

Cualquier JVM que utilice un agente JVMTI (JVM Tool Interface) que puede modificar datos del código bytecode deben utilizar la subopción modified=<contexto_modificado> si desea compartir las clases modificadas con otra JVM.

El contexto modificado es un descriptor especificado por el usuario que describe el tipo de modificación que se está realizando. El contexto modificado particiona la memoria caché, de modo que todas las JVM que se ejecutan bajo el mismo contexto comparten una partición.

Esta partición permite que las JVM que no utilizan código bytecode modificado compartir con seguridad una memoria caché con los que utilizan código bytecode modificado. Todas las JVM que utilicen un determinado contexto modificado deben modificar el código bytecode de forma predecible y repetible para cada clase, para que las clases modificadas almacenadas en la memoria caché tengan las modificaciones esperadas cuando las cargue otra JVM. Cualquier modificación debe ser predecible porque el agente no puede volver a modificar las clases cargadas desde la memoria caché de clases.

Si se utiliza un agente JVMTI sin un contexto de modificación, la JVM continúa compartiendo las clases se continúan pero el impacto en el rendimiento es pequeño. Utilizar un contexto de modificación con un agente JVMTI evita la necesidad de realizar comprobaciones adicionales y, por lo tanto, no afecta al rendimiento. Un ClassLoader que amplía java.net.URLClassLoader y modifica el código bytecode durante la carga sin utilizar JVMTI, almacena automáticamente dicho código bytecode modificado en la memoria caché, pero la memoria caché no trata el código bytecode como modificado. Cualquier otra VM que comparta dicha memoria caché carga las clases modificadas. Se puede utilizar la subopción modified=<contexto_modificación> del mismo modo que con los agentes JVMTI para particionar el código bytecode modificado en la memoria caché. Si un ClassLoader personalizado tiene que modificar clases de forma no predecible durante la carga, dicho ClassLoader no debe intentar compartir los datos de clases.

Consulte la Guía de diagnósticos para obtener más información sobre este tema.

Limitaciones del sistema operativo

No puede compartir clases entre las JVM de 32 bits y de 64 bits. Debe tener suficiente espacio en disco temporal disponible para guardar la información de la memoria caché. Los permisos de la memoria caché los impone el sistema operativo.

En los sistemas operativos que pueden ejecutar aplicaciones de 32 bits y 64 bits, no se puede compartir datos de clases entre las JVM de 32 bits y 64 bits. La subopción listAllCaches listará las memorias caché de 32 bits o 64 bits, dependiendo de la modalidad de dirección de la JVM que se está utilizando.

La memoria caché de clases compartidas necesita espacio de disco para almacenar información de identificación acerca de las memorias caché que existen en el sistema. Esta información se almacena en /tmp/javasharedresources. Si se suprime el directorio de información de identificación, la JVM no puede identificar las clases compartidas en el sistema y debe volver a crear la memoria caché. Utilice el mandato ipcs para ver los segmentos de memoria que utiliza una JVM o la aplicación.

Los usuarios que ejecutan una JVM deben estar en el mismo grupo para utilizar una memoria caché de clases compartidas. Los permisos para acceder a la memoria caché de clases compartidas los impone el sistema operativo. Si no se especifica un nombre de memoria caché, se añade el nombre de usuario al nombre predeterminado para que, de este modo, varios usuarios del mismo sistema puedan crear sus propias memorias caché predeterminadas.

Utilización de SharedClassPermission

Si se utiliza SecurityManager con datos de clases compartidas y la aplicación en ejecución utiliza sus propios cargadores de clases, dichos cargadores de clases deben tener permisos de clases compartidas para poder compartir las clases.

Se pueden añadir los permisos de clases compartidas al archivo java.policy utilizando el nombre de clase ClassLoader (se permiten comodines) y "read", "write" o "read,write" para determinar el acceso concedido. Por ejemplo:

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

Si un ClassLoader no tiene los permisos correctos, no podrá compartir clases. No se pueden cambiar los permisos de los cargadores de clases predeterminados de arranque, de aplicación o de extensión.

Adaptación de cargadores de clases personalizados para compartir clases

Cualquier cargador de clases que amplía java.net.URLClassLoader puede compartir clases sin modificación. Los cargadores de clase que no amplían java.net.URLClassLoader deben adaptarse para compartir datos de clase.

Se puede conceder a todos los cargadores de clases personalizados permisos de clase compartida si se utiliza un SecurityManager; consulte la sección Utilización de SharedClassPermission. IBM proporciona varias interfaces Java para los diferentes tipos de cargadores de clases personalizados, que permiten a los cargadores de clases buscar y almacenar las clases en la memoria caché de clases compartidas. Estas clases están en el paquete com.ibm.oti.shared.

El Javadoc de este paquete se proporciona con el SDK en el directorio docs/content/apidoc.

Consulte la Guía de diagnósticos para obtener más información acerca de cómo utilizar estas interfaces.

Utilización de la API Java Communications (JavaComm)

El paquete (API) Java Communications 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 Runtime Environment.

La API JavaComm ofrece a las aplicaciones Java un método independiente de la plataforma para establecer comunicaciones de puerto paralelo y serie con tecnologías como, por ejemplo, correo de voz, fax y tarjetas electrónicas.

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

Utilizando la API Java Communications puede:

Instalación de la API Java Communications desde un archivo comprimido

Asegúrese de que se ha instalado el SDK o Runtime Environment antes de instalar la API Java Communications.

Si originalmente ha utilizado el paquete RPM para instalar Java, instale la API Java Communications desde el archivo RPM. Para instalar la API Java Communications desde un paquete RPM, consulte la sección Instalación de la API Java Communications desde un archivo RPM.

Para instalar la API Java Communications desde un archivo comprimido:

  1. Coloque el archivo comprimido de la API Java Communications, ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz, en el directorio en el que está instalado el SDK o Runtime Environment. Si ha realizado la instalación en el directorio predeterminado, el directorio es /opt/ibm/java-i386-60/.
  2. En un indicador del shell, en el directorio que contiene el archivo comprimido, extraiga el contenido:
    tar -xvzf ibm-java-javacomm-3.0-0.0-<plat>-<arch>.tar.gz

    Donde <arch> representa la arquitectura: i386, x86_64, ppc o ppc64.

  3. |Copie los archivos javacomm en los directorios correctos |del SDK. | |
      |
    1. Copie lib/libLinuxSerialParallel.so en el |directorio jre/bin/.
    2. |
    3. Copie jar/comm.jar en el |directorio jre/lib/ext/.
    4. |
    5. Copie lib/javax.comm.properties en el |directorio jre/lib/.
    De forma predeterminada, el SDK se instala en el directorio /opt/ibm/java-i386-60/.

Instalación de la API Java Communications desde un archivo RPM

Asegúrese de que se ha instalado una copia del SDK o Runtime Environment antes de instalar la API Java Communications.

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

  1. Abra un indicador de shell asegurándose de iniciar la sesión como usuario root.
  2. Utilice el mandato rpm -ivh para instalar el archivo RPM de la API Java Communications. Por ejemplo:
    rpm -ivh ibm-javacomm-3.0-0.0.<arch>.rpm
    La API Java Communications se instala dentro de la estructura de directorio /opt/ibm/java-i386-60/.
  3. |Copie los archivos javacomm en los directorios correctos |del SDK. | |
      |
    1. Copie lib/libLinuxSerialParallel.so en el |directorio jre/bin/.
    2. |
    3. Copie jar/comm.jar en el |directorio jre/lib/ext/.
    4. |
    5. Copie lib/javax.comm.properties en el |directorio jre/lib/.
    De forma predeterminada, el SDK se instala en el directorio /opt/ibm/java-i386-60/.

Ubicación de los archivos de la API Java Communications

Los archivos de la API Java Communications se instalan de forma predeterminada en el directorio /opt/ibm/java-i386-60/. Los archivos y su estructura son:

Configuración de la API Java Communications

Para utilizar la API Java Communications, debe cambiar el modo de acceso de los puertos serie y paralelos y establecer PATH si no la ha establecido al instalar Java.

Consulte Configuración de la vía de acceso.

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 y grabación a los dispositivos necesarios. Inicie la sesión como usuario root y utilice los mandatos siguientes, según corresponda:

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

Añada usuarios específicos al grupo en el que residen los dispositivos. Por ejemplo, en un sistema SUSE, los dispositivos están en el grupo uucp. Así pues, los usuarios se pueden añadir al grupo uucp para obtener acceso a los dispositivos.

Cambie la modalidad de acceso de cualquier otro puerto según sea necesario.

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

El archivo javax.comm.properties le permite especificar los prefijos de los dispositivos que pone a disposición de la API Java Communications y si son de tipo paralelo o serie. Los números de puerto se asignan secuencialmente para todos los dispositivos.

Por ejemplo, si especifica /dev/ttyS=PORT_SERIAL y los dispositivos /dev/ttyS0 y /dev/ttyS1 existen, se les asignará COM1 y COM2.

Para utilizar los conectores serie USB, descomente la línea /dev/ttyUSB=PORT_SERIAL del archivo javax.comm.properties. Si los dispositivos /dev/ttyUSB0 y /dev/ttyUSB1 existen, y COM1 y COM2 ya están definidos, los dispositivos serie USB se asignarán a los siguientes puertos de la secuencia, COM3 y COM4.

Habilitación de puertos serie en IBM ThinkPads

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

Para habilitar los puertos en la BIOS, debe utilizar la versión DOS del programa de utilidad Configuración de ThinkPad, que está disponible en el sitio de descargas de IBM ThinkPad. Para utilizar el programa de utilidad Configuración de ThinkPad, necesita un disquete de DOS arrancable. Tenga en cuenta que el programa de utilidad Configuración de ThinkPad puede haberse instalado como parte de los Programas de utilidad ThinkPad bajo Windows, dependiendo de sus opciones de instalación, en cuyo caso puede 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 esto no cambia también los valores en la BIOS. Por lo tanto, si utiliza esta aplicación con Windows, los puertos están disponibles; sin embargo, si reinicia el sistema con Linux, los puertos no estarán habilitados.

Limitación de la impresión con la API Java Communications

Cuando imprima con la API Java Communications, es posible que tenga que seleccionar "Alimentación de papel", "Continuar" o una opción similar de 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 RPM (Red Hat Package Manager) o el paquete comprimido TAR (Tape Archive).

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

Desinstalación de la API Java Communications utilizando el paquete RPM.

  1. Utilice la herramienta rpm para desinstalar el paquete. Escriba el mandato siguiente en un indicador del shell:
    rpm -e ibm-javacomm-3.0-0.0
    O también puede utilizar una herramienta gráfica como kpackage o yast2
  2. Si el directorio donde ha instalado la API Java Communications no contiene ninguna otra herramienta que necesite, elimine ese directorio de la sentencia PATH.
  3. |Si ha copiado las bibliotecas javacomm en el directorio SDK, suprima |los archivos siguientes del directorio SDK. | |
      |
    • jre/bin/libLinuxSerialParallel.so
    • |
    • jre/lib/ext/comm.jar
    • |
    • jre/lib/javax.comm.properties
    De forma predeterminada, el SDK se instala en el directorio /opt/ibm/java-i386-60/.

Desinstalación del paquete comprimido TAR (Tape Archive)

Desinstalación de la API Java Communications si ha instalado el paquete comprimido TAR.

Suprima los archivos siguientes del directorio donde los ha instalado:

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

Servicio y soporte de proveedores de software independientes

Puntos de contacto para la obtención de servicio:

Si tiene derecho a servicios para el 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 de la Web: http://www.ibm.com/partnerworld/.

Si ha contratado un servicio de soporte (por ejemplo, la Línea de soporte de IBM Personal Systems o el servicio equivalente en su país), los términos y condiciones de ese contrato de servicio determinan qué servicios, si existen, tiene derecho a recibir en relación 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.

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 utilizar el teclado, pueden consulta la descripción de las pulsaciones más útiles para las aplicaciones Swing en el documento sobre Asignaciones de enlaces de teclas para aplicaciones Swing (Swing Key Bindings) en http://www.ibm.com/developerworks/java/jdk/additional/.

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 de JComboBox no cambia de valor hasta que se selecciona un elemento. Este es el comportamiento correcto 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.

Accesibilidad de Web Start (sólo Linux IA de 32 bits PPC32 y PPC64)

Desde la Versión 5.0, Java Web Start 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 memoria caché de aplicaciones Java están disponibles en el archivo de configuración.

Comentarios sobre esta guía del usuario

Si tiene comentarios sobre esta guía del usuario, póngase en contacto mediante uno de los siguientes canales. Tenga en cuenta que estos canales no están destinados a responder a consultas técnicas, sólo son para comentarios acerca de documentación.

Envíe sus comentarios:

La letra pequeña. Si decide 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, incluido aunque sin limitarse al mismo, el desarrollo, la fabricación y el marketing de productos que incluyan dicha información.

Apéndice A. 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>, añada al número el sufijo "k" o "K" para indicar kilobytes, y "m" o "M" para indicar megabytes o "g" o "G" para indicar gigabytes.

En las opciones con el parámetro <percentage>, utilice un número del 0 al 1. Por ejemplo, 50% es 0,5.

-Xargencoding
Permite añadir secuencias de escape Unicode en la lista de argumentos. Esta opción está desactivada de forma predeterminada.
-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 predeterminado 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 vía de acceso de clases de la rutina de carga. El valor predeterminado 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 vía de acceso de clases 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 Runtime Environment. El valor predeterminado es buscar clases y recursos de rutina de carga en los directorios VM internos y en los archivos .jar.
|-Xcheck:classpath
|Muestra un mensaje de aviso si se detecta un error en la vía de acceso de clases, por ejemplo, si falta un directorio o archivo JAR.
-Xcheck:gc[:<opciones de exploración>][:<opciones de verificación>][:<opciones varias>]
Realiza comprobaciones adicionales de la recogida de basura. De forma predeterminada, no se realiza ninguna comprobación. Vea la salida de -Xcheck:gc:help para obtener más información.
-Xcheck:jni
Realiza comprobaciones adicionales de las funciones JNI. De forma predeterminada, no se realiza ninguna comprobación.
|-Xcheck:memory[:<opción>]
Identifica las pérdidas de memoria en la JVM utilizando comprobaciones estrictas que provocan la salida de la JVM en caso de error. Si no se especifica ninguna opción, se utiliza all de forma predeterminada. Vea la salida de -Xcheck:memory:help o la Guía de diagnósticos para obtener más información.
-Xcheck:nabounds
Realiza comprobaciones adicionales de las funciones JNI. De forma predeterminada, no se realiza ninguna comprobación.
-Xclassgc
Habilita la recogida de objetos de clase en cada recogida de basura. Consulte también -Xnoclassgc. De forma predeterminada, esta opción está habilitada.
-Xcodecache<tamaño>
Establece el tamaño unitario asignado a bloques de memoria para el almacenamiento de código nativo de métodos Java compilados. Se seleccionar un tamaño adecuado para la aplicación que se está ejecutando. De forma predeterminada, se selecciona de forma interna según la arquitectura de la CPU y la capacidad del sistema.
-Xcompactexplicitgc
Realiza una compactación para cada llamada a System.gc(). Consulte también -Xnocompactexplicitgc. De forma predeterminada, la compactación sólo se realiza cuando se desencadena de forma interna.
-Xcompactgc
realiza una compactación para cada recogida de basura. Consulte también -Xnocompactgc. De forma predeterminada, la compactación sólo se realiza cuando se desencadena de forma interna.
-Xconcurrentbackground<número>
Especifica el número de hebras de fondo de prioridad baja conectadas para ayudar a las hebras mutantes en la marca concurrente. El valor predeterminado es 1.
-Xconcurrentlevel<número>
Especifica el índice del "impuesto" de la asignación. Indica la proporción entre la cantidad de almacenamiento dinámico asignado y la cantidad de almacenamiento dinámico marcado. El valor predeterminado es 8.
-Xconmeter:<soa|loa|dynamic>
Determina qué uso del área, LOA (Large Object Area) o SOA (Small Object Area), se calibra y, por lo tanto, qué impuestos de asignaciones se calculan durante la marca concurrente. El impuesto de la asignación se aplica al área seleccionada. Si se especifica -Xconmeter:dynamic, el recopilador determina dinámicamente qué área se calibra según el área que se agote primero. De forma predeterminada, 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. Consulte el apartado Depuración de aplicaciones Java para obtener más información. Si se especifica -Xrunjdwp se proporciona el mismo soporte.
-Xdebug
Inicia la JVM con el depurador habilitado. De forma predeterminada, el depurador está inhabilitado.
-Xdisableexcessivegc
Inhabilita la generación de OutOfMemoryError se se invierte mucho tiempo en la GC. De forma predeterminada, esta opción está desactivada.
-Xdisableexplicitgc
Indica a la VM que las llamadas a System.gc() no deben tener ningún efecto. De forma predeterminada, las llamadas a System.gc() desencadenan una recogida de basura.
-Xdisablestringconstantgc
Impide la recogida de las series de la tabla interna de series. De forma predeterminada, esta opción está inhabilitada.
-Xdisablejavadump
Desactiva la generación de Javadump en el caso de errores y señales. De forma predeterminada, la generación de Javadump está habilitada.
-Xenableexcessivegc
Si se invierte demasiado tiempo en la GC, esta opción devuelve un NULL para las peticiones de asignación y, por lo tanto, genera una excepción OutOfMemoryError. Esta acción se realiza sólo cuando el almacenamiento dinámico se ha expandido al máximo y el GC está empleando el 95% del tiempo disponible. Este es el comportamiento predeterminado.
-Xenableexplicitgc
Indica a la VM que las llamadas a System.gc() deben desencadenar una recogida de basura. Este es el valor predeterminado.
-Xenablestringconstantgc
Habilita la recogida de las series de la tabla interna de series. De forma predeterminada, 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 predeterminadas en los próximos releases. De forma predeterminada, 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 basura. Consulte el apartado Opciones de recogida de basura para obtener más información.
-Xgcthreads<número de hebras>
Establece el número de hebras de ayuda que se utilizan para las operaciones paralelas durante la recogida de basura. De forma predeterminada, el número de hebras se establece como el número de unidades CPU físicas presentes -1, con un mínimo de 1.
-Xgcworkpackets<número>
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 máximo del almacenamiento dinámico.
-Xint
Hace que la JVM sólo utilice el intérprete, e inhabilita el compilador JIT (Just-In-Time). De forma predeterminada, el compilador JIT está habilitado.
-Xiss<tamaño>
Establece el tamaño inicial de la pila de hebras Java. De forma predeterminada, es 2 KB. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
|-Xjarversion
|Consulte Obtención de la información de versión.
-Xjit[:<subopción>,<suboption>...]
Habilita el JIT. Para obtener más información sobre las subopciones, consulte la Guía de diagnósticos. Consulte también -Xnojit. De forma predeterminada, 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. De forma predeterminada, los números de línea están activados.
-Xloa
Asigna una LOA (Large Object Area). Los objetos se asignarán a esta LOA en lugar de a la SOA. De forma predeterminada, la LOA se habilita para todas las políticas de GC, excepto para la subagrupación, donde la LOA no está disponible. Consulte también -Xnoloa.
-Xloainitial<porcentaje>
El <porcentaje> es entre 0 y 0,95, que especifica el porcentaje inicial del espacio de almacén actual asignado al área de objetos grandes (LOA). El valor predeterminado es 0,05 o 5%.
-Xloamaximum<porcentaje>
El <porcentaje> es entre 0 y 0,95, que especifica el porcentaje máximo del espacio de almacén actual asignado a LOA (Large Object Area). El valor predeterminado es 0,5 o 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: La configuración del sistema no admite la opción --> '-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. De forma predeterminada, 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 basura expande el almacenamiento dinámico. Normalmente, cuando el espacio libre desciende por debajo del 30% (o por debajo de la cantidad que se haya especificado mediante -Xminf) el recopilador de basura amplía el almacenamiento dinámico con 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. De forma predeterminada, no hay ningún tamaño de expansión máximo.
-Xmaxf<porcentaje>
Especifica el porcentaje máximo de almacenamiento dinámico que debe quedar libre después de una recogida de basura. Si el espacio libre sobrepasa esta cantidad, la JVM intenta mermar el almacenamiento dinámico. El valor predeterminado es 0,6 (60%).
-Xmca<tamaño>
Establece el paso de ampliación de la memoria asignada para almacenar la parte de RAM de las clases cargadas. Cada vez que se necesita más memoria en la RAM para almacenar clases, la memoria asignada se aumenta en esta cantidad. De forma predeterminada, el paso de ampliación es 32 KB. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmco<tamaño>
Establece el paso de ampliació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. De forma predeterminada, el paso de ampliación es 128 KB. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmine<tamaño>
Establece la cantidad mínima a la que el recopilador de basura expande el almacenamiento dinámico. Normalmente, el recopilador de basura expande el almacenamiento dinámico a la cantidad necesaria para restaurar el espacio libre al 30% (o la cantidad especificada mediante -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 en un mínimo de 50 MB. De forma predeterminada, el tamaño mínimo de expansión es 1 MB.
-Xminf<porcentaje>
Especifica el porcentaje mínimo de almacenamiento dinámico que debe quedar libre después de una recogida de basura. Si el espacio libre es menor de esta cantidad, la JVM intenta expandir el almacenamiento dinámico. De forma predeterminada, el valor mínimo es 0,3 (30%).
-Xmn<tamaño>
Establece el tamaño máximo e inicial del nuevo almacenamiento dinámico (vivero) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. Establecer -Xmn es equivalente a establecer -Xmns y -Xmnx. 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. De forma predeterminada, -Xmn se selecciona de forma interna según la capacidad del sistema. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmns<tamaño>
Establece el tamaño inicial del nuevo almacenamiento dinámico (vivero) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. De forma predeterminada, 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. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmnx<tamaño>
Establece el tamaño máximo del nuevo almacenamiento dinámico (vivero) en el valor especificado cuando se utiliza -Xgcpolicy:gencon. De forma predeterminada, 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. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmo<tamaño>
Establece el tamaño máximo e inicial del antiguo almacenamiento dinámico 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. De forma predeterminada, -Xmo se selecciona de forma interna según la capacidad del sistema. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmoi<tamaño>
Establece qué cantidad de almacenamiento dinámico de Java se aumenta cuando se utiliza -Xgcpolicy:gencon. Si se establece en cero, no se permite ninguna expansión. De forma predeterminada, el tamaño del incremento se calcula según el tamaño de expansión, -Xmine y -Xminf.
-Xmos<tamaño>
Establece el tamaño inicial del antiguo almacenamiento dinámico en el valor especificado cuando se utiliza -Xgcpolicy:gencon. De forma predeterminada, 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. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmox<tamaño>
Establece el tamaño máximo del antiguo almacenamiento dinámico en el valor especificado cuando se utiliza -Xgcpolicy:gencon. De forma predeterminada, 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. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmr<tamaño>
Establece el tamaño del "conjunto recordado" de la recogida de basura cuando se utiliza -Xgcpolicy:gencon. Se trata de una lista de objetos del almacenamiento dinámico antiguo (almacén) que incluyen referencias a objetos del almacenamiento dinámico nuevo (vivero). De forma predeterminada, esta opción se establece en 16 kilobytes. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmrx<tamaño>
Establece el valor del tamaño máximo recordado.
-Xms<tamaño>
Establece el tamaño inicial del almacenamiento dinámico Java. También puede utilizar -Xmo. De forma predeterminada, -Xmo se selecciona de forma interna según la capacidad del sistema. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmso<tamaño>
Establece el tamaño de pila C de las hebras de bifurcación Java. De forma predeterminada, esta opción se establece en 32 KB para las plataformas de 32 bits y en 256 KB para las plataformas de 64 bits. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xmx<tamaño>
Establece el tamaño máximo de pila Java. De forma predeterminada, esta opción se establece internamente según la capacidad del sistema. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xnoclassgc
Inhabilita la recogida de basura de clases. Esta opción desactiva la recogida de basura del almacenamiento asociado con las clases Java que ya no utiliza la JVM. Consulte también -Xclassgc. De forma predeterminada, se realiza una recogida de basura de clase.
-Xnocompactexplicitgc
Inhabilita la compactación en una llamada a System.gc(). Consulte también -Xcompactexplicitgc. De forma predeterminada, la compactación está habilitada en las llamadas a System.gc().
-Xnocompactgc
Inhabilita la compactación del recopilador de basura. Consulte también -Xcompactgc. De forma predeterminada, la compactación está habilitada.
-Xnojit
Inhabilita el compilador JIT. Consulte también -Xjit. De forma predeterminada, el compilador JIT está habilitado.
-Xnolinenumbers
Inhabilita los números de línea para la depuración. Consulte también -Xlinenumbers. De forma predeterminada, los números de línea están activados.
-Xnoloa
Impide la asignación de una LOA (Large Object Area). Los objetos se asignarán a la SOA. De forma predeterminada, la LOA se habilita para todas las políticas de GC, 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.
-Xnosigcatch
Inhabilita el código de manejo de señales de la JVM. Consulte también -Xsigcatch. De forma predeterminada, el manejo de señales está habilitado.
-Xnosigchain
Inhabilita el encadenamiento de manejadores de señales. Consulte también -Xsigchain. De forma predeterminada, el encadenamiento de manejadores de señales está habilitado.
-Xoptionsfile=<archivo>
Especifica un archivo que contiene opciones y definiciones de JVM. De forma predeterminada, no se utiliza ningún archivo de opciones.
-Xoss<tamaño>
Establece el tamaño de la pila Java y el tamaño de la pila C para cualquier hebra. Esta opción se proporciona para compatibilidad y es equivalente a establecer -Xss y-Xmso en el valor especificado.
-Xpartialcompactgc
Habilita la compactación parcial. De forma predeterminada, esta opción no está establecida, por lo que todas las compactaciones son completas. Consulte también -Xnopartialcompactgc.
-Xquickstart
Mejora el tiempo de arranque retardando las optimizaciones y la compilación de JIT. De forma predeterminada, 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. De forma predeterminada, el servidor de información de depuración remoto está inhabilitado.
-Xrs
Reduce el uso de señales del sistema operativo. De forma predeterminada, la VM realiza un uso completo de las señales del sistema operativo; consulte el apartado Señales utilizadas por la JVM.
-Xrun<nombre 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 de diagnósticos.
-Xrunjdwp[:help] | [:<opción>=< valor>, ...]
Carga bibliotecas de depuración que dan soporte a la depuración remota de aplicaciones. Consulte -Xdbg para obtener más información.
-Xrunjnichk[:help] | [:<opción>=<valor>, ...]
Se ha abandonado, utilice -Xcheck:jni.
-Xscmx<tamaño>
Para obtener más información sobre -Xscmx, consulte el apartado Habilitación y configuración de la función de compartir datos de clases.
-Xshareclasses:<opciones>
Para obtener información detallada de las opciones -Xshareclasses, consulte Habilitación y configuración de la función de compartir datos de clases.
-Xsigcatch
Habilita el código de manejo de señales de la VM. Consulte también -Xnosigcatch. De forma predeterminada, el manejo de señales está habilitado.
-Xsigchain
Habilita el encadenamiento de manejadores de señales. Consulte también -Xnosigchain. De forma predeterminada, el encadenamiento de manejadores de señales está habilitado.
-Xsoftrefthreshold<número>
Establece el número de recogida de basura (GC) después del cual se borrará una referencia intermedia (soft reference) si no se ha marcado su referente. El valor predeterminado es 3, lo que significa que a la tercera GC en la que no se marque el referente, se borrará la referencia intermedia.
-Xss<tamaño>
Establece el tamaño máximo de pila Java para cualquier hebra. De forma predeterminada, esta opción se establece en 256 KB. Utilice la opción -verbose:sizes para ver el valor que utiliza la VM.
-Xthr:<opciones>
Establece las opciones de hebra.
-Xverbosegclog:<vía de acceso a archivo>[X,Y]

Hace que la salida de la recogida de basura (GC) se grabe 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 GC en modalidad verbosa se redirige a un número X de archivos, cada uno de los cuales contiene un número Y de ciclos de gc de la salida de GC en modalidad verbosa. Estos archivos tienen el formato nombrearchivo1, nombrearchivo2, etc. De forma predeterminada, no se realiza ningún registro cronológico de la salida de GC en modalidad verbosa.

Consulte la Guía de diagnósticos para obtener más información.

-Xverify
Habilita la comprobación estricta de clases para todas las clases que se carguen. De forma predeterminada, la comprobación estricta de clases está inhabilitada.
-Xverify:none
Inhabilita la comprobación estricta de clases. De forma predeterminada, la comprobación estricta de clases está inhabilitada.

Apéndice B. Limitaciones conocidas

Limitaciones conocidas de SDK y Runtime Environment para Linux.

Puede encontrar más ayuda para el diagnóstico de problemas en la the Guía de diagnóstico en http://www.ibm.com/developerworks/java/jdk/diagnosis/60.html.

Valores de BIOS y 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.

Pestaña Local de la herramienta de supervisión JConsole

La pestaña Local de la herramienta JConsole de IBM, que permite la conexión a otras máquinas virtuales del mismo sistema, no está disponible. Asimismo, la opción de línea de mandatos pid correspondiente no está soportada. En su lugar, utilice la pestaña Remota de JConsole para conectarse con la máquina virtual que desee supervisar. Alternativamente, utilice la opción de línea de mandatos connection y especifique un host de tipo localhost y un número de puerto. Cuando inicie la aplicación que desea supervisar, establezca estas opciones de línea de mandatos:

-Dcom.sun.management.jmxremote.port=<valor>
Especifica el puerto en el que debe escuchar el agente de gestión.
-Dcom.sun.management.jmxremote.authenticate=false
Inhabilita la autenticación a menos que haya creado un archivo de nombre de usuario.
-Dcom.sun.management.jmxremote.ssl=false
Inhabilita el cifrado SSL.

El motor Rhino JavaScript no está disponible

El motor Mozilla Rhino Javascript no está incluido con el SDK de IBMpara Java debido a problemas de licencia. Para utilizar el motor Rhino Javascript con el SDK de IBMpara Java, descargue el motor de creación de scripts jsr223 en https://scripting.dev.java.net/, y el motor Rhino Javascript desde el sitio web de Mozilla: http://www.mozilla.org/rhino/.

Generación lenta de pares de claves DSA

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 un cuelgue porque el proceso se completará si se 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.

Creación de una JVM mediante JNI

Los programas nativos no pueden crear una JVM con las interfaces JNI_VERSION_1_1(0x00010001). No puede invocar JNI_CreateJavaVM() y pasarlo a una versión de JNI_VERSION_1_1(0x00010001). Las versiones que se pueden pasar son:

La JVM creada se determina mediante las bibliotecas Java presentes (esto es, 1.2.2, 1.3.x, 1.4.x, 5.x, 6.x) y no mediante la que queda implícita por la versión de la interfaz JNI que se ha pasado.

La versión de la interfaz no afecta a ninguna área del comportamiento que no sean las funciones disponibles para el código nativo.

Administradores de ventanas y accesos directos del teclado

El administrador de ventanas puede alterar temporalmente algunos de los acceso directos de teclado de Java. Si tiene que utilizar un acceso directo Java alterado temporalmente, consulte el manual del sistema operativo y cambie los accesos directos de teclado del administrador de ventanas.

Descriptores de archivos del sistema X Window

El sistema X Window no puede utilizar descriptores de archivos superiores a 255. Dado que la JVM contiene descriptores de archivos para abrir archivos jar, se pueden agotar los descriptores de archivo de X. Una solución alternativa puede ser establecer la variable de entorno JAVA_HIGH_ZIPFDS de modo que indique a la JVM que utilicen descriptores de archivo mayores para los archivos jar.

Para utilizar la variable de entorno JAVA_HIGH_ZIPFDS, establézcala en un valor entre 0 y 512. La JVM abrirá los primeros archivos jar utilizando los descriptores de archivo hasta 102. Por ejemplo, si es probable que el programa vaya a cargar 300 archivos jar:

export JAVA_HIGH_ZIPFDS=300

De este modo, los primeros 300 archivos jar se cargarán utilizando los descriptores de archivos 724 a 1023. Los archivos jar que se abran después de esto, lo harán dentro del rango normal.

DBCS y el portapapeles KDE

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

Límite del número de hebras cuando se utiliza la biblioteca LinuxThreads

En SLES9 y las distribuciones más recientes, la biblioteca de hebras predeterminada es NPTL, que implementa las hebras de Java como hebras nativas. En las distribuciones más recientes, la biblioteca de hebras es LinuxThreads, que implementa hebras como procesos nuevos. Si el número de hebras Java supera el número máximo de procesos permitidos, es posible que se cuelgue su programa.

El número máximo de hebras disponible se determina mediante el número más bajo de:

No obstante, es posible que se agote el almacenamiento virtual antes de que alcance este número máximo de hebras.

Límite de horas de CPU de usuario de la hebra ThreadMXBean

No existe ningún modo de distinguir entre el tiempo de CPU de modalidad de usuario y el tiempo de CPU de modalidad del sistema en esta plataforma. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() y ThreadMXBean.getCurrentThreadCpuTime() devuelven todos el tiempo de CPU total para la hebra necesaria.

KeyEvents y administradores de ventanas

Los resultados de KeyEvent que incluyen la tecla Alt pueden ser diferentes en los administradores de ventanas de Linux. También pueden ser diferentes de los resultados de otros sistemas operativos. Cuando se utilizan los valores predeterminados Ctrl+Alt+A en el administrador de ventanas KWin se genera un KeyEvent, mientras que cuando se utiliza Ctrl+Alt+A en el gestor de ventanas de Metacity, no se genera un KeyEvent.

El sistema X Window y la tecla Meta

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

xmodmap -pk  

Esto es debido a que SDK considera que Meta y Alt se pulsan al mismo tiempo. Como solución alternativa, puede suprimir la correlación Meta_x escribiendo lo siguiente en un indicador del shell:

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

Esta solución alternativa puede afectar a otras aplicaciones X-Window que se ejecutan en la misma visualización y que utilizan el valor Meta que se ha suprimido.

SIGSEGV cuando se crea una JVM mediante JNI

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.

Falta de recursos con aplicaciones de muchas hebras

Si está ejecutando muchas hebras simultáneas, es posible que reciba este mensaje de aviso:

java.lang.OutOfMemoryError

Esta es una indicación de que se están agotando los recursos del sistema en la máquina y que los mensajes pueden ser debido a los motivos siguientes:

Intente ajustar el sistema para aumentar los recursos del sistema correspondientes.

X Server y problemas de font del cliente

Cuando se ejecuta una aplicación Java AWT o Swing en una máquina Linux y se exporta la visualización a una segunda máquina, es posible que tenga problemas con la visualización de algunos diálogos si el conjunto de fonts cargado en la máquina del cliente X es diferente del conjunto cargado en la máquina del servidor X. Para evitar este problema, instale los mismos fonts en las dos máquinas.

Codificación UTF-8 y MalformedInputExceptions

Si el entorno local del sistema utiliza una codificación UTF-8, es posible que algunas herramientas del SDK generen una excepción sun.io.MalformedInputException. Para saber si el sistema utiliza una codificación UTF-8, examine las variables de entorno específicas del entorno local como, por ejemplo, LANG o LC_ALL para ver si terminan por el sufijo. ".UTF-8". Si recibe la excepción sun.io.MalformedInputException, cambie los caracteres que no están en el rango ASCII de 7 bits (0x00 - 0x7f) y que no se representan como literales de caracteres Unicode Java por literales de caracteres Unicode Java (por ejemplo, '\u0080'). Otra solución alternativa a este problema es suprimir el sufijo ".UTF-8" de las variables de entorno específicas del entorno local, por ejemplo, si la máquina tiene el entorno local "en_US.UTF-8", establezca LANG en "en_US".

Problemas de AMI y xcin cuando se exportan las visualizaciones

Si está utilizando AMI y xcin en un entorno de diferentes plataformas, por ejemplo, si intenta exportar la visualización entre un sistema de 32 bits y un sistema de 64 bits o entre un sistema big-endian y un sistema little-endian, es posible que se produzcan algunos problemas. Si tiene este tipo de problema, realice la actualización a la última versión de AMI y xcin.

RHEL4 y XIM

Sólo para los usuarios del idioma chino, coreano y japonés de RHEL4.

De forma predeterminada, no se instala ningún servidor de XIM. Para la entrada de caracteres DBCS en una aplicación Java, instale un paquete de servidor XIM como, por ejemplo, iiimf-x o kinput2.

RHEL4 e IIIMF

Sólo para los usuarios del idioma chino, coreano y japonés de RHEL4.

Si va a utilizar Internet/IntranetSinput Method Framework (IIIMF), utilice paquetes IIIMF que se incluyen en Red Hat Enterprise Linux 4 Update 2 o posterior. Para obtener información, póngase en contacto con Red Hat en http://www.redhat.com.

(Sólo zSeries de 64 bits) es posible que observe errores de IIIMF o una anomalía de inicio. Para resolver el problema, realice la actualización a los últimos paquetes IIIMF.

(Sólo chino tradicional en PPC, s390 o s390x) es posible que IIIMF no funcione. Pata resolver el problema, utilice iiimf-le-xcin-0.1.7-13.EL4 o posterior.

(Sólo chino simplificado en PPC, s390 o s390x) es posible que IIIMF no funcione correctamente. Para resolver el problema, utilice paquetes IIMF incluidos en RHEL4 Update 5 o posterior.

RHEL4 y el entorno local zh_CN.GB18030

Sólo para los usuarios del idioma chino simplificadode RHEL4.

El entorno local zh_CN.GB18030 no está soportado por xlib en RHEL4. xterm no puede activar el servidor de método de entrada para la entrada de caracteres GB18030. En su lugar, utilice el entorno local zh_CN.UTF8. Si tiene programas de herencia 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 se puedan ejecutar y los datos se puedan visualizar correctamente en RHEL4 con el entorno local zh_CN.UTF8.

Esta limitación se ha resuelto en RHEL4 U3.

RHEL4 y xcin

Es posible que se cuelgue con xcin en RHEL4. Para resolver el problema, establezca ICCHECK_DISABLE en YES en el archivo /etc/chinese/xcin/xcinrc.

Sólo entornos de 64 bits

En RHEL4 con xcin (servidor XIM de chino tradicional), es posible que observe 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). Para resolver el problema, realice la actualización al último paquete xcin.

Problemas de cambio de focalización en RHEL4 e IIIMF

Sólo para RHEL4.

Cuando se utiliza IIIMF (Internet Intranet Input Method Framework) para la entrada de caracteres DBCS, es posible que tenga problemas de cambio de focalización. El problema se produce cuando se minimizan los componentes de entrada activos. Después de restaurar el componente, el método de entrada vuelve a SBCS. De este modo, DBCS se debe volver a activar manualmente.

Los siguientes componentes tienen este problema de cambio de foco:

XIM y el plug-in Java

RHEL4 y SLES9 únicamente

Para los usuarios de los idiomas japonés, chino y coreano, no se puede utilizar XIM para la entrada de los caracteres propios en componentes de texto en un applet Java con un navegador web. Esta limitación se produce porque XEmbed requiere un arreglo para el archivo de biblioteca X11. Como solución alternativa para esta situación, especifique el parámetro del sistema -Dsun.awt.noxembed=true para inhabilitar XEmbed. Puede establecer esta opción utilizando el panel de control:

  1. Abra el panel de control del plug-in Java y vaya a la pestaña Java.
  2. Pulse el botón Ver de los valores de tiempo de ejecución del applet Java.
  3. Escriba -Dsun.awt.noxembed=true en los parámetros de tiempo de ejecución Java y pulse Aceptar.
  4. Pulse Aplicar.
  5. Inicie un navegador.

Esta limitación se ha resuelto enRHEL4 U3 y SLES9 SP3.

Caracteres árabes y tarjetas de vídeo Matrox

Sólo plataformas Intel de 32 bits

Para los usuarios de textos árabes, al utilizar Linux con una tarjeta de vídeo Matrox con la aceleración habilitada, se puede observar caracteres distorsionados cuando se utiliza drawString para mostrar fonts de gran tamaño. Este problema es debido al controlador de dichas tarjetas. La solución alternativa recomendada es inhabilitar la aceleración para el dispositivo.

SLES9 NPTL y el controlador del puerto paralelo

Sólo plataformas Intel de 32 bits

En SLES 9 NPTL, el controlador del puerto paralelo hace que el kernel colisione e inhabilite una hebra Java. La JVM detecta esta colisión cuando intenta suspender la hebra para la recogida de basura y luego colisiona generando un archivo de núcleo y el mensaje "JVMLH030: las hebras desaparecen cuando se intenta suspender todas las hebras".

Se genera el informe SUSE Bugzilla 47947 acerca de este problema. Este problema se ha solucionado en SLES 9 Service Pack 1.

Las llamadas JNI con más de ocho parámetros en plataformas PPC

Sólo plataformas PPC

Si el código Java utiliza llamadas JNI, y cualquier llamada específica tiene más de ocho parámetros flotantes o dobles, el código C se debe compilar con gcc-2.95.3 El nivel FSF (Free Software Foundation) de GGC (GNU C Compiler).

Operaciones de puerto paralelo en SLES9 antes de SP2

Sólo plataformas PPC

El paquete JavaComm no da soporte a las operaciones de puertos paralelos en los kernel SLES 9 GA y SP1. Esta limitación se ha resuelto en el kernel SP2. El número de SUSE Bugzilla es 50028.

Compilación de libFileStat.so en plataformas PPC de 64 bits

Sólo plataformas PPC de 64 bits

El compilador GCC predeterminado entre plataformas (versión 3.2-49) genera varios errores. Para generar la biblioteca compartida libFileStat.so, ejecute:

/opt/cross/bin/powerpc64-linux-gcc -shared -o libFileStat.so    -I<SDK_PATH>/include FileStat.c

donde <SDK_PATH> es la vía de acceso al directorio de instalación del SDK.

IPv6 en plataformas zSeries

Sólo plataformas zSeries

Aunque el kernel Linux en las distribuciones actuales proporciona soporte para IPv6 (Internet Protocol version 6), es posible que tenga problemas al utilizarlo. En este release se incluye soporte para IPv6 desde Java, pero se le recomienda que desactive el soporte con la opción -Djava.net.preferIPv4Stack=true del mandato java. Si instala un kernel que soporta por completo IPv6, no necesita esta opción.

xcin en plataformas zSeries de 64 bits

Sólo para plataformas zSeries de 64 bits

El servidor del método de entrada para China y Taiwán no se ha probado.

API Java Desktop

Es posible que las bibliotecas de la API Java Desktop no funcionen porque una o más bibliotecas GNOME no están disponibles.

NullPointerException con la apariencia de GTK

Sólo entornos DBCS

Si la aplicación falla con una NullPointerException utilizando la apariencia de GTK, desestablezca la variable de entorno GNOME_DESKTOP_SESSION_ID.

Alias de página de código Unicode Shift_JIS

Sólo para usuarios de japonés

El alias de página de código Unicode "\u30b7\u30d5\u30c8\u7b26\u53f7\u5316\u8868\u73fe" para Shift_JIS se ha suprimido. Si utiliza esta página de códigos en sus aplicaciones, sustitúyala por Shift_JIS.

Avisos

Esta información se ha desarrollado para productos y servicios que se ofrecen en los EE.UU. Es posible que IBM no ofrezca en otros países los productos, servicios o características que se tratan en este documento. 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 dar a entender 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 son responsabilidad del usuario.

IBM puede tener aplicaciones bajo patente 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:

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:

El párrafo siguiente no se aplica al Reino Unido ni a ningún otro país en el que tales disposiciones entren en contradicción 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 se le facilite de la manera que considere apropiada sin incurrir en obligaciones con el remitente.

Los poseedores de licencias 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:

Esta información estará disponible, sujeta a los términos que correspondan, lo que en algunos casos supondrá 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 vayan a ser iguales en los sistemas habitualmente disponibles. Asimismo, algunas mediciones pueden haber sido estimadas mediante 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 registradas y logotipos basados en Java son marcas registradas o marcas comerciales 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.