Notas sobre la versión JavaTM 2 SDK, edición estándar Versión 1.3.1

Contenido

Información general
Máquina virtual Java
Propiedades de fuentes
Defecto de Xserver en Solaris
RMI
CORBA, RMI-IIOP y Java IDL
Tecnología Java 2D^TM
Arrastrar y soltar
Accesibilidad
AWT y Swing
JDBC
Seguridad
Conexión en red
Componente Java^TM Plug-in
Notas de adaptación al entorno
Documentación
Las herramientas no pueden convertir las cadenas PCK en japonés en Solaris 2.6
Problemas de fuentes en chino tradicional
Soporte de Windows 2000
Instalación en Windows NT

Java 2 SDK, edición estándar, versión 1.3.1 (J2SDK 1.3.1) es una versión de mantenimiento que soluciona defectos identificados en versiones anteriores. Si desea obtener más detalles sobres estas soluciones, consulte el apartado de

Defectos corregidos en esta versión

Además, J2SDK 1.3.1 contiene las siguientes mejoras.

• Mejoras de Java^TM Plug-in
  Esta versión incluye el producto Java Plug-in mejorado con nuevas características que lo hacen más versátil, más fácil de usar y de configurar y que permiten la compatibilidad con las nuevas características de la interfaz Open JVM del navegador Netscape 6. Consulte el apartado sobre New Java Plug-in Features si desea obtener más información. Estas mejoras de Java Plug-in se introdujeron por primera vez en la versión de actualización J2SDK 1.3.0_01.

• Manejo de errores en la máquina virtual Java
  Las máquinas virtuales Java de J2SDK 1.3.1 tienen un nuevo mecanismo de manejo de errores que imprime la información de depuración en la pantalla cuando se produce una caída del sistema en código nativo. Si desea obtener más información, consulte Error Handling in J2SDK 1.3.1.

• El convertidor de HTML ahora forma parte de Java 2 SDK
  Ahora, el convertidor de HTML viene incluido en Java 2 SDK. En las versiones anteriores, incluida la versión J2SDK 1.3.1 Beta, el convertidor de HTLM sólo estaba disponible en un paquete independiente.

Si desea obtener información acerca del producto Java Plug-in, consulte la sede web de Java Plug-in.

Podrá descargar un conjunto de documentación completo de J2SDK 1.3.1 disponible para la descarga. Consulte también el nuevo documento en línea Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.

Las notas siguientes contienen información interesante para los usuarios de J2SDK 1.3.1. Incluye descripciones de soluciones de defectos importantes, defectos conocidos, soluciones alternativas y varios consejos y sugerencias para el uso de esta versión.

Las notas siguientes están relacionadas con la máquina virtual Java.

• En las plataformas de Linux, si algún archivo que forme parte de la operación de E/S está cerrado, el subproceso en espera de la operación de E/S no se iniciará. Este problema se ha identificado con el número de defecto 4344135 . Para evitar este problema, establezca la variable de entorno J2SE_PREEMPTCLOSE a 1.

  J2SE_PREEMPTCLOSE=1 
  exportar J2SE_PREEMPTCLOSE
  

• Error 4323062: cualquier servicio de Windows NT que incorpore una máquina virtual Java se cancela cuando el usuario finaliza la sesión.

  Este defecto se ha solucionado en J2SDK 1.3.1. Para habilitar la solución, se debe transferir la opción de la línea de comandos -Xrs a la máquina virtual Java. El argumento de la línea de comandos adicional es necesario porque la solución inhabilita el mecanismo de enlace del apagado de J2SDK 1.3 y prohíbe el uso de la clase sun.misc.Signal. Si desea obtener más información, consulte al menos, la última sección de la evaluación de Bug Parade:

  http://developer.java.sun.com/developer/bugParade/bugs/4323062.html

• Un defecto JNI puede provocar una caída de la máquina virtual Java después de que un programa haya terminado, con un mensaje de error similar al siguiente.

  Se detectó otra excepción mientras se manejaba el último error.
  Volcar información sobre el último error: 
  ARCHIVO DE INFORME DE ERROR	= (N/D) 
  PC               		= 0x0x41621c7a 
  SEÑAL     		    	= 11 
  NOMBRE DE FUNCIÓN    		= (N/D) 
  NOMBRE DE BIBLIOTECA      	= (N/D) 
  Compruebe el ARCHIVO DE INFORME DE ERROR para obtener más información, 
  si hubiera alguna. Adiós.
  

  Este problema es más frecuente en Linux Red Hat 7.1 SMP, aunque en teoría podría aparecer también en las plataformas de Microsoft Windows y Solaris.

  Solución alternativa - Agregar una llamada de salida explícita al final del método principal de la aplicación: Runtime.getRuntime().exit(0)

• La ejecución de código en la plataforma Java sobre un NFS montado automáticamente en Red Hat 7.1 puede llevar a frecuentes caídas de dlopen() en Red Hat. Por lo visto, este problema se debe al montador automático del NFS y desaparece cuando el directorio se monta de forma explícita con mount -t nfs.

Esta versión tiene los problemas siguientes en relación a las propiedades de fuentes.

• Cuando se usan versiones RedHat Linux distintas de la 6.1, el archivo font.properties puede que no muestre correctamente algunos caracteres Symbol/Dingbats en algunos componentes AWT. Para solucionar este problema, use el archivo revisado font.properties para sustituir el archivo que se encuentra en <JAVA_HOME>/jre/lib/.

• Debido al error 4419794, las propiedades de fuentes pueden generar mensajes de aviso en entornos nacionales UTF-8 en Solaris 8 (arquitectura Intel). Si necesita utilizar entornos nacionales UTF-8 en Solaris 8 con hardware Intel, actualice el sistema a la versión 4 de la actualización de Solaris 8, donde este problema ya se ha solucionado.

Un defecto en Solaris Xserver puede provocar una caída del sistema cuando una aplicación escrita en lenguaje de programación Java haga referencia a las fuentes. Este problema se describe en el informe de defectos 4391019. A mediados de junio de 2001 estarán disponibles las siguientes modificaciones de Solaris para Xserver que seguramente ayuden a reducir este problema.

Para Solaris 2.6: 105633-55 (Sparc) 106248-41 (Intel)
Para Solaris 7: 108376-24 (Sparc) 108377-22 (Intel)
Para Solaris 8: 108652-31 (Sparc) 108653-26 (Intel)

Compruebe la sede web de SunSolve para ver la disponibilidad de estas modificaciones.

Los cambios que se describen a continuación son cambios importantes para las funciones RMI (Invocación de métodos remotos) de esta versión.

• El requisito "accept" java.net.SocketPermission para recibir llamadas remotas
  Debido a un defecto en implementaciones anteriores de J2SDK, antes se podía exportar un objeto remoto en un contexto de control de acceso determinado y recibir a continuación una llamada remota para dicho objeto en una conexión de zócalo determinada, aunque el contexto del control de acceso no tuviera el requisito "accept" java.netSocketPermission para la java.net.InetAddress remota y el puerto para la conexión del zócalo.

  Este defecto se ha solucionado, y en algunos casos, el código que exporta los objetos remotos debe tener más permisos que los que tenía en las implementaciones anteriores para que funcione correctamente.

  Como ejemplo de cómo otorgar dichos permisos mediante la sintaxis del archivo de políticas de seguridad predeterminadas, el permiso para aceptar las conexiones del zócalo desde un sistema denominado terrier.east.sun.com se puede expresar con la entrada de permiso siguiente (en la entrada de permiso para el código de fuente apropiado):

  permission java.net.SocketPermission "terrier.east.sun.com", "accept";
  

  Como se describe en la documentación de java.netSocketPermission, la especificación del sistema se puede iniciar con un comodín "*", por lo que el permiso para aceptar las conexiones del zócalo para un sistema se puede expresar con la siguiente entrada de permiso en una entrada de permiso determinada:

  permission java.net.SocketPermission "*", "accept";
  

• Los objetos remotos no exportados que no se incluyen en la liberación de recursos
  En implementaciones anteriores y en circunstancias específicas, la RMI en tiempo de ejecución hacía referencia a un objeto remoto incluso después de no haber sido exportado explícitamente. Este defecto se ha solucionado de modo que la RMI en tiempo de ejecución nunca hará referencia a un objeto remoto que no se haya exportado explícitamente.

• Rendimiento de la tabla de sustitución de ObjectOutputStream
  En implementaciones anteriores, una instancia de ObjectOutputStream recordaba objetos sustituidos (es decir, objetos que se habían devuelto mediante una llamada a ObjectOutputStream.replaceObjecto por un método writeReplace definido por clase) de modo que se usaba una búsqueda lineal para determinar si un objeto tenía sustituto. Por ello, si el número de objetos sustituidos de un flujo determinado era demasiado grande, la carga adicional indirecta de la búsqueda se hacía demasiado costosa para cada uno de los objetos de la serie. Este defecto se ha solucionado de modo que la implementación utiliza ahora un algoritmo más eficaz para recordar la sustitución de objetos. Esta solución de la implementación de las series del objeto también beneficia a la escalabilidad de la sustitución de objetos durante el proceso de ordenación del argumento RMI y del valor de retorno.

Los comentarios siguientes hacen referencia a las funciones CORBA, RMI-IIOP y Java IDL de esta versión.

• No se ha probado todavía la interoperatividad de Sun ORB con los ORB de otros proveedores y no se garantiza, por tanto, que Sun ORB funcione correctamente con ORB de otros proveedores.

• Si un servidor de J2SDK 1.3.1 se conecta primero con un cliente J2SDK 1.3 y, a continuación, un cliente J2SDK 1.3.1 intenta enviar una instancia serializable que usa writeUTF o readUTF en sus métodos writeObject o readObject respectivamente, se producirá una excepción MARSHAL. De la misma manera, si un servidor de J2SDK 1.3.1 se conecta primero con un cliente J2SDK 1.3.1 y, a continuación, un cliente J2SDK 1.3 intenta enviar una instancia de la misma clase, se produce una excepción MARSHAL. Este problema se ha identificado con el número de defecto 4434140.

  Solución alternativa - Cambie la clase serializable para que use writeObject y readObject en lugar de writeUTF y readUTF.

• J2SDK 1.3 reasignaba las llamadas de writeUTF y readUTF a cadenas CORBA en lugar de hacerlo a wstrings. De este modo, era imposible usar estos métodos para enviar cadenas con caracteres cuyos valores fueran superiores a 8 bits. Este defecto se solucionó en J2SDK 1.3.1, pero si se comunica con J2SDK 1.3, se puede aplicar la misma limitación. Este problema se ha identificado con el número de defecto 4379597.

  Solución alternativa - Use writeObject y readObject en lugar de writeUTF y readUTF. JDK 1.3.1 y J2SDK 1.3 reasignan estos objetos a llamadas de CORBA wstring cuando los parámetros de método son cadenas.

• El ORB de Java que se entrega con J2SDK 1.3.1 contiene soluciones para admitir los cambios de evolución de las clases serializables, como se especifica en Java Serialialization Specification.

  Debido a esta compatibilidad, J2SDK 1.3.1 y las próximas versiones de J2SDK pueden gestionar la evolución de las clases. Por ejemplo, si una clase V que se entregó en J2SDK 1.3.1 evoluciona en una próxima versión de J2SDK, una aplicación cliente (que envía/recibe la clase V) que ejecute J2SDK 1.3.1 podrá interoperar con el servidor (que recibe/envía la clave V evolucionada) que se ejecute en una próxima versión de J2SDK y viceversa.

  Sin embargo, la versión anterior de J2SDK 1.3.0 tiene defectos que no permiten la evolución de clase (consulte, por ejemplo, el informe de defectos 4365188 en la sede web de Java Developer Connection^SM). Esto significa que habrá problemas de interoperatividad cuando J2SDK 1.3.1 intente enviar clases evolucionadas a J2SDK 1.3.

• Al escribir un código en OMG IDL, no utilice un nombre de interfaz como nombre del módulo. Si lo hace, corre el riesgo de obtener resultados incoherentes al compilar con herramientas de distintos fabricantes, poniendo en peligro la portabilidad del código. Por ejemplo, un código que contenga los mismos nombres puede compilarse con el compilador de IDL a Java de Sun Microsystems y obtener un resultado determinado. El mismo código compilado con el compilador de IDL a Java de otro fabricante puede producir un resultado distinto.

El defecto 4178909 de las bibliotecas Java 2D ^TM impide que ciertas aplicaciones se visualicen correctamente cuando se ejecuta el modo de 8 bits. Este problema sólo debe producirse la primera vez que se ejecuta una aplicación después de rearrancar la máquina o en caso de haber definido el modo de visualización de 8 bits.

Hay también algunos defectos relacionados con DirectDraw. Si se encuentra con un problema de DirectDraw, quizá sea conveniente desactivar DirectDraw:

-Dsun.java2d.noddraw=true

Cuando se accede a DirectDraw, algunos controladores de pantalla dan la sensación de que algunas imágenes del monitor, incluidas las ventanas, se están resincronizando o están saltando. En este caso, busque en la sede web del fabricante un controlador más nuevo para resolver el problema.

La plataforma Java no admite pantallas de 16 colores. Si tiene problemas al dibujar gráficos y componentes de la interfaz gráfica de usuario en una pantalla de 16 colores, intente cambiar la profundidad de color a 256 colores o más.

Las siguientes características están implementadas y son funcionales, pero no se han comprobado totalmente y no se admiten en esta versión.

• Transferencias de arrastrar y soltar de:
  • Tipos de datos nativos de la plataforma y/o definidos por el usuario
  • Instancias de clases arbitrarias, cargadas por instancias distintas de ClassLoader, dentro de la misma máquina virtual Java (JVM*)
  • Objetos Java serializados entre máquinas virtuales Java (o ClassLoaders)
• Enlace de subinterfaces RMI java.rmi.Remote entre máquinas virtuales Java

Los componentes AWT y Swing tienen clases internas que implementan la API de accesibilidad de Java y proporcionan la admisión de accesibilidad apropiada para los componentes. Sin embargo, dicha admisión de accesibilidad no está completamente implementada en esta versión para las siguientes clases AWT:

java.awt.TextComponent 
java.awt.Menu 
java.awt.MenuItem 
java.awt.List

La admisión completa de accesibilidad para todos los componentes se implementará en una versión posterior de la plataforma Java 2.

Los comentarios siguientes hacen referencia a las funciones AWT y Swing de esta versión.

• Un programa que llame al método estático Toolkit.getDefaultToolkit no finalizará y volverá al indicador de comandos. Los informes de defectos 4030718 y 4403762 hacen un seguimiento de este problema, que se solucionará en la versión Beta de J2SDK 1.4.0.

  Solución alternativa - Llame a System.exit() cuando la aplicación haya terminado.

• El nuevo método Component.getListeners() no puede devolver PropertyChangeListeners. Si ha agregado un oyente con addPropertyChangeListener(),

  myComponent.getListeners(PropertyChangeListener.class)
  

  devolverá una matriz vacía.

• El defecto 4199374 hace referencia a un problema de gestión de enfoque con los objetos JWindow. En concreto, este defecto impide que Component.requestFocus() enfoque los componentes de JWindow. Este defecto se solucionó en las versiones de actualización J2SDK 1.2.2_05 y J2SDK 1.3.0_02, pero no se ha solucionado en J2SDK 1.3.1.

En Windows NT, el puente JDBC 2.0 admite el gestor de controladores y los controladores ODBC 2.x y ODBC 3.x. El puente JDBC 2.0 se ha comprobado únicamente con un gestor de controladores ODBC 3.x y con controladores ODBC 2.x y 3.x.

Merant recomienda que se utilice el puente JDBC 2.0 con la versión 3.5 o superior de los controladores ODBC DataDirect de Merant.

Esta versión incluye las siguientes cuestiones relacionadas con la seguridad.

La herramienta de firma de Jar puede verificar archivos firmados por Netscape SignTool 1.3, si los certificados de firma codificada no están autofirmados. Nota: se pueden obtener certificados oficiales Netscape de firma codificada en VeriSign^TM. VeriSign emite estos certificados. No están autofirmados.

Netscape SignTool 1.3 no inserta certificados en el archivo de firma, si el certificado de firma codificada está autofirmado y la herramienta de firma de Jar no puede verificar un archivo Jar firmado si el archivo de firma no contiene el certificado del firmante. Nota: el certificado de firma codificada generado por la propia utilidad SignTool 1.3 es únicamente para efectuar pruebas y está autofirmado. El hecho de que la herramienta de firma de Jar no pueda verificar un archivo Jar firmado por Netscape SignTool 1.3, si el certificado de firma codificada es un certificado de prueba autofirmado, todavía es una cuestión pendiente de revisión.

En Java 2 SDK, las clases de aplicación se cargan mediante una instancia de ClassLoader. Esto hace posible que dichas clases utilicen las extensiones instaladas y, al mismo tiempo, separa la ruta de las clases de aplicación, especificada por el usuario, de la ruta de la clase de rutina de carga, que es fija y normalmente no debería ser modificada por el usuario. La opción -Xbootclasspath se puede utilizar para anular la ruta de la clase de rutina de carga, si es necesario.

Sin embargo, esto significa que, en Java 2 SDK, las clases de aplicación ya no tienen todos los permisos de forma predeterminada, sino que se les conceden permisos en función de la política de seguridad configurada en el sistema. Esto puede provocar que algunas aplicaciones que escriben su propio código de seguridad basándose en el modelo de seguridad original de las versiones 1.0/1.1, generen una excepción y no puedan iniciarse en Java 2 SDK. Una solución alternativa es ejecutar estas aplicaciones con el lanzador de aplicaciones oldjava , que está documentado en la página de referencia del lanzador de aplicaciones java.

En las siguientes notas se resumen las cuestiones relativas a la política de seguridad y de las firmas.

• La implementación de la política de seguridad predeterminada utilizada por la plataforma Java 2 está especificada en la propiedad policy.provider del archivo de propiedades de seguridad de Java, jre/lib/security/java.security. Si se especifica una implementación de la política de seguridad que no sea la predeterminada, se debe situar el nuevo archivo de propiedades de seguridad no predeterminado en bootclasspath. Para esto utilice la opción -Xbootclasspath de la línea de comandos. Si desea obtener más información acerca de esta opción, consulte la página de referencia del cargador de la aplicación Java. Esto hará que el cargador de la clase de rutina de carga cargue el archivo de política. Si el nuevo archivo de política predeterminado está en otra ubicación, como en la ruta de clases o en una extensión, no se recogerá y se utilizará en su lugar la política predeterminada que proporciona sun.security.provider.PolicyFile .

• A partir de la versión 1.2.2, Java 2 SDK utiliza un nuevo mecanismo de carga de clases. Con el nuevo cargador de clases, si un archivo de clases del paquete de un archivo Jar está firmado, todos los archivos de clase que pertenezcan al mismo paquete deberán haber sido firmados por los mismos firmantes. Ya no es posible utilizar un archivo Jar en el que algunas clases de un paquete se han firmado y otras no o han sido firmadas por distintos firmantes. Los archivos Jar aún pueden contener paquetes sin firma. Sin embargo, si algún paquete contiene clases sin firma, todos los archivos de clase de dicho paquete deberán estar firmados por el mismo firmante. Los archivos Jar existentes que no cumplan este criterio no se podrán utilizar en esta versión de la plataforma Java 2.

Actualmente, la herramienta keytool puede importar o imprimir un certificado con codificación Base64 a partir de un archivo sólo si el archivo acaba con un código de línea nueva (salto de línea). Si el archivo de certificado no contiene un salto de línea al final e intenta importarlo o imprimirlo, obtendrá una excepción CertificateException con el mensaje "Unsupported encoding" (codificación no admitida) o un mensaje de defecto de keytool como "Failed to parse input" (no se ha podido analizar la entrada) o "Input not an X.509 certificate" (la entrada no es un certificado X.509).

Si obtiene ese mensaje o excepción, quizá el problema consista en que falta un salto de línea al final del archivo. Un posible motivo es que, a veces, la respuesta de certificado de una entidad certificadora (en respuesta a una solicitud de firma del certificado) no contiene un salto de línea final.

En UNIX, se puede determinar si un archivo contiene o no un salto de línea final ejecutando el comando siguiente:

    od -xc <nombre_certificado>

donde <nombre_certificado> es el nombre del archivo que contiene el certificado. Por ejemplo, si el archivo se denomina micertif , el comando sería

    od -xc micertif

Si la salida resultante contiene "\n" (sin las comillas) justo al final, es que existe el salto de línea final. En caso contrario, puede agregarlo.

Si no está seguro de si el archivo de certificado contiene un salto de línea final, puede agregar uno como en el párrafo siguiente (los saltos adicionales no afectan) y volver a intentar ejecutar el comando -import o -printcert. Si el comando funciona, el problema era la ausencia del salto de línea. Si sigue apareciendo un defecto, el problema de su certificado es otro.

Para agregar un salto de línea al final de un archivo de certificado con codificación Base64, abra el archivo en cualquier editor de texto, sitúe el cursor al final del archivo y agregue un salto de línea (o retorno de carro), pulsando, por ejemplo, la tecla Intro del teclado.

Conexión en red

Esta versión tiene los siguientes defectos y limitaciones en la API de conexión en red:

• En Windows 2000, las aplicaciones de datagramas pueden recibir una excepción SocketException inesperada que indique que se ha cerrado el zócalo. Esto está relacionado con el nuevo funcionamiento de Windows 2000 cuando la aplicación remota no está disponible. Una solución alternativa es cerrar y volver a crear DatagramSocket. Este problema se ha identificado con el número de defecto 4361783.

• J2SDK 1.3.0 introdujo una implementación de cliente HTTP/1.1. Los servidores web como Apache, devuelven una respuesta codificada y entrecortada a los clientes HTTP 1.1, pero la gestión de la codificación entrecortada de J2SDK 1.3.0 y 1.3.1 no canaliza la respuesta entrecortada del servidor. En la práctica, esto significa que los métodos como java.net.URLConnection.getInputStream no se devuelven hasta que la respuesta del servidor ha finalizado. Este problema se ha identificado con el número de defecto 4333920.
  Solución alternativa: para el navegador de web Apache, la solución alternativa es incluir la línea siguiente en httpd.conf.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

• La especificación de HTML 4.0 recomienda codificar los caracteres que no son ASCII en Identificadores de recursos uniformes (URI) con uno o más bytes UTF-8. Muchas secuencias CGI existentes manejan caracteres que no son ASCII mediante bytes con la codificación con la que se recibe un documento. Sin embargo, las clases URLEncoder y URLDecoder no admiten ninguno de dichos métodos de manejo de caracteres que no son ASCII en URI. En su lugar, dichas clases sustituyen uno o más bytes para los caracteres según se define en la codificación predeterminada de la plataforma subyacente. Este defecto se ha identificado con el número 4257115.

• Una llamada al método HttpURLConnection.getResponseCode del cliente puede provocar que la máquina virtual caiga si se encuentra con Intros adicionales en el campo de cabecera HTTP enviado por un servidor Win98 o WinNT. Este defecto está identificado con el número 4258697.
  Solución alternativa: el defecto de desbordamiento de pila se puede evitar si se configura el servidor http para que envíe un respuesta a HTTP 1.0. En el caso de Apache, se debe incluir la siguiente línea en httpd.conf.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

Si la aplicación utiliza las clases de conexión en red, es posible que no se ejecute con fiabilidad en Winsock 1.1. Si la aplicación de red debe admitir Windows 95, que incluye Winsock 1.1, es conveniente que los usuarios de la misma dispongan de Winsock 2.0 (Windows NT 4.0, Windows 2000, Windows ME y Windows 98 incluyen Winsock 2.0). Se puede descargar Winsock 2.0 en la siguiente dirección:

http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/

El URL siguiente contiene información sobre la forma de determinar si los componentes de Winsock 2.0 están instalados en una plataforma Windows 95:

http://support.microsoft.com/support/kb/articles/Q177/7/19.asp

Sin la actualización de Winsock, es posible que se produzca una caída del sistema InetAddress.getByName en kernel32.dll si fracasa la búsqueda de un nombre. Si desea obtener más información acerca de este defecto, consulte la sede web de Microsoft.

http://support.microsoft.com/support/kb/articles/Q176/3/54.ASP

Componente Java^TM Plug-in

Las notas siguientes pertenecen al componente Java Plug-in de esta versión.

• En plataformas Linux, no se pueden imprimir copias múltiples de un applet desde el navegador web. Se debe cerrar y reiniciar el navegador cada vez que se realice una impresión. Este problema se ha detectado como defecto número 4450194.

• Cuando se instala una ampliación con el componente Java Plug-in, aparece un cuadro de diálogo que advierte al usuario al respecto. Si el usuario hace clic en el botón "Deny" (Denegar), puede que el cuadro de diálogo vuelva a aparecer solicitando al usuario que acepte o rechace la instalación de la misma ampliación. Este defecto ya no existirá en una versión próxima.

• En la versión 1.3.0_01, la verificación de la firma se cambió y se usaba el almacén cert que se incluye con Sun Java Runtime Enviroment en lugar del almacén que se incluye en Microsoft Internet Explorer. Este cambio se efectuó porque el uso del almacén cert en Internet Explorer no funciona con los applets que se ejecutan en navegadores de web Netscape. En la versión 1.3.1 se han introducido códigos adicionales de manejo de errores que permiten trabajar con firmas que no se pueden verificar. Consulte el informe de defectos 4424604.

Notas de adaptación al entorno

Si desea obtener información general acerca de la compatibilidad de los entornos nacionales de esta versión consulte el apartado sobre Notas de adaptación al entorno.

Documentación

Los comentarios siguientes están relacionados con la documentación de esta versión.

• Debido al error 4459595, la página Serialized Form de la especificación de la API de esta versión contiene algunos enlaces interrumpidos a archivos de clases privadas y de clases de paquete privadas.

• Consulte el nuevo documento en línea Tuning Garbage Collection with the 1.3 Java Virtual Machine.

Las herramientas no pueden convertir las cadenas PCK en japonés en Solaris 2.6

Al utilizar cadenas en japonés como argumentos del comando java en el entorno nacional de Solaris 2.6 ja_JP.PCK se produce un error. La solución alternativa a este problema es cambiar la línea 89 /usr/java/bin/.java_wrapper

exec $DEBUG_PROG "$prog" $opts "$@"

por

exec $DEBUG_PROG $prog $opts $@

Problemas de texto en chino tradicional

En esta versión, se producen los problemas siguientes con las fuentes del chino tradicional.

• Microsoft Windows 95 para chino tradicional versión 2.0 no contiene las fuentes de chino tradicional especificadas en los archivos de propiedades de fuentes de Java 2 SDK. El uso de Java 2 SDK o del entorno en tiempo de ejecución de Java 2 en dicho sistema operativo puede generar advertencias de "fuente no encontrada" y es posible que el texto no se muestre correctamente. Este problema no se da en la segunda versión de Microsoft Windows 95 para chino tradicional versión 2.0, que es más moderna y se lanzó en octubre de 1996 y que sí que contiene las fuentes especificadas.

• En el entorno de chino tradicional de Microsoft Windows 95, los caracteres chinos no se muestran correctamente en los componentes Swing. Si desea obtener más detalles acerca de este problema, consulte el informe de defectos 4431319 en la sede web de Java Developer Connection ^SM.

En el entorno nacional inglés, los sistemas operativos Windows 2000 Professional, Windows 2000 Server y Windows 2000 Advanced Server admiten la versión 1.3.1 de Java 2 SDK. No se admite la edición DataCenter de Windows 2000. En entornos nacionales no ingleses, sólo se admite la edición profesional de Windows 2000. Los problemas relativos a Windows 2000 son:

• Windows 2000 y soporte de varios monitores: en la plataforma Windows 2000, el uso de varios monitores todavía no es totalmente funcional. En particular, la modalidad de 256 colores sólo funciona correctamente si todos los monitores están configurados a 256 colores. Se recomienda usar la modalidad de color de 16 bits o superior.

• Si aparece el siguiente mensaje de defecto durante la instalación de Windows 2000

     config.nt. The system file is not suitable for running MS-DOS 
     and Microsoft Windows Applications. (El archivo de sistema no es adecuado
     para la ejecución de aplicaciones de MS-DOS y Microsoft Windows).
  

  indica que se ha detectado un problema con el archivo %SystemRoot%\System32\COMMAND.COM en algunas instalaciones de Windows 2000. Si aparece este mensaje de defecto al intentar ejecutar el instalador, consulte la sede web de Microsoft en

  http://support.microsoft.com/support/kb/articles/Q142/2/71.asp

  para obtener información acerca de cómo solucionar el problema.

• Bloqueo del proceso - Una aplicación se puede bloquear debido a un interbloqueo en Ntdll en los sistemas operativos Microsoft Windows 2000 Professional, Server y Advanced Server. Este problema puede ocurrir en las aplicaciones que usan flujos de entrada y de salida de objetos java.lang.Process . Consulte la sede web de servicios de asistencia al cliente de Microsoft si desea obtener más información y una solución:

  http://support.microsoft.com/support/kb/articles/Q271/1/82.ASP

Instalación en Windows NT

Cuando instala la versión 1.3.1 de Java Runtime Environment, el archivo de control ActiveX en C:\Winnt\Archivos de programa Archivos\Java Runtime Environment 1.3.1 presenta el estado "Damaged" (Dañado). Este es un asunto meramente estético y el estado "Dañado" no debería acarrear consecuencias negativas en ninguna situación.

No obstante, hay una solución alternativa en caso de que no se pueda admitir el estado de "Dañado". Vaya a "Inicio -> Ejecutar" y escriba "regedit". Desde las ventanas de regedit, navegue hasta la clave de registro "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation". Haga doble clic en la cadena INF y suprima la cadena resaltada bajo "Value data" (Datos de valor). El archivo de control ActiveX tendrá el estado "Installed" (Instalado).

Copyright © 2001 Sun Microsystems, Inc. Reservados todos los derechos.