2009-07-27 7 views
5

He recibido apoyo para una aplicación web heredada que está utilizando directamente las clases **. Internal. ** apache xerces dentro de rt.jar. Creo que la historia es que este código (en java1.4) solía usar xerces explícitamente y en algún momento cuando se movía a java5 el uso del jar xerces se descartaba y esas clases se referenciaban fuera de rt.jar como interna equivalentes.¿El contenido de rt.jar cambia a través de diferentes proveedores de JVM?

Estoy tratando de entender cuál será el impacto de ejecutar este proyecto en varios contenedores web (por ejemplo, Websphere versus Tomcat, etc.).

  • ¿El proveedor SUN o JVM/JRE proporciona rt.jar?
  • ¿Los proveedores alternativos siguen utilizando xerces internamente o hay otras implementaciones XML?

En algún momento (si los recursos lo permiten) este código tendrá que cambiarse para usar las API java estándar. Quería saber qué tan grave podría ser este problema.

Gracias, Rob

Respuesta

2

En ninguna parte de la especificación JVM o la especificación del lenguaje Java es la rt.jar siquiera mencionado y todos los *.internal.* paquetes están marcados explícitamente como no forma parte de la API.

Por lo tanto, es seguro asumir que el uso de cualquiera de ellos se relaciona directamente con el vendedor de JVM y la versión de implementación. Los diferentes proveedores no solo pueden usar diferentes analizadores XML, sino que incluso dentro de un proveedor, puede encontrarse fácilmente con un problema cuando cambian el analizador XML, la versión del analizador XML o el paquete en el que se envía el analizador XML.

Todos estos son cambios perfectamente legales, ya que esos paquetes no son API.

Así que, a menos que esté de acuerdo con un conjunto pequeño de JVMs bien conocidas, definitivamente debería usar las API estándar o al menos usar Xerces como dependencias externas y, por lo tanto, de los paquetes normales org.apache.xerces.*.

+0

Solo un comentario de seguimiento rápido sobre el problema anterior: Cuando el código anterior se probó en websphere con una IBM JVM, esas clases, como se esperaba, no se encontraron. Además, después de una búsqueda a través del tiempo de ejecución websphere no se encontró ningún signo de rt.jar. El código se ha vuelto a escribir para usar los paquetes org.apache. ** explícitamente. – RobLucas

Cuestiones relacionadas