La estrategia que funcionó bien para nosotros es decidir de antemano qué versiones de JRE apoyaremos. Hacemos esto considerando las plataformas en uso por nuestros usuarios, las características específicas de la versión de un JRE particular que nos gustaría usar y las fechas de lanzamiento de las versiones de JRE. Todo esto se realiza en estrecha consulta con nuestro departamento de atención al cliente. (Por supuesto, todo lo demás es igual, preferimos lanzamientos más nuevos, ya que tienden a tener correcciones de errores, optimizaciones, actualizaciones de seguridad, etc.)
Luego, esto se convierte en una aportación a nuestro proceso de control de calidad. Nuestro esfuerzo de prueba debe abarcar todas las versiones del JRE que estamos respaldando.
Finalmente, utilizamos la capacidad de especificar versiones JRE específicas en el archivo JNLP cuando implementamos nuestra aplicación, para garantizar que los clientes que intentan ejecutar nuestra aplicación con una versión no compatible obtengan una experiencia "a prueba de fallas" (con mensaje útil sobre cómo obtener la versión JRE correcta), en lugar de fallas misteriosas en el futuro.
Una cosa que hacemos para minimizar las incompatibilidades es evitar las API no documentadas (sun.misc
, etc.).
La comprobación explícita de la versión actual de JRE desde dentro de su código debe considerarse solo como último recurso para solucionar un error conocido en una versión de JRE en particular. Si ese error se descubre lo suficientemente temprano en el proceso, preferimos simplemente eliminar esa versión de JRE de la lista de versiones admitidas.
He votado para cerrar, pero he hecho clic en la opción incorrecta. Quería votar para enviar esto a Programmers.SE – Jeremy