Quand est Java 6 fin de vie? (Dans le contexte de l'écriture d'outils de développement)
Contexte
Ce n'est pas aussi immédiatement évident à comprendre que vous ne le pensez.
Tout d'abord, alors que Oracle a arrêté la prise en charge publique de Java 6 en février 201 mais avec une prise en charge Premier en décembre 2013 et une prise en charge étendue en décembre 2016, il y a un peu longue. En plus de cela, il y a un soutien continu qui pourrait durer éternellement.
Le prochain grand Java, IBM, ne semble même pas avoir mis fin à la prise en charge de Java 6 (et est supporte toujours Java 5 jusqu'en septembre 2013!)
Troisièmement, nous avons Apple: avec le correctif actuellement le plus récent en juin 2013 et comme "la société ne précise pas ses politiques de support en noir et blanc" il semble que personne ne le devine ... mais si la gestion de Java 5 peut être utilisée comme base, nous verrons peut-être encore 18 mois environ ... fin 2014-ish?
Enfin, nous avons OpenJDK ... qui Red Hat a dit qu'il prend désormais en charge ...
Et je ne commence même pas à considérer les autres implémentations JVM seulement les plus courantes vues dans la nature!
Donc, d'après ce que je peux voir, jusqu'à présent, tant que vous avez de l'argent pour payer Oracle/IBM/Red Hat, vous pouvez continuer à obtenir une version Java 6 qui est prise en charge indéfiniment ...
Peut-être pouvons-nous commencer à formuler un peu mieux cette question et avoir une chance d'obtenir une réponse non indéfinie:
Si vous ne pouvez plus acheter le matériel/système d'exploitation sur lequel la JVM spécifique s'exécute, alors cette JVM spécifique continue d'être prise en charge est un peu discutable. Les contrats de support étendu sont destinés aux clients existants, qui ont plus que probablement leurs besoins existants satisfaits par leurs systèmes existants ... et s'ils ne peuvent pas passer à un plus récent
Cela nous donne en fait un peu de contexte sur Apple ... comme Apple est pris en charge pendant 5 ans (7 en Californie), alors le seul matériel pris en charge Apple le matériel devrait être un matériel basé sur x86 car le changement a été terminé le décembre 2006 (étant le dernier PPC based Apple hardware to ship) , so en réalité, nous n'avons pas à nous soucier de Apple Java versions qui fonctionnent sur PPC, comme
De même, nous pouvons probablement exclure toutes les versions de Java qui s'exécutent sur les anciennes versions de Windows. Ce qui signifie que viennent avril 2014 si le Java le programme d'installation ne fonctionnera pas sur Windows 7+, alors pouvons-nous effectivement ignorer que Java est prise en charge sur Windows XP?
Mon véritable intérêt est de savoir quand les outils de développement peuvent-ils faire progresser leur version minimale Java version.
Jenkins maintient le support avec Java 5 depuis un certain temps, mais des changements plus récents signifient que 1.520 + est requis Java 6 ou plus récent sur le maître et les esclaves. Cela peut entraîner des problèmes si certains des esclaves de construction, par exemple le matériel hérité, ne peuvent pas exécuter des machines virtuelles Java plus récentes.
Maven a une longue histoire de vous laisser bifurquer une JVM vers J2SE 1.3 pour exécuter des tests unitaires, mais à partir de Surefire 2.15 il ne supportera que l'exécution de tests unitaires aussi bas comme Java 5.
javac passe à un 1 et trois en arrière politique en termes de
-sourceet-target... nous devrons donc attendre JDK 10 avant Java 6 le support du fichier source est supprimé de javac ... avec une cadence de sortie de 2 ans et Java 8 dont la sortie est prévue début 2014, cela impliquerait JDK9 début 2016 et JDK10 début 2018 ... mais JDK9 serait disponible avec une maintenance publique pendant encore 3 ans, ce qui signifie qu'en 2019, le code source de JDK 6 la compatibilité pourrait être supprimée.
Question
Existe-t-il une date claire qui peut être utilisée pour déterminer quand les chaînes d'outils de développeur OSS peuvent abandonner la prise en charge des JVM pré-Java 7, et quelle est cette date?
La distinction OSS est importante car les développeurs OSS n'ont généralement pas de financement pour acheter des contrats de support de type étendu/premium/durable et n'ont probablement pas accès à du matériel obscur/mainframe.
Mise à jour: Par "supprimer le support des JVM pré-Java 7", je veux dire qu'il serait sûr de compiler l'ensemble de la chaîne d'outils avec -target 7 c'est-à-dire que le bytecode nécessite Java 7 pour fonctionner.
Mise à jour 2: Cela devrait, tel que formulé, être une question recevable basée sur des faits. La bonne réponse doit être soit du formulaire
Pas de réponse claire, voici un lien vers "certaines personnes qui fournissent des mises à jour gratuites pour les personnes OSS sur Java 6" et elles n'ont pas encore dit quand elles s'arrêteraient.
ou
Oui, il y a une date définitive de AAAA-MM-JJ et voici les preuves
Existe-t-il une date claire qui peut être utilisée pour déterminer quand les chaînes d'outils de développeur OSS peuvent abandonner la prise en charge des JVM pré-Java 7, et quelle est cette date?
Non. Il n'y a pas une telle date.
Les personnes qui développent des chaînes d'outils sont libres de supprimer le support des versions EOL de Java quand elles le souhaitent ... ou pas du tout. En théorie, si des individus (ou des entreprises) ont conclu des accords contractuels avec d'autres entreprises (par exemple, des clients) à fournir un soutien pendant une période donnée, ces accords les limiteraient évidemment, mais il est peu probable que cela limite le projet dans son ensemble.
(Cependant, les aspects pratiques sont que le maintien de la prise en charge des anciennes versions de Java devient de plus en plus difficile à maintenir. Les développeurs veulent/doivent pouvoir utiliser le nouveau Java dans la base de code de la chaîne d'outils. Vous verrez donc probablement des cas où vous pouvez utiliser la chaîne d'outils pour développer du code pour Java hérité, mais vous devez exécuter la chaîne d'outils sur Java moderne.)
Dans le cas des versions OSS de la base de code Java, vous (l'utilisateur de Java) êtes dans une meilleure position:
Il y aura probablement un certain niveau de soutien/développement communautaire bien après le moment où il serait commercialement viable de le faire.
Sinon, vous avez accès au code source afin que vous puissiez (en théorie) subvenir à vos besoins ou payer quelqu'un d'autre pour le faire pour vous.
Steve Conolly a commenté:
La communauté OSS ne peut pas conclure de contrats de support.
C'est complètement faux.
Tout membre de la communauté OSS peut conclure un contrat avec vous pour fournir une assistance pour un produit OSS. C'est en fait ainsi que certains développeurs gagnent l'argent qui leur permet de continuer à développer leurs trucs.
De plus, toutes les licences OSS traditionnelles le permettent ... y compris la GPL et toutes ses variantes.
Mais s'il n'est pas possible pour une communauté OSS de développer des développeurs parce que vous ne pouvez pas accéder à la technologie sans encourir de coûts, cela rend la prise en charge pré-Java 7 impossible.
C'est également faux.
Sun (auparavant) et maintenant Oracle proposent des téléchargements gratuits des versions EOL des versions gratuites de Java ... remontant à Java 1.1 . EOL-ing ne change pas la disponibilité. Il s'agit en fait de la disponibilité des versions de correctif des anciennes versions de Java pour les problèmes de sécurité récemment découverts et d'autres bogues. Vous devez payer pour cela. (Assez juste Cela coûte de l'argent à Oracle pour faire le travail.)
Le problème est que Java 5 et versions antérieures étaient et ne sont pas disponibles gratuitement sous forme de code source. Cela signifie que les clients n'ont pas la possibilité de corriger (par exemple) des failles de sécurité dans Java 5. En revanche, dans Java 6 ils ont cette option. La base de code OpenJDK 6 a été publiée en open source, et cela ne peut pas être annulé. De plus, puisque Java 7 et Java 8 sont également open source, les utilisateurs peuvent suivre les correctifs de sécurité dans = Java 7 et 8, et essayez de porter en arrière les modifications apportées à la base de code OpenJDK 6 ...