JDK, JRE una compatibilidad JAR

Question

que sé un poco acerca de JDK y JRE fuente y la compatibilidad binaria (por ejemplo this y this), pero no está seguro acerca de la siguiente situación:

Considere Tengo una aplicación que se compila utilizando JDK5 y funciona en JRE6. Utiliza algunas bibliotecas (jarras) que también se compilan utilizando JDK5.

Ahora quiero compilar mi aplicación usando JDK6. ¿Qué nuevos problemas podrían surgir en tiempo de ejecución en tal caso (particularmente, en compatibilidad con los "viejos" tarros)? ¿Debo volver a probar completamente la aplicación (tocar cada biblioteca) o puedo confiar en la compatibilidad prometida con JDK/JRE?

Answer 1

Desarmado ya menos que no haya cambiado su código y agregado nuevas características de Java 6, no debería haber problemas. Con respecto a otros frascos, no debería haber ningún problema. JDK siempre mantiene la compatibilidad con versiones anteriores.

Answer 2

La compatibilidad funciona principalmente. No esperaría que surgiera ningún problema para usted aparte de varias advertencias por ej. no usando genéricos Tal vez algunas API apenas utilizadas estaban en desuso, pero supongo que se dejaron en su lugar, simplemente se marcó como obsoleto.

Inténtelo, si lo compila debería estar bien.

Un aspecto clave del diseño de Java - lamentablemente - es la compatibilidad con versiones anteriores.

Hay muy pocas excepciones en las que la compatibilidad con versiones anteriores no se conservó; lo más destacado de Eclipse sufrió cuando el algoritmo de ordenación cambió de un algoritmo de ordenamiento estable a uno no estable (el orden de los objetos que se clasifican de manera idéntica ya no se conservaba); pero eso nunca fue parte de la especificación de Java, sino un error en Eclipse.

Es desafortunado, porque había unas pocas opciones malas que ahora no se pueden cambiar. Iterator no debería haber tenido una función remove() en la API, Vector no debería haberse sincronizado (resuelto teniendo ArrayList ahora), StringBuffer no debería haberse sincronizado, de ahí StringBuilder. String probablemente debería haber sido una interfaz, no una clase, para permitir, p. Cadenas de 8 bits, cadenas de 32 bits: CharSequence es la mejor interfaz de cadenas, pero hay demasiados métodos que no aceptan CharSequence y requieren devolver String. Observable también debería ser una interfaz: no se puede hacer una subclase observable con esta API. Para nombrar unos pocos. Pero debido a la compatibilidad con versiones anteriores, no se pueden arreglar más hasta que tal vez la modularización JDK (en ese momento, algunos pueden al menos desaparecer en un módulo donotuse ...).

Por supuesto que ya debe tener miles de equipo realiza un test para ayudarle a probar con el nuevo JDK ... :-)

Answer 3

Normalmente no hay problemas si surge si se establece la opción de compilador de JDK6 a use 1.5 compatibilidad de fuente. Sin embargo, a veces esto no siempre es cierto.

Recuerdo una vez cuando compilé el código 1.4 con el compilador 1.5 (usando compatibilidad con 1.4). Las jarras estaban bien (nivel binario 1.4) pero la aplicación se bloqueó debido a una conversión divertida.

Utilizamos un número BigDecimal pasando un entero como argumento al constructor. El 1.4 version tenía solo un constructor desde double pero el 1.5 version tenía ambos, el int y el double constructores. Por lo tanto, al compilar con el compilador 1.4 realizó la conversión automática de int a double, pero con el compilador 1.5 comprobó que el constructor int existía y no se dio cuenta de esa conversión. Luego, al usar el código binario compatible perfecto en 1.4 JRE, el programa se bloqueó con un NoSuchMethodException.

Tengo que admitir que fue un caso extraño, pero es uno de esos casos donde la lógica no funciona. Así que mi consejo es que si planea compilar para versiones anteriores de JRE intente usar la versión de destino JDK siempre que sea posible.