Comment justifier la migration de Java 6 vers Java 7?

Nous migrions de Java 6 vers Java 7 . Le projet est en retard et risque d'être abandonné, auquel cas il continuera d'utiliser Java 6.

Quelles sont les améliorations spécifiques de Java 7 avec lesquelles nous pourrions revenir à notre responsable et le convaincre qu'il est important d'utiliser JDK 7? Vous cherchez des corrections de bugs que je pourrais mettre en évidence dans Oracle Java 7 (par rapport à Java 6). Les correctifs de sécurité, de performances, Java 2D / impression, etc. seront plus vendables dans mon cas. Les correctifs du compilateur, par exemple, ne seront pas très utiles.

[Je passe par de nombreux sites comme le guide d'adoption Oracle , la base de données de bogues, les questions sur Stack Overflow].

Mise à jour: Merci pour les réponses. Nous avons reporté la mise à jour à la prochaine version. Au plus près, nous avons eu la sécurité. Accepter la réponse votée la plus élevée.

Java 6 a atteint EOL en février de cette année et ne recevra plus de mises à jour publiques (y compris la sécurité) à moins que vous n'achetiez un support d'entreprise très coûteux.

Cela devrait être toute la raison nécessaire.

En outre, des preuves accablantes suggèrent que la compatibilité descendante pour les runtimes Java est excellente. Il y a de fortes chances que vous ayez juste à remplacer les installations Java 6 par Java 7 et toutes les applications continueront de fonctionner sans aucun problème. Bien sûr, cela n'est pas garanti et des tests approfondis sont recommandés pour confirmer qu'il n'y aura en effet aucun problème.

En général, il y a un certain nombre de changements assez larges pour faciliter les choses sur le programmeur. Votre gestionnaire ne se soucie peut-être pas trop de ces choses, mais faire en sorte que les programmeurs passent moins de temps à penser au code passe-partout, et ont donc plus de temps pour réfléchir à l'objectif réel de ce qu'ils implémentent, devrait augmenter l'efficacité, réduire les bogues, etc., ce qui peut être un argument très puissant. Oracle a une liste assez complète de changements , mais elle est assez longue, je vais donc résumer autant que possible.

Les fonctionnalités linguistiques incluent:

• Moins de passe-partout sur les génériques. Le code Map<String, String> myMap = new HashMap<String, String>();peut être réduit à Map<String, String> myMap = new HashMap<>(). Le compilateur peut déduire les types génériques nécessaires sur le côté droit à partir de la gauche, de sorte que votre code devient un peu plus court et plus rapide à lire.
• Les chaînes fonctionnent maintenant dans les instructions switch , en utilisant la sémantique de la .equals()méthode au lieu de ==.
• Gestion automatique des ressources à l'aide d'essayer avec des ressources. Cela rend le code plus propre, mais a également un avantage sur le code try / finalement basé sur l'ancien. Si une exception est levée dans l'instruction try, puis une autre est levée lors de la fermeture, le code qui utilise les instructions try / finally traditionnelles perdra complètement l'exception d'origine et ne transmettra que celle qui a été levée dans le bloc finally. Dans une instruction try-with-resources, le runtime supprime l'exception que les appels close () ont lancée et fait remonter l'exception d'origine dans la pile, en supposant que cette exception d'origine est celle qui a causé tous les problèmes dans le premier endroit. De plus, au lieu d'abandonner l'autre exception au garbage collector, cette suppression permet de récupérer les exceptions rapprochées à l'aide de Throwable.getSuppressed.
• Les littéraux numériques peuvent être plus faciles à lire. Tous les littéraux numériques autorisent les soulignements , de sorte que des choses comme int n = 1000000000peuvent être transformées en un texte beaucoup plus lisible int n = 1_000_000_000, qui est beaucoup plus facile à analyser comme étant un milliard, et plus difficile à taper à tort sans le remarquer. De plus, les littéraux binaires sont autorisés dans le formulaire 0b10110101, ce qui rend le code qui fonctionne avec les champs binaires un peu plus agréable à lire.
• La gestion de plusieurs types d'exception dans la même instruction catch peut être effectuée, ce qui réduit la duplication de code et peut éventuellement faciliter la refactorisation plus tard.

Chacun de ces changements est quelque chose que votre gestionnaire ne peut pas directement s'intéresser, mais ils facilitent un peu l'écriture du code correct sans autant d'effort et de réflexion, libérant votre esprit pour se concentrer un peu plus sur la logique réelle que vous essayez à implémenter, et ils facilitent également la lecture du code plus tard, ce qui rend le débogage un peu plus rapide.

Côté API, un certain nombre de mises à jour d'API ont également eu lieu:

• En termes de sécurité , plusieurs méthodes de cryptage ont été ajoutées / déconseillées, car la cryptographie évolue sans cesse.
• Le fichier IO a été modifié, ( ce pourrait être un meilleur lien, cependant ) en ajoutant une meilleure abstraction à plusieurs endroits. Je n'ai pas personnellement plongé dans les nouveaux trucs d'E / S, mais cela ressemble à une refonte très utile, ce qui rend beaucoup plus facile de travailler avec le système de fichiers sans autant de douleur.
• La prise en charge d'Unicode est jusqu'à Unicode 6.0, avec un certain nombre d'autres améliorations d'internationalisation.
• Java2D , que vous avez mentionné dans votre question, a été amélioré. Meilleure prise en charge des polices Linux, meilleur rendu X11 sur les machines modernes et gestion des scripts tibétains.

try-with-resources est une fonctionnalité qui mérite une mise à niveau vers Java 7 pour, toute seule. Les fuites de ressources / fuites de mémoire sont un gros risque dans le développement Java et TWR réduit ce risque de manière significative.

J'ajouterai que la nouvelle abstraction de fichiers NIO.2 et les capacités asynchrones valent également la peine d'être déplacées si votre application dispose de fonctionnalités d'E / S de fichier / réseau.

Il peut y avoir une raison pour laquelle vous ne devriez pas passer à Java 7: si vous devez utiliser la machine virtuelle d'Oracle et que votre logiciel fonctionne sur du matériel intégré ou que vous le distribuerez avec du matériel intégré: Oracle a modifié la licence de JRE afin qu'elle ne soit pas concédée si ci-dessus les conditions sont remplies; vous devrez acheter une licence intégrée Java SE. Voir Que signifie "système à usage général" pour Java SE Embedded?