son - ¿Cuándo es Java 6 el fin de la vida?(En el contexto de escribir herramientas para desarrolladores)
herramientas de java netbeans (1)
Fondo
Esto no es tan obvio como se podría pensar.
En primer lugar, mientras que Oracle dejó de ofrecer soporte público a Java 6 a partir de febrero de 2013, pero el soporte Premier se extendió hasta diciembre de 2013 y el soporte extendido se extendió hasta diciembre de 2016. Además de eso, hay un apoyo sostenido que podría durar para siempre.
El siguiente gran proveedor de Java, IBM, no parece haber publicado el fin del soporte para Java 6 (¡y aún es compatible con Java 5 hasta septiembre de 2013!)
En tercer lugar, tenemos a Apple: con el parche actual más reciente en junio de 2013 y como "la compañía no explica sus políticas de soporte en blanco y negro" parece ser la conjetura de cualquiera ... pero si el manejo de Java 5 puede ser usado como base podemos ver otros 18 meses más o menos ... a finales de 2014-ish?
Finalmente tenemos OpenJDK ... Red Hat ha dicho que ahora apoyarán ...
¡Y ni siquiera estoy empezando a considerar las otras implementaciones de JVM, solo las más comunes que se ven en la naturaleza!
Por lo que puedo ver, hasta ahora, siempre que tenga el dinero para pagar Oracle / IBM / Red Hat, puede continuar obteniendo una versión de Java 6 que se admite de forma indefinida ...
Tal vez podamos comenzar a encuadrar esta pregunta un poco mejor y tener la oportunidad de obtener una respuesta no indefinida:
Si ya no puede comprar el hardware / sistema operativo en el que se ejecuta la JVM específica, entonces la JVM específica que sigue siendo compatible es un poco discutible. Los contratos de soporte extendido son para clientes existentes, quienes probablemente satisfagan sus necesidades existentes con sus sistemas existentes ... y si no pueden cambiar a uno más nuevo
Esto realmente nos da algo de contexto en Apple ... ya que el hardware de Apple es compatible durante 5 años (7 si es en California), entonces el único hardware de Apple compatible debe ser hardware basado en x86, ya que el cambio se completó en diciembre de 2006 (siendo el último PPC Hardware de Apple para el envío) , por lo que en realidad no tenemos que preocuparnos por las versiones de Apple Java que se ejecutan en PPC, ya que
Del mismo modo, probablemente podamos descartar cualquier versión de Java que se ejecute en versiones anteriores de Windows. Lo que significa que vendrá en abril de 2014, si el instalador de Java no se ejecuta en Windows 7+, ¿podemos ignorar efectivamente la versión de Java que se admite en Windows XP?
Mi interés real es cuando las herramientas para desarrolladores pueden avanzar su versión de Java mínima.
Jenkins ha mantenido el soporte con Java 5 durante algún tiempo, pero los cambios más recientes significan que 1.520+ requiere Java 6 o más nuevo en el maestro y en los esclavos. Esto puede causar problemas si algunos de los esclavos de compilación, por ejemplo, el hardware heredado, no pueden ejecutar JVM más recientes.
Maven ha tenido una larga historia de permitirle un JVM a J2SE 1.3 para ejecutar pruebas unitarias, pero a partir de Surefire 2.15 solo será compatible con la ejecución de pruebas unitarias en Java 5.
javac se está moviendo a una política de 1 y 3 en términos de
-sourcey-source... así que tendremos que esperar hasta JDK 10 antes de que Java 6-sourcede-sourcecompatible con el archivo fuente Java ... con una cadencia de lanzamiento de 2 años y Java 8 programado para el lanzamiento a principios de 2014, implicaría que JDK9 a principios de 2016 y JDK10 a principios de 2018 ... pero JDK9 estaría disponible con mantenimiento público durante otros 3 años, lo que significa que en algún momento de 2019 es cuando la compatibilidad con el código fuente de JDK 6 podría dejarse caer
Pregunta
¿Existe una fecha clara que se pueda usar para establecer cuándo las cadenas de herramientas para desarrolladores de OSS pueden abandonar el soporte para las JVM anteriores a Java 7, y cuál es esa fecha?
La distinción de OSS es importante ya que los desarrolladores de OSS generalmente no cuentan con fondos para comprar contratos de soporte de tipo extendido / premium / sostenido y es muy probable que no tengan acceso a hardware oscuro / mainframe.
Actualización: Por "eliminar el soporte para JVM pre-Java 7" quiero decir que sería seguro compilar toda la cadena de herramientas con -target 7 es decir, que el código de bytes requiere Java 7 para ejecutarse.
Actualización 2: Esto debería, como se enmarca, ser una pregunta respondible basada en hechos. La respuesta correcta debe ser cualquiera de la forma
No hay una respuesta clara, aquí hay un enlace a "algunas personas que proporcionan actualizaciones gratuitas para las personas de OSS en Java 6" y no han dicho cuándo se detendrán todavía.
o
Sí, hay una fecha definitiva de YYYY-MM-DD y aquí está la evidencia
¿Existe una fecha clara que se pueda usar para establecer cuándo las cadenas de herramientas para desarrolladores de OSS pueden abandonar el soporte para las JVM anteriores a Java 7, y cuál es esa fecha?
No. No hay tal fecha.
Las personas que desarrollan cadenas de herramientas son libres de abandonar el soporte para las versiones EOL de Java cuando lo deseen ... o no. Hipotéticamente, si los individuos (o compañías) han entrado en acuerdos contractuales con otras compañías (por ejemplo, clientes) para brindar apoyo durante un período determinado, entonces esos acuerdos obviamente los restringirán. Sin embargo, es poco probable que eso limite el proyecto en su totalidad.
(Sin embargo, lo práctico es que mantener el soporte para versiones anteriores de Java se hace cada vez más difícil de mantener. Los desarrolladores quieren / necesitan poder usar las nuevas funciones de Java en la base de código de la cadena de herramientas. Por lo tanto, es probable que vea casos en los que puede use la cadena de herramientas para desarrollar código para Java heredado, pero debe ejecutar la cadena de herramientas en la Java moderna.)
En el caso de las versiones OSS del código base de Java, usted (el usuario de Java) está en una mejor posición:
Es probable que haya un cierto nivel de apoyo / desarrollo comunitario más allá del punto en el que sería comercialmente viable hacer esto.
Y si no, tiene acceso al código fuente para que pueda (en teoría) mantenerse a sí mismo o pagarle a alguien más para que lo haga por usted.
Steve Conolly comentó:
La comunidad OSS no puede celebrar contratos de soporte.
Eso está completamente mal.
Cualquier persona en la comunidad OSS puede celebrar un contrato con usted para proporcionar soporte para un producto OSS. Así es como algunos desarrolladores ganan el dinero que les permite seguir desarrollando sus cosas.
Además, todas las licencias OSS convencionales permiten esto ... incluyendo la GPL y todas sus variantes.
Pero si no es posible que una comunidad OSS crezca desarrolladores porque no puede acceder a la tecnología en absoluto sin incurrir en costos, eso hace que el soporte de pre-java 7 sea imposible.
Eso también está mal.
Sun (anteriormente) y ahora Oracle ofrece descargas gratuitas de las versiones EOL''d de las versiones gratuitas de Java ... y se remonta a Java 1.1. EOL-ing no cambia la disponibilidad. En realidad, se trata de la disponibilidad de versiones de parches de versiones antiguas de Java para problemas de seguridad recientemente descubiertos y otros errores. Tienes que pagar por eso. (Bastante justo. Le cuesta dinero a Oracle hacer el trabajo).
El problema es que Java 5 y versiones anteriores estaban y no están disponibles gratuitamente en forma de código fuente. Eso significa que los clientes no tienen la opción realista de arreglar (digamos) agujeros de seguridad en Java 5. Por el contrario, en Java 6 TIENEN esa opción . El código base de OpenJDK 6 se ha publicado como código abierto, y no puede ser rescindido. Y además, dado que Java 7 y Java 8 también son de código abierto, las personas pueden realizar un seguimiento de las correcciones de seguridad en Java 7 y 8, y tratar de realizar una copia de los cambios en el código base de OpenJDK 6 ...