La mise à niveau du code compilé Java 7 vers Java 8 présente-t-elle un avantage?

Question

J'ai une vieille demande écrite à l'aide de Java 7. Il fonctionne très bien dans une Java JRE 8. Je n'ai pas de plan sur la réécriture du code pour rendre l'utilisation de Java 8 fonctionnalités. Est-il un avantage technique à la mise à niveau du code compilé la dernière version de Java JDK 8?

Pour être clair, le code est actuellement compilé avec Java 7 et déjà en cours d'exécution avec la dernière version de Java 8 JRE. Il doit déjà bénéficier de l'Java 8 runtime améliorations. Cette question est de savoir si les avantages seraient acquis par la compilation de la version 8 et fonctionne avec Java 8 compilé en byte code.

---

Aussi, je ne suis pas concerné par la non-techniques des avantages tels que la productivité des développeurs. Je pense que ceux qui sont importantes, mais pas au point de cette question. Je vous demande pour l'amour de code de production qui n'a PAS d'équipe de développement. C'est uniquement en mode de maintenance.

Answer 1

Si je comprends correctement à la question, vous voulez savoir si le bytecode produit par javac sera "mieux" dans Java 8 que dans Java 7.

La réponse est probablement non, ils ne cessent de corriger les bugs du compilateur et qui conduit parfois à la plus efficace du bytecode. Mais vous ne voyez pas d'accélération significative de ces correctifs pour Java 8 pour autant que je peux voir, le changelog répertorie uniquement les 2 principaux changements entre les versions.

L'oracle site est terrible et je n'arrive pas à obtenir une liste de corrections de bugs liés à l' javac entre les versions, mais ici est un non exhaustive de OpenJDK. Une majorité de ceux que j'pouvez gérer à trouver sont à la correction des erreurs. Par la mise à jour vers Java 8, il y a une chance il l'habitude de compiler plus en raison de javac plus correctement à la suite de la JLS et il y aura très peu de "améliorations" pour le "bytecode".

Answer 2

Le principal avantage est que Java 8 a les dernières corrections de bugs, où que Java 7 n'est pas d'être publiquement mises à jour.

Aussi, si vous allez exécuter du code sur une Java 8 JVM, vous pouvez aussi bien avoir juste une version de Java installée.

Java 8 pourrait être plus rapide, et il a un meilleur support pour de nouvelles fonctionnalités comme le G1. Toutefois, il pourrait être plus lente pour votre cas d'utilisation, de sorte que le seul moyen de savoir est de tester.

Est-il un avantage technique à la mise à niveau du code compilé la dernière version de Java JDK 8?

Si vous vous demandez si il n'y a aucun avantage à re-compiler Java 7 du code en Java 8 compilateur, la réponse est; presque rien.

La seule différence est qu'il y a eu des différences mineures de l'API Java, alors il pourrait y avoir des différences très subtiles Java 8 compilateur peut trouver que le Java 7

D'autres différences mineures sont le nombre magique au début du fichier, éventuellement, de l'ordre de la constante de la piscine. Le byte-code est fondamentalement la même, même le soutien pour l' invokedynamic qui a été ajouté pour les lambdas existé dans Java 7 mais je n'ai pas utilisé de cette façon.

Answer 3

Il pouvait contribuer à créer la sensibilisation.

Lorsque vous passez à Java8, vous pourriez trouver d'autres mises en garde émises par javac. Exemple: l'inférence de type a été grandement améliorée avec Java8. Et qui pourrait éliminer le besoin de @SuppressWarnings annotations dans votre base de code (et quand ces annotations ne sont plus nécessaires, le compilateur signale que).

Ainsi, même lorsque vous n'avez pas l'intention de modifier votre base de code aujourd'hui, le passage à Java8 pourrais vous parler de telles choses. L'augmentation de votre connaissance peut aider à prendre des décisions éclairées.

Sur l'autre main:

• J'ai vu quelques questions à propos de (rares) des situations où Java8 refusé de compiler Java7 code. Donc, commutation de Java8 porte aussi une (très peu) de risque de courir dans ce genre de problème.
• Et même quand vous n'avez pas l'intention de toucher à votre base de code aujourd'hui, il y a une certaine chance que vous changez d'avis plus tard. Et puis, quand pas attention, vous pourriez exploiter Java8 fonctionnalités. Ce qui pourrait compliquer le champ "mises à jour"; comme vous avez maintenant deux versions de votre code source pour entretenir!
• Ensuite: dans le cas où vous avez des clients exécutant le produit à l'aide d'un java7 jre; vous devez être très prudent sur les binaires de correctifs de vous donner à eux. Nous avons une telle configuration; et j'ai perdu du temps plus d'une fois parce que j'ai accidentellement mis un seul Java8-classe compilée sur un Java7 piloté par un système de test. Qui ne peut tout simplement pas se produire lorsque votre dev et test/réglage client est tous Java7.

Longue histoire courte: il y a quelques subtiles avantages, et certains risques (d'où l'importance des risques dépendent principalement de l'ensemble de votre installation).

Answer 4

Je voudrais le faire pour au moins ces faits.

1) HashMap internes (c'est plus rapide sous jdk-8)

2) Beaucoup de correction de bugs qui pourraient être transparent pour vous (à l'exécution des optimisations) qui permet de rendre votre code plus vite et mieux, sans vous en train de faire quoi que ce soit.

3) G1 Garbage Collector

MODIFIER

À partir d'un point de vue technique, ceci ressemble plus à quelque chose à voir avec l'Avance de Temps de Compilation ou de quelque chose qu'un compilateur pourrait améliorer en analysant le code plus. Comme je sais que de telles choses ne sont pas fait en java 8 compilateur.

À partir d'un développeur point de vue - il y en a beaucoup. L'augmentation de la productivité est le plus important pour moi.

EDIT 2

Je ne vois que deux points qui correspond à votre deuxième question:

–paramètres

afin de préserver la méthode des noms de paramètres.

-profil

Appelé Profil Compact Option pour un encombrement réduit.

Answer 5

Si vous n'avez pas d'autres raisons de recompiler votre application, alors il n'a probablement pas beaucoup de différence, comme indiqué dans la accepté de répondre.

Toutefois, si vous avez à le recompiler même une seule fois, pensez à ceci:

• Code source de votre application est compatible avec Java 7, et le plus probable, 8;
• Dans l'éventualité que le code ne compile pas avec Java 8, il ne sera probablement pas compiler soit avec Java 8 compilateur Java 7 source en mode de compatibilité (-source 7 avec javac);
• Vos développeurs et CI aura besoin pour exécuter les tests unitaires et d'intégration à l'encontre d'un Java 8 de l'exécution pour être aussi proche que possible de l'environnement de production. Les développeurs auront également besoin pour exécuter l'application sur le même Java 8 d'exécution lors de l'exécution à l'échelle locale;
• Il est plus difficile de compiler avec un JDK 7 et de les exécuter avec un JRE 8 (dans le même processus de construction, ou dans le même IDE) que de tout faire avec la même version;
• Il n'y a aucun avantage de l'utilisation de -source 7 au lieu de -source 8 si vous compilez avec un JDK 8 et de votre cible runtime Java 8;
• À l'aide de -source 8 garantit que le développeur est à l'aide de Java 8 (ou version ultérieure) pour la compilation et l'exécution (comme il l'applique -target 8).

En conclusion, ne pas recompiler si vous n'en avez pas besoin. Cependant, à la première occasion, vous devez recompiler (en raison de changements de code), passer à Java 8. Ne prenez pas le risque d'avoir un bug dû à l'inadéquation de l'environnement, et de ne pas restreindre les développeurs sans une bonne raison.