Nota: antes de utilizar esta información y el producto al que da soporte, asegúrese de leer la información general que aparece en Avisos.
Esta edición de la guía de usuario corresponde a IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0, 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, 2004, 901 San Antonio Rd., Palo Alto, CA 94303 EE.UU. Reservados todos los derechos.
(c) Copyright International Business Machines Corporation, 1999, 2005. Reservados todos los derechos.
Derechos restringidos para los usuarios del Gobierno de los Estados Unidos - Su uso, duplicación o divulgación están restringidos por el GSA ADP Schedule Contract con IBM Corp.
Esta Guía del usuario proporciona información general sobre IBM(R) 32-bit SDK and Runtime Environment for Windows(R), Java(TM) 2 Technology Edition, Version 5.0 e información específica sobre las diferencias en la implementación de IBM comparada con la implementación de Sun. Lea esta Guía del usuario además de la documentación más amplia que se proporciona en el sitio Web de Sun: http://java.sun.com.
El SDK y el Runtime Environment reciben soporte en los siguientes productos:
Tenga en cuenta que IPv6 sólo recibe soporte sobre Windows XP y Windows Server 2003.
La guía Diagnostics Guide proporciona información más detallada sobre la IBM Virtual Machine para Java.
Los cambios técnicos realizados en esta Guía del usuario de la Versión 5.0, que no sean los menores u obvios como la actualización de la versión "1.4.2" a "5.0", están indicados en rojo cuando se trata de HTML o una copia impresa en color y mediante barras verticales a la izquierda de los cambios.
Los términos "Runtime Environment" y "Java Virtual Machine" se utilizan de manera indistinta a lo largo de esta Guía del usuario.
IBM SDK es un entorno de desarrollo para escribir y ejecutar applets y aplicaciones que se ajustan a la interfaz de programas de aplicación (API) central Java 1.4 de IBM.
El SDK incluye el Runtime Environment para Windows, que permite ejecutar sólo aplicaciones Java. Si ha instalado el SDK, está incluido el Runtime Environment.
El Runtime Environment contiene la Java Virtual Machine y archivos de soporte, incluidos los archivos de clases. El Runtime Environment contiene sólo un subconjunto de las clases que se encuentran en el SDK y permite dar soporte a un programa Java durante el tiempo de ejecución, pero no permite compilar programas Java. El Runtime Environment para Windows no incluye ninguna de las herramientas de desarrollo como, por ejemplo, appletviewer.exe o el compilador Java (javac.exe), ni clases que sean sólo para sistemas de desarrollo.
Asimismo, se proporciona el paquete de la interfaz de programas de aplicación Java Communications para su uso con Runtime Environment para Windows. Puede encontrar información sobre ello en Utilización de la API Java Communications (JavaComm).
En general, cualquier applet o aplicación que se ejecute con una versión anterior del SDK debería ejecutarse correctamente con IBM 32-bit SDK for Windows, v5.0. No se garantiza que las clases compiladas con este release funcionen en releases anteriores.
|IBM 32-bit SDK for Windows, V5.0, |está incorporado con Microsoft Visual Studio .NET 2003.
Consulte el sitio Web de Sun en http://java.sun.com para ver la documentación de Sun sobre compatibilidad.
Si desea actualizar el SDK de un release anterior, haga una copia de seguridad de todos los archivos de configuración y los archivos de políticas de seguridad antes de continuar con la actualización.
Después de la actualización, puede que necesite restaurar o reconfigurar estos archivos porque es posible que se hayan sobrescrito durante el proceso de actualización. Compruebe la sintaxis de los archivos nuevos antes de restaurar los archivos originales porque es posible que el formato o las opciones de los archivos hayan cambiado.
En la Versión 5.0, el IBM Runtime Environment para Windows contiene nuevas versiones de IBM Java Virtual Machine y el compilador Just-In-Time (JIT). Si realiza una migración desde un IBM Runtime Environment anterior, tenga en cuenta lo siguiente:
El SDK contiene varias herramientas de desarrollo y un Java Runtime Environment (JRE). En este apartado se describe el contenido de las herramientas del SDK y el Runtime Environment.
Las aplicaciones que se graban completamente en Java no deben tener dependencias de la estructura de directorios del IBM SDK (o los archivos en esos directorios). Una dependencia de la estructura de directorios del SDK (o los archivos en esos directorios) puede generar problemas de portabilidad de aplicaciones. Las aplicaciones JNI (Java Native Interface) tendrán algunas dependencias menores.
Nota: Las guías del usuario, el Javadoc y los archivos de licencia y copyright que se adjuntan, y el directorio demo son la única documentación que se incluye en este SDK para 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 en: http://java.sun.com.
Para instalar el paquete del SDK o del Runtime Environment, descargue el paquete de instalación correspondiente. Asegúrese de descargar todos los paquetes en el mismo directorio. Los paquetes y sus nombres de archivo se incluyen en el apartado Instalación atendida (interactiva); no cambie los nombres de archivo de los paquetes.
Antes de empezar la instalación, asegúrese de que hay espacio suficiente en el directorio C:\WINDOWS\TEMP utilizado durante la instalación. La cantidad de espacio temporal que se necesita 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 termina la instalación. Si dispone de suficiente espacio temporal y sigue apareciendo este mensaje, verifique que los paquetes que intenta instalar se hayan descargado completamente. Para ello, compare el tamaño de los archivos de los paquetes con los tamaños de archivo mostrados en las páginas Web desde las que ha descargado los paquetes.
Los paquetes que puede instalar son:
Se proporcionan otros paquetes con formato de archivo zip:
El Runtime Environment se instala por omisión en el directorio C:\Archivos de programa\IBM\Java50\jre.
Si ha descargado el paquete instalable del SDK, puede elegir si desea instalar:
Puede instalar los componentes individualmente o combinados.
En el asistente de instalación, aparecen las siguientes opciones:
Cuando instala el Runtime Environment (bien como parte del paquete instalable del SDK o desde el paquete instalable del Runtime Environment), se le pregunta si desea instalar el Runtime Environment como la Java Virtual Machine (JVM) del sistema. Si se instala como System JVM, el programa de instalación copia los archivos java.exe y javaw.exe en el directorio del sistema de Windows. Si ya existe una versión de java.exe o javaw.exe en el directorio del sistema de Windows, se le pregunta si desea sobrescribir la versión existente con la versión actual. La instalación de estos archivos en el directorio del sistema de Windows convierte al Runtime Environment en la JVM por omisión del sistema. Además, se establece la clave de registro "Current Version" para que coincida con esta instalación.
Para crear una instalación desatendida, debe realizar primero una instalación atendida y crear un archivo de respuestas (setup.iss) que registre las opciones seleccionadas durante la instalación. El archivo de respuestas que cree debe ser adecuado para los sistemas en los que tenga previsto utilizarlo. Si es necesario, cree varios archivos de respuestas para utilizarlos en la instalación de paquetes en sistemas que tengan distintas configuraciones.
Para crear un archivo de respuestas mientras ejecuta la instalación, escriba lo siguiente en el indicador de mandatos:
ibm-java2-sdk-50-win-i386 /r
o bien
ibm-java2-jre-50-win-i386 /r
Dependiendo del producto Windows, el archivo de respuestas (setup.iss) se crea en el directorio C:\Windows o C:\Winnt, donde C: es la unidad de arranque.
El siguiente mensaje puede aparecer durante una instalación interactiva:
Another Java Runtime Environment is currently installed as the System JVM. Select Yes to overwrite this version or No to exit this installation.
Si aparece este mensaje, seleccione No y salga de la instalación. Vaya al directorio del sistema de Windows y suprima los dos archivos siguientes:
Después de suprimir los archivos, reinicie la instalación interactiva utilizando el mandato que se muestra al principio de este apartado.
En el sistema en que desee ejecutar la instalación desatendida, copie el archivo de respuestas setup.iss en el directorio C:\Windows. Después de copiar el archivo, escriba lo siguiente en el indicador de mandatos:
ibm-java2-sdk-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log ibm-java2-jre-50-win-i386 /s /f1c:\Windows\setup.iss /f2c:\setup.log
Si la instalación es satisfactoria, el archivo de registro contiene la serie ResultCode=0.
IBM Accessibility Bridge se instala pero está inhabilitado por omisión. Para habilitar IBM Accessibility Bridge, suprima el símbolo de almohadilla que aparece al principio de la siguiente línea del archivo Accessibility.properties en el directorio jre/lib:
#assistive_technologies=JawBridge
Este sitio Web proporciona más información sobre los programas de utilidad Accessibility:
http://java.sun.com/products/jfc/accessibility.html
Puede inhabilitar el soporte de Java Accessibility para aumentar el rendimiento de carga de la JVM de las aplicaciones Java que no proporcionan soporte de tecnología de ayuda Java, especialmente a través de enlaces de red.
Para inhabilitar el soporte de Java Accessibility, establezca la variable de entorno JAVA_ASSISTIVE en OFF. Si esta variable de entorno se establece en OFF, no habrá disponible ninguna tecnología de ayuda, como JawBridge, 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).
La ventana de mandatos normalmente utiliza la página de códigos OEM. La salida de consola de Java utiliza la página de códigos de la ventana de mandatos desde donde se inicia Java. No obstante, el mandato javaw utiliza siempre la página de códigos ANSI. Especifique la página de códigos que se va a utilizar para la salida de consola con la opción -Dconsole.encoding en el mandato java. Por ejemplo, -Dconsole.encoding=Cp1252 hace que toda la salida de consola esté en la página de códigos Latin1 ANSI de Windows (1252).
Tenga en cuenta que, si altera la variable de entorno PATH tal como se describe a continuación, alterará temporalmente los ejecutables Java existentes en la vía de acceso.
Después de instalar el SDK, puede ejecutar una herramienta escribiendo su nombre en el indicador de shell con un nombre de archivo como argumento.
Puede especificar la vía de acceso a una herramienta escribiendo siempre la vía de acceso antes del nombre de la herramienta. Por ejemplo, si el SDK para Windows está instalado en C:\Archivos de programa\IBM\Java50\bin, puede compilar un archivo denominado miarchivo.java escribiendo lo siguiente en un indicador de mandatos:
"C:\Archivos de programa\IBM\Java50\bin\javac" miarchivo.java
Para no tener que escribir cada vez la vía de acceso completa:
Si ha instalado el SDK o el Runtime Environment en otro directorio, sustituya C:\Archivos de programa\IBM\Java50\ por el directorio en el que ha instalado el SDK o el Runtime Environment
javac miarchivo.java
La variable de entorno PATH habilita Windows para encontrar archivos ejecutables como, por ejemplo, javac, java y javadoc, desde cualquier directorio activo. Para visualizar el valor actual de PATH, escriba lo siguiente en el indicador de mandatos:
echo %PATH%
La CLASSPATH indica a las herramientas del SDK como, por ejemplo, java, javac y javadoc, dónde se encuentran las bibliotecas de clases Java.
Sólo es necesario establecer la CLASSPATH de forma explícita en los siguientes casos:
Para visualizar el valor actual de CLASSPATH, escriba lo siguiente en el indicador de mandatos:
echo %CLASSPATH%
Si tiene previsto desarrollar y ejecutar aplicaciones que utilicen entornos de tiempo de ejecución diferentes, incluido otras versiones que haya instalado por separado, debe establecer la CLASSPATH (y la PATH ) de forma explícita para cada aplicación. Si tiene previsto ejecutar varias aplicaciones simultáneamente y utilizar entornos de tiempo de ejecución diferentes, cada aplicación debe ejecutar su propia ventana de mandatos.
Si desea ejecutar sólo una versión de Java cada vez, puede utilizar un script por lotes para conmutar entre los distintos entornos de tiempo de ejecución.
Para desinstalar el SDK, tanto si se ha utilizado la instalación atendida o desatendida:
Este procedimiento elimina todos los paquetes instalados con el instalador. No elimina el paquete de la API Java Communications (consulte el capítulo API Java Communications) ni ningún otro archivo que se haya extraído de los paquetes zip.
Cuando se mantienen varias instalaciones entre IBM 32-bit SDK for Windows, v5.0 y versiones V1.3.1 o anteriores, si desinstala una versión anterior mientras sigue instalada en el sistema una versión V5.0, el desinstalador de V1.3.1 elimina las siguientes claves de registro, y todas las subclaves, necesarias para la versión V5.0, lo que daña la instalación de V5.0:
Por lo tanto, vuelva a instalar V5.0 después de desinstalar la versión V1.3.1. Esta limitación del desinstalador se ha solucionado en V1.4.0 y los releases siguientes.
La herramienta java inicia una aplicación Java iniciando un Java Runtime Environment y cargando una clase especificada.
La JVM busca la clase inicial (y otras clases utilizadas) en tres pasos de localización: la classpath de la rutina de carga, las extensiones instaladas y la classpath del usuario. Los argumentos que se especifiquen después del nombre de clase o nombre de archivo JAR se pasan a la función principal.
El mandato javaw es idéntico a java, excepto que javaw no tiene una ventana de consola asociada. Utilice javaw si no desea que aparezca una ventana indicadora de mandatos. El iniciador javaw muestra un recuadro de diálogo con información de error si se produce una anomalía durante el inicio.
Los mandatos java y javaw tienen la sintaxis siguiente:
java [ opciones ] clase [ argumentos ... ] java [ opciones ] -jar archivo.jar [ argumentos ... ] javaw [ opciones ] clase [ argumentos ... ] javaw [ opciones ] -jar archivo.jar [ argumentos ... ]
Los elementos que aparecen entre corchetes son opcionales.
Si se especifica la opción -jar, el archivo JAR especificado contiene los archivos de clases y recursos de la aplicación, con la clase de arranque indicada mediante la cabecera de manifiesto Main-Class (clase principal).
El iniciador tiene un conjunto de opciones estándar a las que el Runtime Environment da soporte actualmente y en releases futuros. Además, existe un conjunto de opciones no estándar. Las opciones por omisión se han seleccionado para el mejor uso general. Deben tenerse en cuenta las mayúsculas y minúsculas cuando se decida realizar cambios.
Puede especificar las propiedades del sistema y las opciones de Java de tres modos distintos. En orden de prioridad, éstos modos son:
Las opciones situadas más a la derecha de la línea de mandatos tienen prioridad sobre las opciones situadas más a izquierda; por ejemplo, si especifica las opciones -Xint -Xjit miClase, tendrá prioridad -Xjit.
Las opciones -X que se listan a continuación no son estándar y están sujetas a cambios sin previo aviso.
En las opciones del parámetro <tamaño>, debe añadir al número el sufijo "k" o "K" para indicar kilobytes, "m" o "M" para indicar megabytes, y "g" o "G" para indicar gigabytes.
Para obtener el número de versión y de nivel de compilación de IBM, en el indicador de mandatos escriba:
java -version
El mandato java y otros mandatos del iniciador java (como javaw) permiten especificar un nombre de clase con cualquier carácter que esté en el juego de caracteres del entorno local actual.
También puede especificar cualquier carácter Unicode en el nombre de clase y argumentos utilizando secuencias de escape Java. Para hacerlo, debe especificar -Xargencoding. Para especificar un carácter Unicode, utilice secuencias de escape con el formato \u####, donde # es un dígito hexadecimal (0 a 9, A a F).
De forma alternativa, para especificar que el nombre de clase y los argumentos del mandato están en codificación UTF8, utilice -Xargencoding:utf8, o en la codificación ISO8859_1, utilice -Xargencoding:latin.
Por ejemplo, para especificar una clase denominada "HelloWorld" utilizando la codificación Unicode para las dos letras mayúsculas, utilice este mandato:
java -Xargencoding '\u0048ello\u0057orld'
Los mandatos java y javaw proporcionan mensajes de salida traducidos. Estos mensajes difieren según el entorno local en el que se ejecute Java. Las descripciones de error y otra información de depuración devuelta por java están en inglés.
Para establecer que se ejecute automáticamente una clase java o un archivo jar desde el archivo utilice la opción Herramientas->Opciones de carpeta->Tipos 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\Java50\jre\bin\java.exe %l %*
Sun proporciona el Java Access Bridge para facilitar a las tecnologías de asistencia nativas de Windows, como los lectores de pantalla, acceso al soporte Java Accessibility en una aplicación Java. Estas tecnologías de asistencia nativas de Windows deben soportar llamadas al Java Access Bridge.
El 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 su uso con JawBridge.
Si ya ha habilitado el IBM Accessibility Bridge (JawBridge), que permite que el Windows 2000 Magnifier funcione con aplicaciones Swing, y desea habilitar JawBridge al mismo tiempo que el Java Access Bridge, edite la línea del archivo accessibility.properties para que diga:
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 el Java Access Bridge:
http://java.sun.com/products/jfc/accessibility.html
El compilador Just-In-Time (JIT) de IBM genera dinámicamente el código máquina utilizado con frecuencia por secuencias de código de bytes en aplicaciones o applets Java durante su ejecución. |El |compilador JIT V5.0 proporciona nuevas optimizaciones como resultado de |las investigaciones del compilador, mejora las optimizaciones |implementadas en las versiones anteriores de JIT y proporciona un mayor |aprovechamiento del hardware.
El IBM SDK y el Runtime Environment incluyen el JIT, que está habilitado por omisión. Generalmente, no es necesario invocar el JIT explícitamente, ya que la compilación de código de bytes Java a código de máquina ocurre de forma transparente. No obstante, si tiene problemas con el Runtime Environment al ejecutar una aplicación Java o un applet, puede inhabilitar el JIT para aislar el problema. La inhabilitación del JIT sólo debe ser una medida temporal; éste es necesario para un rendimiento adecuado.
Existen tres modos de inhabilitar el JIT:
En el indicador de mandatos donde se ejecute la aplicación, escriba:
set JAVA_COMPILER=NONE
Asimismo, puede establecer permanentemente JAVA_COMPILER utilizando la interfaz gráfica de usuario. Abra Panel de control, seleccione Sistema y, en la pestaña Avanzada, seleccione Variables de entorno.
java -Djava.compiler=NONE MiApli
java -Xint MiApli
Ambas opciones de la línea de mandatos alteran temporalmente la variable de entorno JAVA_COMPILER.
Para habilitar el JIT explícitamente, establezca la variable de entorno JAVA_COMPILER en "jitc" o utilice la opción -D para establecer la propiedad java.compiler property en "jitc". Alternativamente, utilice la opción -Xjit (y omita la opción -Xint) en la línea de mandatos de la JVM para activar el JIT.
Si la variable de entorno JAVA_COMPILER o la propiedad java.compiler se establecen en "" (la serie vacía), el JIT permanece inhabilitado. Para desestablecer la variable de entorno adecuadamente, escriba set JAVA_COMPILER= en el indicador de mandatos.
Para determinar si el JIT está habilitado, escriba lo siguiente en un indicador de mandatos:
java -version
Si el JIT no se está utilizando, aparece un mensaje que incluye lo siguiente:
(JIT disabled)
Si el JIT se está utilizando, aparece un mensaje que incluye lo siguiente:
(JIT enabled)
Para obtener más información sobre el JIT, consulte la guía Diagnostics Guide.
El recopilador de desechos gestiona la memoria utilizada por Java y las aplicaciones que se ejecutan en la VM.
Cuando el recopilador de desechos recibe una solicitud de almacenamiento, la memoria no utilizada en el almacenamiento dinámico se define aparte: "asignación". El recopilador de desechos también busca áreas de memoria a las que ya no se haga referencia, y las libera para que se puedan reutilizar: "recopilación".
La fase de recopilación puede desencadenarla un error de asignación de memoria, que se produce cuando no queda espacio para una solicitud de almacenamiento, o una llamada explícita a System.gc().
La recopilación de desechos puede afectar significativamente al rendimiento de la aplicación, por lo que la máquina virtual IBM ofrece varios métodos para optimizar la recopilación de desechos y reducir de esta forma el efecto en la aplicación.
Para obtener información más detallada sobre la recopilación de desechos, consulte la guía Diagnostics Guide.
La opción -Xgcpolicy especifica la política de recopilación de desechos.
-Xgcpolicy toma los valores optthruput (el valor por omisión y el recomendado), optavgpause o gencon. La opción controla el comportamiento del recopilador de desechos, realizando intercambios entre la salida de la aplicación y el sistema en general y los tiempos de pausa provocados por la recopilación de desechos.
El formato de la opción y sus valores son:
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
Cuando un intento de una aplicación de crear un objeto no se puede cumplir inmediatamente con el espacio disponible en el almacenamiento dinámico, corresponde al recopilador de desechos identificar los objetos sin referencia (desechos), suprimirlos y devolver el almacenamiento dinámico a un estado en el que las peticiones de asignación inmediatas y posteriores se puedan satisfacer rápidamente. Estos ciclos de recopilación de desechos provocan pausas inesperadas ocasionales en la ejecución del código de la aplicación. Como el tamaño y la complejidad de las aplicaciones aumenta y los almacenamientos dinámicos crecen en consecuencia, este tiempo de pausa de recopilación de desechos tiende a aumentar en duración e importancia. El valor por omisión de la recopilación de desechos, -Xgcpolicy:optthruput, proporciona una salida muy alta para las aplicaciones, pero al coste de estas pausas ocasionales, que pueden variar de unos pocos milisegundos a varios segundos, en función del tamaño del almacenamiento dinámico y la cantidad de desechos.
La JVM utiliza dos técnicas para reducir los tiempos de pausa:
La opción de línea de mandatos -Xgcpolicy:optavgpause solicita el uso de la recopilación de desechos concurrente para reducir significativamente el tiempo invertido en las pausas de recopilación de desechos. La GC concurrente reduce el tiempo de pausa mediante la realización de actividades de recopilación de desechos de forma concurrente durante la ejecución normal del programa, para minimizar la interrupción provocada por la recopilación del almacenamiento dinámico. La opción -Xgcpolicy:optavgpause también limita el efecto de aumentar el tamaño de almacenamiento dinámico en la duración de la pausa de recopilación de desechos. La opción -Xgcpolicy:optavgpause es muy útil en configuraciones con grandes almacenamientos dinámicos. Con el tiempo de pausa reducido, puede experimentarse alguna reducción en el rendimiento de las aplicaciones.
Durante la recopilación de desechos concurrente, se invierte una cantidad importante de tiempo en la identificación de objetos de duración relativamente larga que no se pueden recopilar. Si la GC se concentra sólo en aquellos objetos con más probabilidad de reciclarse, podrá reducir aún más los tiempos de pausa de algunas aplicaciones. Esto es lo que hace la GC generacional al reducir el almacenamiento dinámico en dos "generaciones": las áreas de "cantera" y de "permanencia". Los objetos se colocan en una de estas áreas dependiendo de su antigüedad. La cantera es la menor de las dos y contiene los objetos más jóvenes; la permanencia es mayor y contiene los objetos más antiguos. Los objetos se asignan primero a la cantera; si sobreviven lo suficiente, al final pasan al área de permanencia.
La GC generacional depende que la mayoría de los objetos no duren mucho. La GC generacional reduce los tiempos de pausa al concentrar el trabajo en reclamar el almacenamiento en la cantera, ya que tiene el espacio más reciclable. En lugar de tiempos de pausa ocasionales pero largos para recopilar todo el almacenamiento dinámico, se recopila la cantera con más frecuencia y, si la cantera es lo suficientemente pequeña, los tiempos de pausa son comparativamente cortos. No obstante, la GC generacional tiene el inconveniente de que, con el tiempo, el área de permanencia puede llenarse si muchos objetos duran demasiado tiempo. Si esto ocurre, para minimizar el tiempo de pausa, utilice una combinación de GC concurrente y GC generacional. La opción -Xgcpolicy:gencon solicita el uso combinado de GC concurrente y generacional para minimizar el tiempo invertido en una pausa de recopilación de desechos.
Si el almacenamiento dinámico de Java está casi lleno y hay muy pocos desechos que recopilar, es posible que las peticiones de objetos nuevos no se puedan satisfacer rápidamente ya que no hay espacio disponible inmediatamente. Si se trabaja con un almacenamiento dinámico casi lleno, el rendimiento de las aplicaciones puede resentirse sin importar cuál de las opciones anteriores se usa y, si se siguen realizando peticiones de más espacio de almacenamiento dinámico, la aplicación recibe una excepción OutofMemory, que provoca la interrupción de la JVM si esta excepción no se detecta y gestiona. En este punto, la JVM produce un archivo de diagnóstico "javadump". En estas condiciones, se recomienda incrementar el tamaño del almacenamiento dinámico mediante la opción -Xmx o reducir el número de objetos de aplicación en uso. Para obtener más información, consulte la guía Diagnostics Guide.
Cuando se activa una señal que resulta interesante para la JVM, se llama a un manejador de señales. Este manejador de señales determina si ha sido llamado por una hebra Java o no Java.
Si la señal es de una hebra Java, la JVM toma el control del manejo de la señal. Si se ha instalado un manejador de aplicaciones para esta señal y no ha especificado la opción de línea de mandatos -Xnosigchain, cuando la JVM haya finalizado el proceso, se llamará al manejador de aplicaciones de esta señal.
Si la señal es de una hebra no Java y la aplicación que ha instalado la JVM ha instalado previamente su propio manejador de señales, se pasa el control a ese manejador. De lo contrario, si la JVM o la aplicación Java solicitan la señal, se ignorará la señal o se realizará la acción por omisión.
La excepción a esta regla se produce en Windows, donde se crea una nueva hebra por cada señal generada externamente (por ejemplo, al pulsar Control-Inter) para ejecutar 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 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 son para temas de control interno y no hacen que termine. La única señal de control interesante es SIGBREAK, que hace que se genere un Javadump.
La Tabla 1 siguiente muestra las señales utilizadas por la JVM. Las señales se agrupan en la tabla por tipo o utilización, de la forma siguiente:
| Nombre de señal | Tipo de señal | Descripción | Inhabilitada por -Xrs |
|---|---|---|---|
| SIGINT | Interrupción | Atención interactiva (Control-C). La JVM sale normalmente. | Sí |
| SIGTERM | Interrupción | Petición de terminación. La JVM saldrá normalmente. | Sí |
| SIGBREAK | Control | Señal de interrupción procedente de un terminal. La JVM utiliza esto para tomar Javadumps. | Sí |
Utilice la opción -Xrs (reducir el uso de señales) para evitar que la JVM maneje la mayoría de señales. Para obtener más información, consulte la página del iniciador de aplicaciones de Java de Sun en http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html.
Las señales 2 (SIGINT) y 15 (SIGTERM) en las hebras de JVM hacen que la JVM concluya; por lo tanto, un manejador de señales de la aplicación no debería intentar recuperarse de esta señal a menos que ya no necesite los servicios de la JVM.
El Runtime Environment contiene un encadenamiento de señales. El encadenamiento de señales permite a la JVM interoperar de forma más eficaz con el código nativo que instala sus propios manejadores de señales.
El encadenamiento de señales permite a la aplicación enlazar y cargar la biblioteca compartida 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.
Para utilizar jsig.dll, enlácela con la aplicación que crea o incorpora la JVM.
IBM SDK contiene el procesador XSLT4J y el analizador XML4J que cumplen la especificación JAXP 1.3. Estas herramientas permiten analizar y transformar documentos XML independientemente de la implementación de proceso XML específica. Al utilizar "Factory Finders" (Buscadores de fábricas) para ubicar las implementaciones de SAXParserFactory, DocumentBuilderFactory y TransformerFactory, la aplicación puede cambiar entre las distintas implementaciones sin necesidad de modificar ningún código.
|La tecnología XML incluida en el IBM SDK es similar a |Apache Xerces Java y Apache Xalan Java. Consulte | http://xml.apache.org/xerces2-j/ y |http://xml.apache.org/xalan-j/ para obtener |más información.
El procesador XSLT4J permite elegir entre el procesador XSLT Interpretive original o el nuevo procesador XSLT Compiling. El procesador Interpretive está diseñado para entornos de herramientas y depuración, y da soporte a las funciones de ampliación XSLT que no están soportadas por el procesador XSLT Compiling. El procesador XSLT Compiling está diseñado para entornos de tiempo de ejecución de alto rendimiento; genera un motor de transformación, o translet, desde una hoja de estilo XSL. Este enfoque separa la interpretación de las instrucciones de la hoja de estilo de su aplicación de tiempo de ejecución en datos XML.
El procesador XSLT Interpretive es el procesador por omisión. Para seleccionar el procesador XSLT Compiling, puede:
Para implementar las propiedades del archivo jaxp.properties, copie jaxp.properties.sample en jaxp.properties, en C:\Archivos de programa\IBM\Java50\. Este archivo también contiene información detallada completa sobre el procedimiento utilizado para determinar qué implementaciones se deben utilizar para TransformerFactory, SAXParserFactory y DocumentBuilderFactory.
Para aumentar el rendimiento cuando se transforma un objeto StreamSource con el procesador XSLT Compiling, especifique la clase com.ibm.xslt4j.b2b2dtm.XSLTCB2BDTMManager como el proveedor del servicio org.apache.xalan.xsltc.dom.XSLTCDTMManager. Para determinar el proveedor de servicios, pruebe cada uno de estos pasos hasta que encuentre org.apache.xalan.xsltc.dom.XSLTCDTMManager:
El procesador XSLT Compiling detecta el proveedor de servicios del servicio org.apache.xalan.xsltc.dom.XSLTCDTMManager cuando se crea un objeto javax.xml.transform.TransformerFactory. Los objetos javax.xml.transform.Transformer o javax.xml.transform.sax.TransformerHandler que se crean utilizando ese objeto TransformerFactory utilizarán el mismo proveedor de servicios. Sólo puede cambiar los proveedores de servicio si modifica uno de los valores descritos anteriormente y, a continuación, crea un nuevo objeto TransformerFactory.
Si utiliza una versión anterior de Tomcat, puede aplicarse esta limitación.
Si utiliza una versión anterior de Xerces (previa a 2.0) o Xalan (previa a 2.3) en la alteración confirmada, puede obtener una excepción de puntero nulo cuando ejecute la aplicación. Esta excepción se produce porque las versiones anteriores no manejan correctamente el archivo jaxp.properties.
Para evitar este problema, utilice una de las siguientes soluciones provisionales:
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.SAXParserFactory= org.apache.xerces.jaxp.SAXParserFactoryImplo bien
set IBM_JAVA_OPTIONS=-Djavax.xml.parsers.DocumentBuilderFactory= org.apache.xerces.jaxp.DocumentBuilderFactoryImplo bien
set IBM_JAVA_OPTIONS=-Djavax.xml.transform.TransformerFactory= org.apache.xalan.processor.TransformerFactoryImpl
En los siguientes apartados se proporciona información sobre el uso del SDK para Windows para desarrollar aplicaciones Java. Consulte el apartado Herramientas del SDK para obtener información detallada sobre las herramientas disponibles.
Para depurar programas Java, puede utilizar la aplicación Depurador Java (JDB) u otros depuradores que se comuniquen utilizando la JPDA (Java Platform Debugger Architecture) que se proporciona con el SDK para Windows.
El Depurador Java (JDB) se incluye en el 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_socket,server=y,address=<puerto>
MyApp <argumentos de MiApl>jdb -attach <número de puerto>El depurador se conectará a la JVM y ya puede emitir una amplia gama de mandatos para examinar y controlar la aplicación Java; por ejemplo, escriba run para ejecutar la aplicación Java.
Para obtener más información sobre las opciones de JDB, escriba:
jdb -help
Para obtener más información sobre los mandatos de JDB:
También puede utilizar JDB para depurar aplicaciones Java que se estén ejecutando en máquinas remotas. JDPA utiliza un socket TCP/IP para conectarse a la JVM remota.
jdb -attach <nombre de máquina o dirección ip>:<número de puerto>
Cuando inicie una sesión de depuración utilizando el transporte dt_socket, asegúrese de que los puertos especificados estén libres para su uso.
|Java Virtual Machine Debugging Interface (JVMDI) |no está soportada en este release. Se ha |sustituido por Java Virtual Machine Tool Interface (JVMTI).
Para obtener más información sobre JDB y JPDA, y su utilización, consulte los siguientes sitios Web:
Algunas aplicaciones Java deben poder determinar si se están ejecutando en una JVM de 32 bits o en una JVM de 64 bits. Por ejemplo, si la aplicación tiene una biblioteca de código nativo, la biblioteca se debe compilar por separado en formatos de 32 y 64 bits para las plataformas que den soporte a las modalidades de 32 y 64 bits de funcionamiento. En este caso, la aplicación debe cargar la biblioteca correcta en el tiempo de ejecución, ya que no se puede mezclar código de 32 y 64 bits.
La propiedad del sistema com.ibm.vm.bitmode permite a las aplicaciones determinar la modalidad en la que se está ejecutando la JVM. Devuelve los siguientes valores:
Puede inspeccionar la propiedad del sistema com.ibm.vm.bitmode desde el código de la aplicación utilizando la llamada:
System.getProperty("com.ibm.vm.bitmode");
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:
Este número de versión determina sólo el nivel de la interfaz JNI nativa que se va a utilizar. El nivel real de la JVM que se crea viene especificado por las bibliotecas J2SE (esto es, v5.0). La API de la interfaz JNI no afecta a la especificación del lenguaje implementada por la JVM, las API de bibliotecas de clases o cualquier otra área del comportamiento de la JVM. Para obtener más información, consulte http://java.sun.com/j2se/1.5.0/docs/guide/jni.
Si la aplicación necesita dos bibliotecas JNI, una creada para 32 bits y otra para 64 bits, utilice la propiedad del sistema com.ibm.vm.bitmode para determinar si está ejecutando una JVM de 32 o de 64 bits y elegir la biblioteca adecuada.
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.
Para ejecutar un applet con el Visor de applets, escriba lo siguiente en un indicador de mandatos:
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 el 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.
Por ejemplo, http://java.sun.com/applets/NervousText/example1.html es el URL de una página Web que llama a un applet. Para invocar el Visor de applets en esta página Web, escriba en el indicador de shell:
appletviewer http://java.sun.com/applets/NervousText/example1.html
El Visor de applets no reconoce la opción charset del código <META>. Si el archivo que carga appletviewer no está codificado como el valor por omisión del sistema, se puede producir una excepción de E/S. Para evitar la excepción, utilice la opción -encoding cuando ejecute appletviewer. Por ejemplo:
appletviewer -encoding JISAutoDetect sample.html
Puede depurar applets utilizando la opción -debug del Visor de applets. Cuando se depuran applets, se recomienda invocar el Visor de applets desde el directorio que contiene el archivo HTML que llama al applet. Por ejemplo:
cd <demo>\TicTacToe appletviewer -debug example1.html
Donde <demo> se sustituye por la vía de acceso completa en la que ha descomprimido el paquete de demostración.
Puede encontrar documentación sobre cómo depurar applets utilizando el Visor de applets en el sitio Web de Sun: http://java.sun.com.
| | |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 local para el usuario JVM |está configurada para permitir "Bloquear las páginas en la memoria".
J2SE (Java 2 Platform, Standard Edition) da soporte, como mínimo, a las especificaciones definidas en el soporte de Especificaciones oficiales de CORBA en J2SE (V1.5). En algunos casos, el IBM J2SE ORB da soporte a versiones más recientes de las especificaciones.
Este SDK da soporte a todas las versiones de GIOP, tal como se define en los capítulos 13 y 15 de la especificación CORBA 2.3.1, en el documento de OMG formal/99-10-07, que puede obtener en:
http://www.omg.org/cgi-bin/doc?formal/99-10-07
El GIOP bidireccional no está soportado.
Este SDK da soporte a los interceptores portátiles, tal como se define en el OMG en el documento ptc/01-03-04, que puede obtener en:
http://www.omg.org/cgi-bin/doc?ptc/01-03-04
Los interceptores portátiles son enganches al ORB mediante los cuales los servicios ORB pueden interceptar el flujo de normal de ejecución del ORB.
Este SDK da soporte al Servicio de nombres interoperativo, tal como se define en el OMG en el documento ptc/00-08-07, que puede obtener en:
http://www.omg.org/cgi-bin/doc?ptc/00-08-07
El puerto por omisión que utiliza el Servidor de nombres transitorios (el mandato tnameserv), cuando no se proporciona ningún parámetro ORBInitialPort, ha cambiado de 900 a 2809, que es el número de puerto registrado con IANA (Internet Assigned Number Authority) para un Servicio de nombres CORBA. Puede que tenga que actualizar los programas que dependen de este valor por omisión para que funcionen con esta versión.
El contexto inicial que se devuelve del Servidor de nombres transitorios es ahora org.omg.CosNaming.NamingContextExt. Los programas existentes que reducen la referencia a un contexto org.omg.CosNaming.NamingContext continúan funcionando, y no se tienen que volver a compilar.
El ORB da soporte a los parámetros -ORBInitRef y -ORBDefaultInitRef definidos por la especificación de Servicio de nombres interoperativo, y la operación ORB::string_to_object da soporte ahora a los formatos de serie de ObjectURL (corbaloc: y corbaname:) definidos por la especificación de Servicio de nombres interoperativo.
El OMG especifica un método ORB::register_initial_reference para registrar un servicio con el Servicio de nombres interoperativo. No obstante, este método no está disponible en la API Sun Java Core Versión 5.0. Los programas que necesiten registrar un servicio en la versión actual deben invocar este método en la clase de implementación de ORB interna de IBM. Por ejemplo, para registrar un servicio "MiServicio":
((com.ibm.CORBA.iiop.ORB)orb).register_initial_reference("MiServicio",
serviceRef);
donde orb es una instancia de org.omg.CORBA.ORB que se devuelve de ORB.init(), y serviceRef es un objeto CORBA que está conectado al ORB. Este mecanismo es provisional, y no es compatible con las próximas versiones ni puede trasladarse a otros ORB que no sean de IBM.
Una característica de depuración en tiempo de ejecución proporciona una capacidad de servicio mejorada. Es muy útil para el diagnóstico de problemas o puede solicitarla el personal de servicio de IBM. El rastreo se controla mediante tres propiedades del sistema.
Por ejemplo, para rastrear sucesos y mensajes de GIOP formateados, escriba:
java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true miapli
No active el rastreo para operaciones normales, ya que puede disminuir el rendimiento. Aunque haya desactivado el rastreo, FFDC (First Failure Data Capture) continúa funcionando, de forma que sólo se notifican los errores graves. Si se genera un archivo de salida de depuración, examínelo para comprobar el problema. Por ejemplo, puede que se haya detenido el servidor sin ejecutar ORB.shutdown().
El contenido y el formato de la salida de rastreo variará según la versión.
Las siguientes propiedades permiten ajustar el ORB:
Por ejemplo, para establecer el tamaño de fragmento en 4096 bytes:
java -Dcom.ibm.CORBA.FragmentSize=4096 miapli
El tamaño de fragmento por omisión es 1024 bytes. Para desactivar la fragmentación, establezca el tamaño de fragmento en 0.
java -Dcom.ibm.CORBA.RequestTimeout=30
-Dcom.ibm.CORBA.LocateRequestTimeout=30 miapli
Por omisión, el ORB espera indefinidamente una respuesta. No establezca el tiempo de espera demasiado bajo y así evitará que las conexiones finalicen de forma innecesaria.
Por ejemplo, para que el ORB utilice el puerto 1050, escriba:
java -Dcom.ibm.CORBA.ListenerPort=1050 miapli
Si se establece esta propiedad, el ORB empieza a escuchar tan pronto como se inicializa. De lo contrario, empieza a escuchar sólo cuando sea necesario.
Cuando se ejecuta con Java 2 SecurityManager, la invocación de algunos métodos en las clases de la API CORBA puede provocar comprobaciones de permisos, que pueden generar una SecurityException. Los métodos afectados son los siguientes:
| Clase/Interfaz | Método | Permiso necesario |
|---|---|---|
|
org.omg.CORBA.ORB |
init |
java.net.SocketPermission resolve |
|
org.omg.CORBA.ORB |
connect |
java.net.SocketPermission listen |
|
org.omg.CORBA.ORB |
resolve_initial_references |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_is_a |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_non_existent |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
OutputStream _request (String, boolean) |
java.net.SocketPermission connect |
|
org.omg.CORBA. portable.ObjectImpl |
_get_interface_def |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
invoke |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
send_deferred |
java.net.SocketPermission connect |
|
org.omg.CORBA. Request |
send_oneway |
java.net.SocketPermission connect |
|
javax.rmi. PortableRemoteObject |
narrow |
java.net.SocketPermission connect |
Si el programa utiliza alguno de estos métodos, compruebe que tenga los permisos necesarios.
Las clases de implementación de ORB en este release son:
Estos son los valores por omisión, y se recomienda no establecer estas propiedades o hacer referencia a las clases de implementación directamente. A efectos de portabilidad, haga referencia sólo a las clases de la API CORBA, y no a la implementación. Estos valores pueden cambiar en próximos releases.
La Invocación a método remoto (RMI) de Java proporciona un mecanismo sencillo para realizar la programación Java distribuida. RMI a través de IIOP (RMI-IIOP) utiliza el protocolo IIOP (Internet Inter-ORB Protocol) estándar de Common Object Request Broker Architecture (CORBA) para ampliar la RMI Java básica para la comunicación. Esto permite dirigir la interacción con otros ORB (Object Request Brokers) de CORBA, siempre que estén implementados en Java o en otro lenguaje de programación.
La siguiente documentación está disponible:
La agrupación de hebras para manejadores de conexiones para RMI no está habilitada por omisión.
Para habilitar la agrupación de conexiones implementada a nivel TCPTransport de RMI, establezca la opción
-Dsun.rmi.transport.tcp.connectionPool=true (o cualquier valor no nulo)
Esta versión del Runtime Environment no tiene ningún valor que pueda utilizarse para limitar el número de hebras en la agrupación de conexiones.
Para obtener más información, consulte el sitio de Java de Sun: http://java.sun.com.
El IBM SDK incluye el soporte BiDireccional mejorado. Para obtener más información, consulte http://www-106.ibm.com/developerworks/java/jdk/bidirectional/index.html. El Javadoc para el paquete BiDirectional se suministra con el SDK en el archivo docs/apidoc.zip.
A partir de Java 5.0, la clase IBM BigDecimal ha sido adoptada por Sun como |java.math.BigDecimal. IBM ya no mantiene com.ibm.math.BigDecimal y se ha etiquetado |como desechado. Se recomienda migrar el código Java existente para que utilice |java.math.BigDecimal.
|El nuevo java.math.BigDecimal utiliza los mismos métodos que los anteriores |java.math.BigDecimal y com.ibm.math.BigDecimal. El código existente que utiliza |java.math.BigDecimal continuará funcionando correctamente.
|Para migrar el código Java existente para que utilice la clase |java.math.BigDecimal, cambie la sentencia import al principio del archivo java de: |import com.ibm.math.*; a import java.math,*;.
IBM SDK y Runtime Environment establecen el Euro como la moneda por omisión para los países de la Unión Monetaria Europea (EMU) a partir del 1 de enero de 2002.
Para utilizar la moneda nacional anterior, especifique -Duser.variant=PREEURO en la línea de mandatos Java.
Si ejecuta los entornos locales de inglés de Reino Unido, danés o sueco y desea utilizar el Euro, especifique -Duser.variant=EURO en la línea de mandatos Java.
El paquete de la interfaz de programas de aplicación (API) Java Communications (JavaComm) es un paquete opcional que se proporciona para su uso con Runtime Environment para Windows. JavaComm se instala de forma independiente del SDK o el Runtime Environment.
La API JavaComm ofrece a las aplicaciones Java un método independiente de la plataforma para ejecutar comunicaciones de puerto paralelo y serie en tecnologías como, por ejemplo, correo de voz, fax y smartcards. Después de grabar comunicaciones de puerto paralelo o serie para la aplicación, puede incluir esos archivos con la aplicación.
La API Java Communications da soporte a puertos serie Electronic Industries Association (EIA)-232 (RS232) y puertos paralelo Institute of Electrical and Electronics Engineers (IEEE) 1284, y está soportada en sistemas con IBM Runtime Environment Versión 5.0.
Utilizando la API Java Communications puede:
Asegúrese de que hay instalada una copia del SDK o el Runtime Environment antes de instalar la API Java Communications.
Para instalar la API Java Communications desde un archivo zip:
Si ha aceptado el directorio por omisión al instalar el Runtime Environment, el archivo comm.jar estará en C:\Archivos de programa\IBM\Java50\jre\lib\ext.
Si ha descomprimido el archivo en otro directorio, los archivos se guardarán en la misma estructura de directorios, pero C:\Archivos de programa\IBM\Java50\ se sustituirá por el directorio donde haya descomprimido el archivo.
Después de instalar la API Java Communications, debe:
Si imprime con la API Java Communications, puede que tenga que pulsar "Alimentación de papel", "Continuar" u otra opción similar en la impresora.
Para desinstalar la API Java Communications, suprima los siguientes archivos del directorio donde haya instalado el Runtime Environment:
Por omisión, el Runtime Environment se instala en el directorio C:\Archivos de programa\IBM\Java50\.
Puede encontrar la documentación y ejemplos de la API Java Communications en el sitio Web de Sun: http://java.sun.com.
El Java Plug-in es un plug-in de navegador Web. Si utiliza el Java Plug-in, puede ignorar la JVM por omisión del navegador Web y utilizar en su lugar el Runtime Environment que desee para ejecutar applets o beans en el navegador.
Debe permitir que los applets terminen de cargarse para que el navegador no se 'cuelgue'. Por ejemplo, si utiliza el botón Atrás y, a continuación, el botón Adelante mientras se está cargando un applet, puede que no se puedan cargar las páginas HTML.
El Java Plug-in está documentado por Sun en: http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/.
|
| |Sistema operativo | |Internet Explorer | |Netscape | |Mozilla |
|---|---|---|---|
| |Windows 2000 | |5.5 SP2, 6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows XP | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
| |Windows Server 2003 | |6.0 | |4.78, 6.2.2, 7.2 | |1.4.x, 1.5.x, 1.6.x, 1.7.x, Firefox 1.0.x |
Tenga en cuenta que Internet Explorer 5.01, el navegador por omisión en |Windows 2000, no está soportado.
Debido a limitaciones en determinados navegadores, es posible que no pueda implementar todas las funciones del paquete org.w3c.dom.html.
El Java Plug-in soporta caracteres de doble byte (por ejemplo chino tradicional BIG-5, coreano, japonés) como parámetros para los códigos <APPLET>, <OBJECT> y <EMBED>. Debe seleccionar la codificación de caracteres correcta para el documento HTML para que el Java Plug-in pueda analizar el parámetro. Especifique la codificación de caracteres para el documento HTML utilizando el código <META> en la sección <HEAD> de esta forma:
<meta http-equiv="Content-Type" content="text/html; charset=big5">
Este ejemplo indica al navegador que analice el archivo HTML utilizando la codificación de caracteres chinos BIG-5. Todos los parámetros se pasan correctamente al Java Plug-in. Sin embargo, es posible que algunas versiones antiguas de navegadores no entiendan correctamente este código. En este caso, puede forzar que el navegador ignore este código, pero deberá cambiar la codificación manualmente.
Para especificar la codificación que desea utilizar para analizar el archivo HTML:
Puede utilizar Java Web Start para desplegar aplicaciones Java. Web Start permite al usuario iniciar y gestionar aplicaciones directamente desde la Web. Utilizando Java Web Start, puede iniciar aplicaciones fácilmente desde la Web, con la garantía de que ejecuta la última versión, lo que elimina los procedimientos de instalación o actualización. Java Web Start elimina la necesidad de descargar e instalar software, lo que permite ahorrar el tiempo de las opciones de instalación.
|Además de los java-vm-args que se describen en |http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources, |Web Start da soporte a -Xgcpolicy para establecer la política |de recopilación de desechos.
Para obtener información sobre los navegadores que dan soporte a Web Start, consulte el apartado Navegadores soportados.
Para obtener más información sobre Web Start, consulte: http://java.sun.com/products/javawebstart y http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html. Para obtener más información sobre el despliegue de aplicaciones, consulte: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/index.html.
Puede invocar Web Start de tres formas:
Una vez descargada una aplicación, ésta se almacena en la Antememoria de aplicaciones Java. Si se vuelve a acceder a la aplicación, Java Web Start descarga una versión más reciente de la aplicación, si está disponible, y si no, utiliza la versión que hay en la antememoria.
Si se produce un error en un archivo .jnlp (como un nombre de código no válido), Web Start falla sin mostrar un mensaje de error.
Una aplicación Java, a diferencia de un applet Java, no se puede basar en un navegador Web para los servicios de instalación y tiempo de ejecución. Cuando se envía una aplicación Java, el paquete de software suele estar formado por los siguientes componentes:
Para ejecutar la aplicación, un usuario necesita 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 del SDK con la aplicación. Asegúrese de que la máquina de destino tenga instalada una versión con licencia de SDK para Windows.
| | |IBM Virtual Machine (VM) permite compartir clases de aplicación y de rutina de |carga entre VM, almacenándolas en la antememoria en una memoria compartida. El |compartimiento de clases reduce el consumo general de memoria virtual cuando más de |una VM comparte una antememoria. El compartimiento de clases también reduce el |tiempo de arranque de una VM una vez creada la antememoria. La antememoria de clases |compartidas es independiente de la VM activa y persiste después del tiempo de vida |de la VM que ha iniciado la antememoria.
| |El IBM SDK permite compartir tantas clases como sea posible, de forma |transparente para el usuario.
| |La antememoria de clases compartidas contiene datos y metadatos de clases |estáticas de sólo lectura que describen las clases. Cualquier VM puede leer o |actualizar la antememoria. Las VM que comparten clases deben ser del mismo release. |Debe tener cuidado si utiliza la modificación del código de bytes en el |tiempo de ejecución. (Consulte Modificación del código de bytes en el tiempo de ejecución.)
| |Como la antememoria de clases compartidas persiste después del tiempo de vida de |la VM, la antememoria se actualiza dinámicamente para reflejar las modificaciones |realizadas en los JAR o en las clases del sistema de archivos. La actualización |dinámica hace que la antememoria sea transparente para la aplicación que la |utiliza.
| |Habilite el compartimiento de clases utilizando la opción |-Xshareclasses cuando inicie una VM, para que la VM se conecte |a una antememoria existente o cree una si no existe. Todas las clases de |aplicación y de rutina de carga cargadas por la VM se comparten por omisión. Los |cargadores de clases personalizados se comparten automáticamente si amplían el |cargador de clases de la aplicación; de lo contrario, deben utilizar la API Helper |de Java que se proporciona con la VM para acceder a la antememoria. (Consulte el |apartado Adaptación de cargadores de clases personalizados para compartir clases.)
| |El acceso a la antememoria de clases compartidas está limitado por |permisos del sistema operativo y permisos de la seguridad Java. |Sólo un cargador de |clases que se haya registrado para compartir clases puede añadir clases a |la antememoria de clases compartidas. Si un Java SecurityManager está |instalado, los cargadores de clases, excepto los cargadores de clases por |omisión de la extensión, la aplicación o la rutina de carga, deben obtener |permiso para compartir clases añadiendo SharedClassPermissions al archivo |java.policy. (Consulte Utilización de SharedClassPermissions.) |El RuntimePermission "createClassLoader" limita la creación de nuevos |cargadores de clases y, por lo tanto, restringe el acceso a la |antememoria.
| |En un sistema pueden existir varias antememorias, que se especifican por el |nombre como una subopción del mandato -Xshareclasses. |Una VM sólo puede conectarse a una antememoria cada vez. El tamaño de la antememoria se |especifica en el arranque utilizando -Xscmx<n>[k|m|g], |pero después este tamaño se fija para el tiempo de vida de la antememoria. Las |antememorias existen hasta que se destruyen de forma explícita utilizando una |subopción en el mandato -Xshareclasses o hasta que se reinicia |el sistema.
| |Todos los programas de utilidad de antememoria son |subopciones en el mandato -Xshareclasses. Utilice |-Xshareclasses:help para ver una lista de las subopciones |disponibles.
| |El compartimiento de clases se habilita y se configura utilizando las opciones de |la línea de mandatos -Xshareclasses y -Xscmx.
|Para habilitar el compartimiento de clases, añada |-Xshareclasses[:name=<nombre>] en la línea de mandatos de la |aplicación. La VM se conectará a una antememoria existente con el nombre |proporcionado o creará una nueva antememoria con ese nombre. Si se crea |una nueva antememoria, se llenará con todas las clases de aplicación y de |rutina de carga que se están cargando hasta que se llena la antememoria. Si se inician dos o más VM simultáneamente, todas llenarán la |antememoria de forma simultánea.
|Para comprobar que se ha creado la antememoria, ejecute java |-Xshareclasses:listAllCaches. Para ver cuántas clases y |cuántos datos de clases se están compartiendo, ejecute java |-Xshareclasses:[name=<nombre>],printStats. (Estos programas de utilidad se |pueden ejecutar cuando la VM de aplicación haya terminado o en otra ventana de |mandatos).
|Para ver las clases que se están cargando desde la antememoria o que se han |almacenado en la antememoria, añada |-Xshareclasses:[name=<nombre>],verbose en la línea de mandatos de la |aplicación.
|Para suprimir la antememoria creada, ejecute java |-Xshareclasses:[name=<nombre>],delete. Las antememorias sólo se deben |suprimir si contienen muchas clases obsoletas o si la antememoria está llena y desea |crear una antememoria mayor.
|Se recomienda que ajuste el tamaño de antememoria para la aplicación |específica porque es poco probable que el valor por omisión sea el tamaño |óptimo. La mejor forma de determinar el tamaño óptimo de antememoria es |especificar una antememoria grande mediante -Xscmx, |ejecutar la aplicación y, a continuación, utilizar printStats para |determinar cuántos datos de clases se han almacenado. Añada una pequeña |cantidad al valor mostrado en printStats por si se produce alguna |contingencia. Tenga en cuenta que como las clases se pueden cargar en |cualquier momento durante la vida de la VM, es mejor realizar este |análisis después de que la aplicación haya finalizado. No |obstante, una antememoria completa no tiene ningún impacto |negativo en el rendimiento o capacidad de cualquier VM conectada a |ella, de modo que es legítimo decidir un tamaño de antememoria menor |que el necesario.
|Si se llena una antememoria, se emite un mensaje a la línea de |mandatos de todas las VM que utilicen la antememoria y éstas cargan |cualquier otra clase en su propia memoria de proceso. Las clases de una antememoria llena todavía se |pueden compartir, pero una antememoria llena es de sólo lectura y no se |puede actualizar con nuevas clases.
| |El compartimiento de clases es particularmente útil en los sistemas que |utilizan más de una VM con un código similar, ya que éstos se benefician |del consumo reducido de memoria virtual. También es útil en los sistemas |que arrancan y concluyen las VM con frecuencia, ya que éstos se benefician |de la mejora en el tiempo de arranque.
|La carga adicional que supone crear y llenar una nueva antememoria es mínima. |El coste del tiempo de arranque de la VM para una única VM se encuentra |normalmente entre el 0 y el 5%, dependiendo de cuántas clases se carguen. La mejora en |el tiempo de arranque de la VM con una antememoria que se ha llenado de |clases se encuentra normalmente entre el 10% y el 40%, dependiendo del |sistema operativo y del número de clases cargadas. Varias VM en ejecución |de forma concurrente mostrarán más ventajas relacionadas con el tiempo de |arranque global.
|Cuando se ejecuta la aplicación con el compartimiento de clases, se pueden |utilizar las herramientas del sistema operativo para ver la reducción en el consumo |de la memoria virtual.
| |El tamaño máximo de antememoria teórico es 2GB. La |antememoria estará limitada por los siguientes |factores:
| |Una VM que utiliza un agente JVMTI que puede modificar el código de bytes no |puede compartir clases, a menos que se utilice la subopción |modified=<contexto_modificado> en la línea de mandatos (ver arriba). El contexto |modificado es un descriptor especificado por el usuario que describe el tipo de |modificación que se está realizando. Todas las VM que utilicen un determinado |contexto modificado deben modificar el código de bytes de forma predecible y |repetible para cada clase, para que las clases modificadas almacenadas en la |antememoria tengan las modificaciones esperadas cuando las cargue otra VM. |El motivo por el que una modificación debe ser predecible es que el agente |no puede volver a modificar las clases cargadas desde la antememoria de |clases compartidas. Tenga en |cuenta que el código de bytes modificado y no modificado se puede almacenar en la |misma antememoria. Consulte la guía Diagnostics |Guide para obtener más información sobre este tema.
| |En los sistemas operativos que pueden ejecutar aplicaciones de |32 bits y 64 bits, el compartimiento de clases no está permitido entre VM de 32 bits |y 64 bits. La subopción listAllCaches listará las antememorias |de 32 bits o 64 bits, dependiendo de la modalidad de dirección de la VM que se está |utilizando.
|La antememoria de clases compartidas necesita espacio de disco para almacenar |información de identificación acerca de las antememorias que existen en el sistema. |Esta información se encuentra en el directorio de perfiles de |usuario. Si se suprime el directorio de información de |identificación, la VM no podrá identificar las clases compartidas en el sistema y |deberá volver a crear la antememoria.
|Los permisos para |acceder a una antememoria de clases compartidas vienen determinados por el |sistema operativo. Si no se especifica un nombre de antememoria, se añade el nombre de |usuario al nombre por omisión para que varios usuarios en el mismo sistema puedan |crear sus propias antememorias por omisión.
| |Si un SecurityManager se está utilizando junto con el compartimiento |de clases y la aplicación en ejecución utiliza sus propios cargadores de |clases, éstos deben obtener SharedClassPermissions antes de que puedan |compartir clases. Debe añadir SharedClassPermissions |al archivo java.policy utilizando el nombre de clase del cargador de |clases (se pueden utilizar comodines) y "read", "write" o "read,write" |para determinar el acceso otorgado. Por ejemplo:
|permission |com.ibm.oti.shared.SharedClassPermission "com.abc.customclassloaders.*", |"read,write";
Si un cargador de clases no tiene el SharedClassPermission correcto |e intenta compartir clases, se generará una excepción AccessControlException. |No puede cambiar o reducir los permisos de los cargadores de clases de la |extensión, la aplicación o la rutina de carga.
| |La mayoría de aplicaciones Java utilizarán los propios cargadores de clases de la |VM o tendrán cargadores de clases personalizados que amplíen |java/net/URLClassLoader. Las aplicaciones que utilicen estos cargadores de |clases podrán compartir clases de rutina de carga y de aplicación |automáticamente. Los cargadores de clases |personalizados que no amplíen java/net/URLClassLoader requerirán modificaciones para |poder utilizar el compartimiento de clases. Todos los cargadores de clases |personalizados deberán obtener SharedClassPermissions si se está |utilizando un SecurityManager; para ello, consulte |Utilización de SharedClassPermissions. IBM proporciona |varias interfaces Java para los distintos tipos de cargadores de clases |personalizados, que permiten a los cargadores de clases buscar y almacenar |clases en la antememoria de clases compartidas. |Estas clases están en el paquete com.ibm.oti.shared. El Javadoc para este |paquete se suministra con el SDK en el archivo docs/apidoc.zip. Consulte la guía |Diagnostics Guide para obtener más información |sobre cómo utilizar estas interfaces.
Si tiene el derecho de servicios del código de programa según se establece en IBM Solutions Developer Program, póngase en contacto con IBM Solutions Developer Program a través de su método normal de acceso o en la Web en: http://www-1.ibm.com/partnerworld/.
Si ha adquirido un contrato de servicio (por ejemplo, la Línea de soporte de IBM Personal Systems o un servicio equivalente por país), los términos y condiciones de ese contrato de servicio determinan qué servicios, si existen, tiene derecho a recibir de acuerdo con el programa.
Las Guías del usuario que se suministran con este SDK y el Runtime Environment se han probado utilizando lectores de pantalla. Puede utilizar un lector de pantalla como Home Page Reader o el lector de pantalla JAWS con estas Guías del usuario.
Para cambiar los tamaños de font en las Guías del usuario, utilice la función que se proporciona con el navegador, que normalmente se encuentra en la opción de menú Ver.
Los usuarios que necesiten el desplazamiento mediante teclas pueden consultar la descripción de las pulsaciones más útiles para las aplicaciones Swing en "Swing Key Bindings" (Enlaces de teclas de Swing) en http://www-128.ibm.com/developerworks/java/jdk/additional/
|Además de la GUI, la herramienta iKeyman proporciona la |herramienta de línea de mandatos IKEYCMD, que tiene |las mismas funciones que la GUI de iKeyman. IKEYCMD permite |gestionar claves, certificados y peticiones de certificado. Puede invocar |IKEYCMD desde scripts de shell nativos y desde los programas |que se utilizan cuando las aplicaciones necesitan añadir interfaces personalizadas a |las tareas de gestión de claves y certificados. |IKEYCMD puede crear archivos de base de datos de claves para |todos los tipos que admite actualmente iKeyman. IKEYCMD |también puede crear peticiones de certificado, importar certificados firmados por CA |y gestionar certificados autofirmados.
Para ejecutar un mandato IKEYCMD, entre:
java [-Dikeycmd.properties=<archivo de propiedades>]com.ibm.gsk.ikeyman.ikeycmd <objeto> <acción> [opciones]
donde:
Para obtener más información, consulte la Guía de usuario de iKeyman en: http://www.ibm.com/developerworks/java/jdk/security/index.html.
Si recorre la lista desplegable de un componente JComboBox con las teclas del cursor, el botón o el campo editable del recuadro combinado no cambia de valor hasta que se selecciona un elemento. Este es el comportamiento deseado para este release, ya que mejora la accesibilidad y la utilización, al garantizar que el comportamiento del recorrido del teclado sea coherente con el comportamiento del recorrido del ratón.
IBM Java Web Start v5.0 contiene varias mejoras de accesibilidad y utilización con respecto al release anterior, incluido un soporte mejorado de lectores de pantalla y un desplazamiento mediante teclas optimizado.
Puede utilizar la línea de mandatos sólo para iniciar una aplicación Java habilitada para Web Start. Para cambiar las opciones de preferencias, debe editar un archivo de configuración, 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 antememoria 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.
Tenga en cuenta estas limitaciones en IBM 32-bit SDK for Windows, v5.0:
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.
Si tiene algún comentario acerca de la utilidad, o no utilidad, de esta Guía del usuario, estaremos encantados de conocer su opinión a través de uno de estos canales. Tenga en cuenta que estos canales no están destinados a responder consultas técnicas, sólo son para comentarios acerca de documentación. Envíe sus comentarios:
La letra pequeña. Si elige enviar un mensaje a IBM, acepta que toda la información contenida en su mensaje, incluidos los datos de respuesta, como preguntas, comentarios, sugerencias, etc., se considerarán no confidenciales e IBM no tendrá ningún tipo de obligación sobre dicha información y será libre de reproducir, utilizar, revelar y distribuir la información a otros sin limitaciones. Además, IBM será libre de utilizar cualquier idea, concepto, conocimiento o técnica contenido en dicha información para cualquier tipo de propósito, incluyendo, pero sin limitarse al desarrollo, fabricación y marketing de productos que incluyan dicha información.
Esta información se ha desarrollado para productos y servicios que se ofrecen en los EE.UU. IBM puede que no ofrezca los productos, servicios o características que se discuten en este documento en otros países. Consulte a su representante local de IBM para obtener información acerca de los productos y servicios actualmente disponibles en su zona. Cualquier referencia a un producto, programa o servicio de IBM no pretende afirmar ni implica que sólo se pueda utilizar dicho producto, programa o servicio de IBM. En su lugar, puede utilizarse cualquier producto, programa o servicio funcionalmente equivalente que no infrinja ninguno de los derechos de propiedad intelectual de IBM. Sin embargo, la evaluación y la verificación del funcionamiento conjuntamente con otros productos, programas o servicios que no son de IBM es responsabilidad del usuario.
IBM puede tener aplicaciones patentadas o pendientes de patente que cubran el tema tratado en este documento. La posesión de este documento no le otorga ninguna licencia sobre estas patentes. Puede enviar consultas de licencias por escrito a la dirección siguiente:
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 cualquier otro país en el que tales disposiciones sean incoherentes con la legislación nacional:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL" SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLICITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN, COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunos estados no contemplan la limitación de responsabilidades, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no sea aplicable en su caso.
Esta información puede contener imprecisiones técnicas o errores tipográficos. Periódicamente se realizarán modificaciones en la información aquí contenida; dichos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta información en cualquier momento y sin previo aviso.
Cualquier referencia hecha en esta información a sitios Web que no son de IBM se proporciona únicamente para su comodidad y no debe considerarse en modo alguno como promoción de dichos sitios Web. Los materiales de estos sitios Web no forman parte de los materiales de IBM para este producto y el uso que se haga de estos sitios Web es de la entera responsabilidad del usuario.
IBM puede utilizar o distribuir la información que facilite de la manera que considere apropiada sin incurrir en obligaciones con el remitente.
Los poseedores de la licencia de este programa que deseen obtener información acerca del mismo con el propósito de permitir (i) el intercambio de información entre programas creados independientemente y otros programas (incluido éste) y (ii) la utilización mutua de la información intercambiada, deben ponerse en contacto con la dirección siguiente:
Esta información estará disponible, sujeta a los términos que correspondan, lo que en algunos casos incluirá el pago de una cuota.
IBM proporciona el programa con licencia descrito en este documento y todo el material con licencia disponible para el mismo bajo los términos del Acuerdo de cliente de IBM, el Acuerdo internacional de licencia de programas IBM o cualquier acuerdo equivalente entre las dos partes.
Cualquier información acerca del rendimiento que contenga el presente documento se ha determinado en un entorno controlado. Por lo tanto, los resultados obtenidos en otros entornos operativos pueden variar significativamente. Es posible que algunas medidas se hayan tomado en sistemas de nivel de desarrollo y no hay garantías de que estas medidas serán iguales en los sistemas habitualmente disponibles. Asimismo, algunas mediciones pueden haber sido estimadas mediante la extrapolación. Los resultados reales pueden variar. Los usuarios de este documento deben verificar los datos aplicables para su entorno específico.
La información relativa a productos que no son de IBM se ha obtenido de los proveedores de estos productos, de los anuncios públicos o de otras fuentes disponibles públicamente. IBM no ha probado esos productos y no puede confirmar la precisión del rendimiento, su compatibilidad o cualquier otra afirmación relacionada con productos que no son de IBM. Las preguntas sobre las posibilidades de los productos que no son de IBM deben dirigirse a los proveedores de dichos productos.
IBM es una marca registrada de International Business Machines Corporation en los Estados Unidos y/o en otros países.
Java y todas las marcas y logotipos basados en Java son marcas comerciales o marcas registradas de Sun Microsystems, Inc. en los Estados Unidos y/o en otros países.
Microsoft, Windows y el logotipo de Windows son marcas registradas de Microsoft Corporation en los Estados Unidos y/o en otros países.
Otros nombres de empresas, productos o servicios pueden ser marcas registradas o de servicio de otros.
Este producto también está basado en parte del trabajo de FreeType Project. Para obtener más información sobre Freetype, consulte http://www.freetype.org.
Este producto incluye software desarrollado por Apache Software Foundation http://www.apache.org/.