Antes de utilizar esta información y el producto al que da soporte, lea la información del apartado Avisos.
Esta edición de la guía del usuario corresponde a IBM SDK de 32 bits y Runtime Environment para Windows, Java Technology Edition, Versión 6, y a todos los releases, modificaciones y renovaciones de servicio siguientes, hasta que se indique lo contrario en nuevas ediciones.
(C) Copyright Sun Microsystems, Inc. 1997, 2007, 901 San Antonio Rd., Palo Alto, CA 94303 EE.UU. Reservados todos los derechos.
Esta guía del usuario proporciona información general sobre IBM SDK de 32 bits y Runtime Environment para Windows, 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.
SDK y Runtime Environment reciben soporte en los siguientes productos:
Se da soporte a estos entornos virtuales:
Tenga en cuenta que IPv6 sólo recibe soporte en Windows XP y Windows Server 2003.
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.
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 Windows, 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 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 Windows no incluye ninguna de las herramientas de desarrollo como, por ejemplo, appletviewer.exe o el compilador Java (javac.exe), o clases que únicamente sean para sistemas de desarrollo.
Asimismo, se proporciona el paquete de la interfaz de programación de aplicaciones (API) Java Communications para utilizarlo junto con Runtime Environment para Windows. Puede encontrar información acerca del mismo en el Utilización de la API Java Communications (JavaComm).
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 de 32 bits para Windows, v6. No se garantiza que las clases compiladas con este release funcionen en releases anteriores.
IBM SDK de 32 bits para Windows, v6, está incorporado en Microsoft Visual Studio .NET 2003.
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.
A partir de la versión 5.0, the IBM Runtime Environment paraWindows 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:
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 (Java Native Interface) tendrán algunas dependencias menores.
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 Windows. 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.
Una lista de las clases y herramientas que puede utilizar con Runtime Environment estándar.
Con el SDK estándar se incluye una lista de herramientas e información de referencia.
El archivo License, C:\Archivos de programa\IBM\Java60\docs\content\<entorno_local>\LA_<entorno_local>, contiene el acuerdo de licencia para el software SDK para Windows (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.
Utilice el asistente de instalación o el archivo comprimido para instalar el SDK. Configure el SDK utilizando las variables de entorno, opciones de línea de mandatos y archivos de propiedad.
Para instalare el paquete SDK o Runtime Environment, descargue el paquete de instalación adecuado. Asegúrese de que descarga todos los paquetes en el mismo directorio y de que dispone de suficiente espacio en el directorio temporal.
Los paquetes y los nombres de archivo están listados en Instalación de paquetes; no cambie los nombres de archivo de los paquetes.
Antes de empezar la instalación, asegúrese de que dispone de suficiente espacio en el directorio C:\WINDOWS\TEMP para utilizar durante la instalación. La cantidad de espacio temporal necesario en el directorio TEMP durante la instalación es:
Si no dispone de suficiente espacio temporal, el programa de instalación genera un error y la instalación finaliza. Si dispone de espacio temporal suficiente pero todavía ve este mensaje, verifique si los paquetes que está intentando instalar se han descargado completamente. Para ello, compare los tamaños de archivo de los paquetes con los tamaños de archivo que aparecen en las páginas web de las que ha descargado los paquetes.
Hay muchos paquetes que puede instalar de forma independiente, incluido el SDK, Runtime Environment, Javacomm, documentación y demos.
Los paquetes que puede instalar son:
Otros paquetes se suministran en archivos comprimidos:
Si instala el SDK o Runtime Environment desde el paquete comprimido, no podrá utilizar Web Start o el plug-in de Java y el panel de control contendrá la pestaña Actualizar que no funciona.
Utilice la información atendida para instalar el SDK o JRE en un solo cliente.
Runtime Environment está instalado de forma predeterminada en el directorio C:\Archivos de programa\IBM\Java60\jre.
Si ha descargado el paquete instalable SDK, puede elegir qué componentes desea instalar:
En el asistente de instalación, aparecen las siguientes opciones:
En Windows Vista, es posible que haya un retardo después de seleccionar el idioma de instalación.
Si la instalación falla con el mensaje de error "Error applying transform", la información de configuración de Windows Installer se ha dañado. Para solucionar el error, utilice la herramienta de limpieza de Windows Installer http://support.microsoft.com/kb/290301 para eliminar la información de configuración de Windows Installer dañada.
Cuando instala Runtime Environment (ya sea como parte del paquete instalable SDK o del paquete instalable Runtime Environment), se le solicita si desea instalar Runtime Environment como Java Virtual Machine (JVM) del sistema. Si lo instala como JVM del sistema, el programa de instalación copia los iniciadores java.exe, javacpl.cpl, javaws.exe y javaw.exe en el directorio del sistema de Windows.
Si ya existe actualmente una versión de java.exe or javaw.exe en el directorio del sistema Windows, se le solicita sobrescribir la versión existente con la versión actual. Al instalar estos archivos en el directorio del sistema de Windows hace que este Runtime Environment sea la JVM del valor predeterminado del sistema. Además, la clave de registro "Current Version" se establece para coincidir con esta instalación.
Utilice la instalación desatendida para instalar el SDK o JRE en varios clientes.
Para crear una instalación desatendida, complete primero una instalación atendida y cree un archivo de respuestas (setup.iss) que registre las opciones realizadas durante la instalación. El archivo de respuestas que cree debe ser correcto para los sistemas en los que piensa utilizarlo. Si es necesario, cree varios archivos de respuestas que va a utilizar para instalar los paquetes en los sistemas que tienen diferentes configuraciones.
Para crear un archivo de respuestas mientras ejecuta la instalación, escriba lo siguiente en el indicador de mandatos:
ibm-java-sdk-60-win-i386 /r
o bien
ibm-java-jre-60-win-i386 /r
En función del producto de Windows de que se trate, se crea un archivo de respuestas (setup.iss) en el directorio C:\Windows o C:\Winnt.
Es posible que se produzca el siguiente mensaje durante una instalación interactiva:
Actualmente está instalado en la JVM del sistema otro Java Runtime Environment. Seleccione Sí para para sobrescribir esta versión o No para salir de esta instalación.
Si se visualiza este mensaje, pulse No y salga de la instalación. Vaya al directorio del sistema de Windows y suprima los dos archivos siguientes:
Una vez que haya suprimido los archivos, reinicie la instalación interactiva utilizando el mandato que aparece al principio de esta sección.
En el sistema en el que se ejecutará la instalación desatendida, copie el archivo de respuestas setup.iss en el directorio C:\Windows. Una vez que haya copia el archivo, en un indicador de mandatos escriba lo siguiente:
ibm-java-sdk-60-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java-jre-60-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Si la instalación se ha realizado correctamente, el archivo de registro contiene la serie ResultCode=0. Si la instalación no se ha realizado correctamente, el archivo de registro contendrá un código de resultado diferente.
IBM Accessibility Bridge está instalado pero inhabilitado de forma predeterminada. Para habilitar IBM Accessibility Bridge, quite la marca de comentario de la entrada assistive_technologies del archivo Accessibility.properties.
El archivo Accessibility.properties se encuentra en el directorio jre/lib. Suprima el # del principio de la siguiente línea:
#assistive_technologies=JawBridge
Este sitio web le da más información sobre Accessibility Utilities:
http://java.sun.com/products/jfc/accessibility.html
Puede inhabilitar el soporte de accesibilidad Java para mejorar el rendimiento de la carga JVM de las aplicaciones Java que no proporcionan soporte de tecnología asistida Java, en particular a través de enlaces. Para inhabilitar el soporte de accesibilidadJava, establezca la variable de entorno JAVA_ASSISTIVE en OFF.
Una tecnología asistida como, por ejemplo, JawBridge, no está disponible si la variable de entorno se establece en OFF, aunque la tecnología esté habilitada en el archivo Accessibility.properties.
En Windows, un proceso tiene dos páginas de códigos: la página de códigos ANSI (o Windows) y la página de códigos OEM (o DOS).El mandato javaw utiliza siempre la página de códigos ANSI a menos que la propiedad del sistema console.encoding está establecida.
La ventana de mandatos utiliza manualmente la página de códigos OEM. La salida de la consola Java utiliza la página de códigos de la ventana de mandatos desde la que se inicióJava. No obstante, el mandato javaw utiliza siempre la página de códigos ANSI. Especifique la página de códigos que va a utilizar para la salida de la consola con la opción -Dconsole.encoding en el iniciador java o javaw. Por ejemplo, -Dconsole.encoding=Cp1252 hace que toda la salida de la consola esté en la página de códigos Latin1 (1252) de Windows ANSI.
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 Windows 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 los iniciadores Java a la vía de acceso:
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
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 de mandatos:
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 de mandatos.
Utilice el programa de utilidad de Windows Agregar o quitar programas para desinstalar el SDK o Runtime Environment.
Para desinstalar el SDK, independientemente de si ha instalado el producto mediante una instalación atendida o desatendida:
Este procedimiento elimina todos los paquetes que están instalados con el Instalador. No elimina el paquete de la API Java Communications API (consulte el apartado Desinstalación de la API Java Communications) o cualquier archivo adicional que se haya extraído de los paquetes comprimidos.
Si no dispone de los permisos necesarios para desinstalar el SDK o Runtime Environment, "Error1325.launchpad no es un nombre corto de archivo válido". Para desinstalar el SDK o Runtime Environment, restaure los permisos correctos.
Si mantiene varias instalaciones entre IBM SDK de 32 bits para Windows, v6 y versiones en V1.3.1 o posteriores, si desinstala la versión anterior mientras sigue instalada una versión de v6 en el sistema, el desinstalador de V1.3.1 elimina las claves de registro siguientes y todas las subclaves que la versión v6 necesita, dañando así la instalación de v6:
Por consiguiente, vuelva a efectuar la instalación dev6 después de desinstalar la versión V1.3.1. Este límite del desinstalador se ha fijado para V1.4.0 y los releases posteriores.
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.
Una breve descripción de los mandatos java y javaw.
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.
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 ... ]
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.
java -versionVerá información similar a la siguiente:
java version "1.6.0-internal" Java(TM) SE Runtime Environment (build 20070227_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20070226_11758 (JIT enabled) J9VM - 20070226_11758_lHdSMR JIT - dev_20070215_1800 GC - 20070208_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:
|... |C:\Archivos de programa\IBM\Java60\jre\lib\ext\ibmpkcs11impl.jar VERSION: 1.0 build_20070125 |C:\Archivos de programa\IBM\Java60\jre\lib\ext\dtfjview.jar |C:\Archivos de programa\IBM\Java60\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.
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:
java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass
set 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.
Las definiciones de las opciones estándar.
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.
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.
Para establecer una clase Java o un archivo jar de modo que se ejecute automáticamente desde el explorador de Windows, utilice la opción Herramientas -> Opciones de carpeta -> Tipo de archivo del Explorador de Windows.
De forma alternativa, escriba en el indicador de mandatos:
assoc .class=javaclass ftype javaclass=C:\Archivos de programa\IBM\Java60\jre\bin\java.exe''%l''%*'
Sun proporciona el Java Access Bridge para permitir que las tecnologías de asistencia nativas de Windows, como los lectores de pantalla, puedan acceder al soporte Java Accessibility en una aplicación Java. Estas tecnologías de asistencia nativas de Windows deben admitir llamadas al Java Access Bridge.
El paquete Java Access Bridge que facilita Sun incluye un programa de instalación que coloca cinco archivos en los directorios correctos: access-bridge.jar, jaccess.jar, accessibility.properties, JavaAccessBridge.dll y WindowsAccessBridge.dll. IBM proporciona una copia de jaccess.jar en el directorio adecuado para utilizarlo con JawBridge.
Si ya ha habilitado IBM Accessibility Bridge (JawBridge), que permite que Windows 2000 Magnifier funcione con aplicaciones Swing, y desea habilitar JawBridge al mismo tiempo que Java Access Bridge, edite la línea del archivo accessibility.properties para que indique:
assistive_technologies=com.sun.java.accessibility.AccessBridge,JawBridge
Comente la línea insertando # delante para desactivar ambos puentes. El siguiente sitio web le indica cómo bajar Java Access Bridge:
http://java.sun.com/products/jfc/accessibility.html.
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.
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.
set JAVA_COMPILER=NONETambién puede establecer de forma permanente JAVA_COMPILER utilizando la interfaz gráfica de usuario. Abra el Panel de control, seleccione Sistema, y en la pestaña Opciones avanzadas, seleccione Variables de entorno.
java -Djava.compiler=NONE <clase>
java -Xint <clase>
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.
set JAVA_COMPILER=jitcTambién puede establecer de forma permanente JAVA_COMPILER utilizando la interfaz gráfica de usuario. Abra el Panel de control, seleccione Sistema, y en la pestaña Opciones avanzadas, seleccione Variables de entorno. Si la variable de entorno JAVA_COMPILER es una serie vacía, el JIT continúa inhabilitado. Para inhabilitar la variable de entorno, en el indicador de mandatos, escriba:
set JAVA_COMPILER=
java -Djava.compiler=jitc <clase>
java -Xjit <clase>
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 de mandatos:
java -version
Si el JIT no se está utilizando, aparece un mensaje que incluye lo siguiente:
(JIT disabled)
Si el JIT se está utilizando, aparece un mensaje que incluye lo siguiente:
(JIT enabled)
Para obtener más información sobre el JIT, consulte la Guía de diagnósticos.
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.
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:
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.
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.
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.
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.
| | |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:
|java -Djava.ext.dirs=C:\Archivos de programa\IBM\Java60\jre\lib\ext;C:\Archivos de programa\IBM\Java60\jre\lib\im <clase>
|
Si ha instalado SDK o Runtime Environment en un directorio diferente, sustituya C:\Archivos de programa\IBM\Java60\ por el directorio en el que ha instalado SDK o Runtime Environment.
SDK para Windows 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.
| | |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.
|IBM SDK para Java contiene las bibliotecas XML siguientes.
|XML4J es un analizador con validación que proporciona soporte para los siguientes estándares: |
|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 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.
|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: |
|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: |
|Los siguientes proveedores de servicio controlan las bibliotecas de proceso XML que utiliza Java: |
|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:
|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 | |
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.
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.
Las siguientes características opcionales StAX |no están soportadas en XL XP-J: |
|Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLInputFactory, tal como se ha descrito enXMLInputFactory Javadoc.
| |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 | |Sí | |
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 | |Sí | |
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 | |Sí | |
javax.xml.stream.resolver | |Sí | |
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.
|Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLStreamReader, |tal como se ha descrito en XMLStreamReader Javadoc.
| |Nombre de la propiedad | |Soportada | |
---|---|
javax.xml.stream.entities | |Sí | |
javax.xml.stream.notations | |Sí | |
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.
|Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLOutputFactory, tal como se ha descrito en XMLOutputFactory Javadoc.
| |Nombre de la propiedad | |Soportada | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sí | |
Se admiten las siguientes propiedades en |la implementación javax.xml.stream.XMLStreamWriter, tal como se ha descrito en XMLStreamWriter Javadoc.
| |Nombre de la propiedad | |Soportada | |
---|---|
javax.xml.stream.isRepairingNamespaces | |Sí | |
Las propiedades sobre objetos XMLStreamWriter son de sólo lectura.
| | |XL TXE-J es una biblioteca XSLT que contiene el intérprete XSLT4J 2.7.8 y un compilador |XSLT.
Característica | |Intérprete XSLT4J (incluido) | |Compilador XSLT4J (no incluido) | |Compilador XL TXE-J (incluido) | |
---|---|---|---|
Característica http:// |javax.xml.transform.stream.StreamSource |/feature | |Sí | |Sí | |Sí | |
Característica http:// |javax.xml.transform.stream.StreamResult |/feature | |Sí | |Sí | |Sí | |
Característica http://javax.xml.transform.dom.DOMSource/feature | |Sí | |Sí | |Sí | |
Característica http://javax.xml.transform.dom.DOMResult/feature | |Sí | |Sí | |Sí | |
Característica http://javax.xml.transform.sax.SAXSource/feature | |Sí | |Sí | |Sí | |
Característica http://javax.xml.transform.sax.SAXResult/feature | |Sí | |Sí | |Sí | |
Característica http://javax.xml.transform.stax.StAXSource/feature | |Sí | |No | |Sí | |
Característica http://javax.xml.transform.stax.StAXResult/feature | |Sí | |No | |Sí | |
Característica http:// |javax.xml.transform.sax. |SAXTransformerFactory/feature | |Sí | |Sí | |Sí | |
Característica http:// |javax.xml.transform.sax. |SAXTransformerFactory/feature/ |xmlfilter | |Sí | |Sí | |Sí | |
Característica http://javax.xml.XMLConstants/feature/secure-processing | |Sí | |Sí | |Sí | |
Atributo http://xml.apache.org/xalan/features/incremental | |Sí | |No | |No | |
Atributo http://xml.apache.org/xalan/features/optimize | |Sí | |No | |No | |
Atributo http://xml.apache.org/xalan/properties/source-location | |Sí | |No | |No | |
Atributo translet-name | |N/D | |Sí | |Sí (con el nombre nuevo) | |
Atributo destination-directory | |N/D | |Sí | |Sí (con el nombre nuevo) | |
Atributo package-name | |N/D | |Sí | |Sí (con el nombre nuevo) | |
Atributo jar-name | |N/D | |Sí | |Sí (con el nombre nuevo) | |
Atributo generate-translet | |N/D | |Sí | |Sí (con el nombre nuevo) | |
Atributo auto-translet | |N/D | |Sí | |Sí (con el nombre nuevo) | |
Atributo use-classpath | |N/D | |Sí | |Sí (con el nombre nuevo) | |
Atributo enable-inlining | |No | |Sí | |No (obsoleto en TL TXE-J) | |
Atributo indent-number | |No | |Sí | |Sí (con el nombre nuevo) | |
Atributo debug | |No | |Sí | |Sí (con el nombre nuevo) | |
Extensiones Java | |Sí | |Sí (sólo sintaxis abreviada, las construcciones xalan:component/xalan:script no están soportadas) | ||
Extensiones JavaScript | |Sí | |No | |No | |
Elementos de extensión | |Sí | |No | |No | |
Funciones de extensión EXSLT | |Sí | |Sí (excepto dynamic) | |Sí (excepto dynamic) | |
Extensión redirect | |Sí | |Sí (excepto redirect:open y redirect:close) | |Sí | |
Extensión output | |No | |Sí | |Sí | |
Extensión nodeset | |Sí | |Sí | |Sí | |
Funciones de extensión NodeInfo | |Sí | |No | |No | |
Extensión de biblioteca SQL | |Sí | |No | |No | |
Extensión pipeDocument | |Sí | |No | |No | |
Extensión evaluate | |Sí | |No | |No | |
Extensión tokenize | |Sí | |No | |No | |
XML 1.1 | |Sí | |Sí | |Sí | |
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.
| |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: |
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory=
| org.apache.xerces.jaxp.SAXParserFactoryImpl
o bien
|set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory=
| org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
o bien
|set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory=
| org.apache.xalan.processor.TransformerFactoryImpl
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 paraWindows.
Para obtener más información acerca del diagnóstico de problemas mediante Java consulte la Guía de diagnósticos.
JDB (Java Debugger) se incluye en SDK para Windows. El depurador se invoca utilizando el mandato jdb; se conecta a la JVM mediante JPDA.
Para depurar una aplicación Java:
java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<puerto> <clase>La JVM se inicia, pero suspende la ejecución antes de iniciar la aplicación Java.
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:
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.
java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=<puerto> <clase>La JVM se inicia, pero suspende la ejecución antes de iniciar la aplicación Java.
jdb -connect com.sun.jdi.SocketAttach:hostname=<sistema principal>,port=<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:
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");
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.
Cuando se genera una señal de forma externa, por ejemplo, cuando se pulsa Ctrl-Inter), se crea una hebra nueva para el manejador de señales. En este caso, el manejador de señales de la JVM realiza su proceso y, 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, se llamará al manejador de aplicaciones de esta señal.
Para señales de excepción y de error, la JVM:
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:
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 SIGBREAK, que hace que se genere un Javadump.
Los tipos de señales son 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:
Nombre de señal | Tipo de señal | Descripción | Inhabilitada por -Xrs |
---|---|---|---|
SIGINT (2) | Interrupción | Atención interactiva (Control-C). La JVM sale normalmente. | Sí |
SIGTERM (15) | Interrupción | Petición de terminación. La JVM saldrá normalmente. | Sí |
SIGBREAK | Control | Señal de interrupción procedente de un terminal. De forma predeterminada, esto activa un Javadump. | Sí |
IBM JVM utiliza el manejo de excepciones estructurado y la API SetConsoleCtrlHandler(). Se inhabilitan con -Xrs. -Xnosigchain no se tiene en cuenta en Windows.
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 2 (SIGINT) y 15 (SIGTERM) de las hebras de la JVM hacen que concluya la JVM; por lo tanto, un manejador de señales de la aplicación no debe intentar recuperarse de esta señal a menos que ya no requiera la JVM.
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 jsig.dll antes de msvcrt.dll. La biblioteca jsig.dll garantiza que las llamadas a signal() 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.
La biblioteca libjsig.dll 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.
La variable de entorno JAVA_HOME debe establecerse en la ubicación del SDK, por ejemplo, C:\Archivos de programa\IBM\Java60\.
Para utilizar jsig.dll, enlácela con la aplicación que crea o incorpora la JVM.
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).
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.
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.
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.
Las asignaciones de páginas grandes sólo se realizarán satisfactoriamente si la política administrativa para el usuario JVM se ha configurado de modo que permite "Bloquear páginas en la memoria".
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.
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.
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.
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.
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.
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>
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.
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.
Para inhabilitar la fragmentación, establezca el tamaño del fragmento en 0 bytes:
java -Dcom.ibm.CORBA.FragmentSize=0 <miapli>
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.
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 |
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.
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:
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.
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.*;.
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.
El plug-in de Java es un plug-in de navegador web. Utilice el plug-in de Java para ejecutar applets en el navegador.
Debe dejar que los applets terminen de cargarse para que el navegador no se cuelgue. Por ejemplo, si utiliza el botón Atrás y, a continuación, el botón Adelante mientras se está cargando un applet, puede que no se puedan cargar las páginas HTML.
El plug-in de Java se describe en la dirección de Sun: http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/.
El plug-in de Java está preparado para Internet Explorer, Netscape, Mozilla, y Mozilla Firefox.
Navegador | Versiones soportadas |
---|---|
Internet Explorer | 6.0 SP1, 7.0 |
Netscape (No está soportado en Windows Vista) | 7.2 |
Mozilla (No está soportado en Windows Vista) | 1.7, 1.8 |
Firefox | 2.0 |
Los releases secundarios inferiores de los navegadores también están soportados.
Internet Explorer 5.01, el navegador predeterminado en Windows 2000, no está soportado.
La creación de versiones estáticas permite que los applets soliciten su ejecución en una versión específica de la JVM. Dado que esta posibilidad permite que los applets se aprovechen de las antiguas vulnerabilidades de seguridad de los sistemas que se han actualizado a una nueva JVM, ahora se utiliza Secure Static Versioning en Internet Explorer.
De forma predeterminada, todos los applets se ejecutan bajo la JVM instalada más recientemente. Para inhabilitar SSV, establezca la clave de registro siguiente en 0:
HKEY_LOCAL_MACHINE\Software\IBM\Java Deployment\Policy\EnableSecureStaticVersioning
Si la clave de registro no existe, SSV está habilitado.
SSV no funciona en Internet Explorer si se inhabilitan las extensiones de terceros. Para habilitar las extensiones de navegador de terceros:
SSV continuará funcionando si, después de utilizarlo, se inhabilitan las extensiones de navegador de terceros.
Para proporcionar protección a los navegadores Mozilla y Firefox, el plug-in para Internet Explorer eliminará automáticamente todos los plug-in Java de los directorios de plug-in de Mozilla y Firefox. Esto sucede cada vez que se ejecuta un applet en Internet Explorer.
Para volver a instalar un plug-in de Java para Mozilla o Firefox, utilice el panel de control de Java.
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:
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 de 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 BIG-5 para analizar el archivo HTML.
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.
Utilice el mandato siguiente para ejecutar un applet con el visor de applets.
En un indicador de mandatos, 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 de mandatos:
appletviewer <demo>\GraphLayout\example1.html
Donde <demo> se sustituye por la vía de acceso completa en la que ha descomprimido el paquete de demostración.
Para invocar el Visor de applets en una página web, escriba en un indicador de mandatos:
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
Se ha añadido un conjunto CLSID exclusivos a IBM JVM a partir de la Versión 6.
Los siguientes son los CLSID nuevos:
1ACECAFE-0016-0000-0000-ABCDEFFEDCBA 1ACECAFE-0016-0000-0000-ABCDEFFEDCBB 1ACECAFE-0016-0000-0000-ABCDEFFEDCBC
Puede hacer referencia a los CLSID anteriores en el indicador OBJECT para los applets.
Asimismo, también se da soporte a los siguientes CLSID existentes con fines de compatibilidad:
CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA CAFEEFAC-0016-0000-0000-ABCDEFFEDCBB CAFEEFAC-0016-0000-0000-ABCDEFFEDCBC
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.
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:
Web Start puede ejecutarse desde una página web o la línea de mandatos. Las aplicaciones de Web Start se almacenan en la memoria caché de aplicaciones Java.
Puede invocar Web Start de varias formas diferentes.
javaws <URL>Donde <URL> es la ubicación de un archivo .jnlp.
C:\Archivos de programa\IBM\Java60\jre\bin\javaws| -viewer
Todas las aplicaciones Java Web Start se almacenan en la memoria caché de aplicaciones Java. Una aplicación sólo se descarga si la versión más reciente no está en la memoria caché.
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.
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 Windows. El software de SDK para Windows contiene un Runtime Environment. Sin embargo, no puede suponer que los usuarios tienen instalado el software de SDK para Windows.
La licencia de software de SDK para Windows 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 Windows.
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:
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é.
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.
|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.
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.
El acceso a la memoria caché de las clases compartidas se limita mediante permisos del sistema operativo y permisos de seguridad Java. 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é.
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.
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.
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.
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:
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 laGuía de diagnósticos para obtener más información.
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.
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.
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.
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 espacio de disco disponible y de espacio de dirección virtual disponible.
La memoria caché está limitado por los factores siguientes:
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.
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 encuentra en el directorio de perfiles de usuario. 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é.
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.
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.
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.
El paquete (API) Java Communications es un paquete opcional que se proporciona para su uso con Runtime Environment para Windows. 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:
Asegúrese de que se ha instalado el SDK o Runtime Environment antes de instalar la API Java Communications.
Para instalar la API Java Communications desde un archivo comprimido:
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.
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.
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.
Para desinstsalar la API Java Communications, suprima los archivos siguientes del directorio en el que está instalado Runtime Environment:
De forma predeterminada, Runtime Environment se instala en el directorio C:\Archivos de programa\IBM\Java60\.
Puede encontrar la documentación y ejemplos de la API Java Communications en el sitio web de Sun.
http://java.sun.com/products/javacomm/.
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.
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/.
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.
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, Datos de programa\IBM\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.
Puede obtener archivos de política de jurisdicción no restringida de JCE en http://www.ibm.com/developerworks/java/jdk/security/index.html. En este sitio web también puede encontrar documentación sobre los paquetes de seguridad IBM JCE, JCEFIPS, JSSE2, JSSEFIPS, JGSS, JAAS y criptografía de hardware.
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.
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.
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.
Limitaciones conocidas de SDK y Runtime Environment para Windows.
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.
IBM SDK de 32 bits para Windows, v6, da soporte a los siguientes entornos locales:
No obstante, puede que los fonts de estos entornos locales no funcionen en componentes AWT.
IBM SDK de 32 bits para Windows, v6, da soporte a IPv6. No obstante, como el soporte actual de IPv6 en Windows no es de pila dual, el SDK emula el comportamiento de pila dual en un sistema habilitado para IPv6. La aplicación Java puede utilizar hasta dos veces el número de sockets debido a la naturaleza de la emulación. Para inhabilitar esta emulación, inhabilite el soporte IPv6 en el SDK estableciendo la propiedad del sistema java.net.preferIPv4Stack en true.
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:
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/.
Cuando trabaje con un editor de métodos de entrada (IME), es recomendable que complete la composición de caracteres y que seleccione el candidato antes de utilizar el espacio de trabajo para cualquier otra operación.
Cuando un usuario escribe texto en un área de texto AWT mientras utiliza un editor de métodos de entrada (IME) y después redimensiona la ventana de la aplicación antes de consignar el texto, el texto se consigna automáticamente.
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.
Los cortafuegos personales pueden producir problemas con el código Windows NIO y provocar que determinadas operaciones fallen. Por ejemplo, la llamada al método Selector.open() puede generar una excepción "java.io.IOException: No se ha podido establecer la conexión de bucle de retorno" con la causa "java.net.ConnectException: Conexión denegada: connect". La excepción se debe a que el sistema operativo se conecta a un puerto que está siendo bloqueado por el cortafuegos. La JVM volverá a intentar la operación de conexión, solicitando al sistema operativo que elija otro número de puerto. Si después de varios intentos continúa sin poder conectarse, se generará la excepción ConnectException.
Si aparece esta excepción, puede establecer la propiedad del sistema java.nio.debug=pipe para ver qué números de puerto están bloqueados.
En Windows 2000 y XP, el valor predeterminado del número de archivos que puede tener abiertos simultáneamente es demasiado bajo y dará problemas en las aplicaciones con una gran actividad de E/S. Para solucionar esta limitación, edite el archivo <windows>\system32\CONFIG.NT y establezca los siguientes valores:
files=200 buffers=60
donde <windows> es el directorio en el que se ha instalado Windows.
En Windows 2000, con una profundidad de color de 32 bits, el mecanismo DirectDraw de la JVM no vuelve a dibujar la región bajo el puntero del ratón. El efecto es que aparecen cuadrados grises o negros en los menús después de que el ratón haya estado en ellos. La solución es desactivar DirectDraw (-Dsun.java2d.noddraw) o cambiar la resolución de color de la pantalla a otro valor, por ejemplo, 256 colores.
La llamada NIO SocketChannel finishConnect() puede devolver true (el canal está conectado) o false (el proceso de conexión no ha finalizado todavía), o puede generar una excepción. En Windows 2000, cuando se utilizan conexiones de desbloqueo, se puede devolver false aunque previamente una llamada Java a select() haya implicado que el canal estaba preparado para el proceso.
No puede alterar el rango de pilas de la hebra principal Java (también conocida como hebra primordial) en el tiempo de ejecución. La hebra principal tiene un tamaño fijo de 256 KB, determinado como el valor óptimo a efectos de rendimiento. Puede utilizar la opción -Xss para modificar el rango de pilas sólo en hebras distintas de la principal. No utilice la hebra principal para cálculos demasiados recursivos porque la hebra principal es más propensa al desbordamiento que otras hebaras.
Si escribe caracteres DBCS en un JTextArea, JTextField o JFileChooser, el cambio de algunos editores IME en chino (en particular, código interno chino y Zhengma) al IME Intelligent ABC, puede producir un volcado del núcleo.
Los usuarios del idioma checo deben tener en cuenta que el panel de selección de idioma de Installshield ofrece una entrada traducida en una instalación que no está traducida. Esta es una limitación de InstallShield. La serie se elige en el sistema operativo según la página de códigos. Como el polaco (para el que está traducida la instalación) y el checo tienen los dos la página de códigos 1250, InstallShield intenta recuperar una lista de idiomas del sistema para ambos idiomas, por lo que aparece esta serie en la lista de idiomas.
Si es un usuario de chino tradicional, no deberá dirigir la salida de la aplicación Java directamente al mandato more. En su lugar, dirija la salida hacia un archivo temporal y después examine el archivo por separado.
Los usuarios de catalán, deben utilizar el font Lucida Console para evitar que las palabras en mayúsculas acentuadas aparezcan como caracteres corruptos. Esto afecta únicamente a los usuarios de Windows 2000.
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.
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.
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.
IBM, AIX, developerWorks, eServer, iSeries, MVS, POWER4, POWER5+, PowerPC, pSeries, System i, System p, System z, WebSphere, System z9, z/OS, 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.
Microsoft, Windows y el logotipo de Windows son marcas registradas de Microsoft Corporation 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.