IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Au revoir Java 7 ! Oracle a officiellement interrompu le support de cette version standard vieille de près de 11 ans.
Désormais, aucune mise à jour ne sera fournie

Le , par Stéphane le calme

12PARTAGES

5  0 
C'est la fin pour Java 7, une version de Java standard vieille de près de 11 ans. Oracle a officiellement interrompu le support étendu de la plateforme fin juillet 2022. Avec l'arrêt du support étendu officiel, Java 7 passe en mode de support de maintien uniquement tel que défini par la politique de support à vie d'Oracle. Aucune autre mise à jour de correctif, aucun bogue ou correctif de sécurité, et aucune implémentation de fonctionnalité ne seront fournis, et seule une assistance limitée sera toujours disponible.

Sorti le 28 juillet 2011, Java 7 avait été la première version majeure de Java en plus de cinq ans et la première sous la juridiction d'Oracle après l'acquisition par Oracle du fondateur de Java Sun Microsystems en 2010. La fin du support étendu signifie certaines anciennes versions d'Oracle Fusion Les produits middleware n'auront plus de kit de développement Java certifié disponible. Les clients pris en charge utilisant Java Standard Edition (SE) 7 sont invités à effectuer une mise à niveau vers une version prise en charge de Java standard, telle que Java SE versions 8 ou 11, selon un bulletin de support Oracle mis à jour pour la dernière fois le 22 juillet.


Dans une étude sur l'écosystème Java publiée en avril par le moniteur d'applications New Relic, la société a indiqué qu'environ 2 % des applications utilisaient encore Java 7 en production. La plupart des applications utilisant Java 7 ou Java 6 étaient des applications héritées qui n'avaient pas été mises à niveau, selon New Relic.

Selon la même étude, en 2020, la grande majorité des applications restaient sur Java 8 (84,48%) même si Java 11 était disponible depuis plus d'un an. Depuis lors, l'équilibre a changé entre ces deux versions LTS. Plus de 48 % des applications utilisent désormais Java 11 en production (contre 11,11 % en 2020), suivi de près par Java 8, capturant 46,45 % des applications utilisant la version en production. Java 17 n'a pas grimpé dans les classements, mais en quelques mois depuis sa sortie, il a déjà dépassé les versions Java 6, Java 10 et Java 16.

Les utilisateurs doivent passer au moins à la version 8

Oracle recommande à ses utilisateurs de passer à une nouvelle version de Java SE prise en charge. Actuellement, la société offre un support pour Java SE 8 et Java SE 11. Les utilisateurs optant pour ces versions bénéficieront d'un support complet pour leur environnement d'exécution Java :

« Le support communautaire prendra fin lorsque Java 7 atteindra la fin de service le 29 juillet 2022. Toutes les applications exécutées sur Java 7 continueront de fonctionner, mais Java 7 lui-même ne recevra pas de mises à jour ni de correctifs de sécurité. Pour minimiser les risques et les vulnérabilités de sécurité potentielles, mettez à niveau vos applications vers Java 8 ou Java 11 en fonction des exigences de votre charge de travail.

« Le guide canonique à suivre est le Oracle JDK Migration Guide. Le guide de migration résout toutes les incompatibilités de spécification Java et les incompatibilités d'implémentation JDK. La plupart de ces incompatibilités sont des cas extrêmes. Vous devriez faire une enquête lorsqu'un avertissement ou une erreur se produit.

« La plupart des applications devraient fonctionner sur Java 8 sans modification. La première chose à essayer est de faire fonctionner votre application sur Java 8 sans recompiler le code. Le but de la simple exécution est de voir quels avertissements et erreurs proviennent de l'exécution. Cette approche permet à une application de s'exécuter plus rapidement sur Java 8 avec le moins d'effort ».

La dernière version de Java, la version 18, ne devrait bénéficier que d'un support de premier niveau avec des mises à jour logicielles essentielles et un service 24h/24 et 7j/7 jusqu'en septembre. Le prédécesseur Java 17 est défini pour plusieurs années de support Premier en tant que version de support à long terme. Oracle a publié une feuille de route des plans de support pour plusieurs versions de Java standard. La prochaine version LTS de Java sera Java 21, attendue pour septembre 2023.


Sources : Oracle (1, 2), étude sur l'écosystème Java

Et vous ?

Avez-vous déjà fait du développement Java ? Si oui, quelle(s) version(s) avez-vous utilisé ?
Quelle version utilisez-vous actuellement ?
Qu'est-ce qui pourrait, selon vous, expliquer que Java 8, sortie en mars 2014, soit utilisé par près de la moitié des applications Java ?

Voir aussi :

JDK 18, l'implémentation de référence de Java 18, est désormais disponible, Elle propose comme Python, Ruby, PHP ou encore Erlang, un mini serveur Web prêt à l'emploi
Java 19 : nouvelles fonctionnalités avec exemples. Elle apporte des méthodes pour créer des HashMaps préalloués

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 01/08/2022 à 14:24
Avez-vous déjà fait du développement Java ? Si oui, quelle(s) version(s) avez-vous utilisé ?
Quelle version utilisez-vous actuellement ?
Qu'est-ce qui pourrait, selon vous, expliquer que Java 8, sortie en mars 2014, soit utilisé par près de la moitié des applications Java ?
Java 8 au boulot, j'ai connu java 7 et vu quelques morceau de code qui date d'avant Java 5 (ex: implémentation des l’internationalisation à la main, vu que ça date e Java 5 apparemment).

Ce qui peut expliquer qu'on coince à Java 8 :
  • Les histoires de licences
  • La stabilité de Java 8 ainsi que l'ensemble de ce qu'on peut faire avec qui fait que nos clients en tout cas ne voient pas forcément d'intérêt à upgrader.
  • La tendance des grandes structures à coincer à une même version de composant jusqu'à temps que ça passe plus.
  • Possiblement la restructuration du JDK en modules
0  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 04/08/2022 à 1:10
Citation Envoyé par walfrat Voir le message
ex: implémentation des l’internationalisation à la main, vu que ça date e Java 5 apparemment.
Locale et ResourceBundle datent du JDK 1.1
Donc probablement plus un développeur qui avait pas la moindre idée de comment faire et a lu ni la doc ni les didacticiels fournis par Sun a l’époque.
J'ai un peu tilté car mes projets Java de DESS a la fac de 98 et 99 supportaient déjà l'internalisation...
0  0 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 04/08/2022 à 11:40
Avez-vous déjà fait du développement Java ? Si oui, quelle(s) version(s) avez-vous utilisé ?
J'en fais depuis 2000, j'ai commencé avec Java 1.1, il y a eu du chemin depuis.

Quelle version utilisez-vous actuellement ?
OpenJDK 11 au boulot, OpenJDK 17 à titre privé.
Je préfère Java 17 qui apporte quelques nouveautés qui m'intéressent par rapport à la version 11, record, switch, pattern matching et accessoirement Stream.toList() ou les nouveaux blocs de texte.
Reste à le faire adopter au boulot...

Qu'est-ce qui pourrait, selon vous, expliquer que Java 8, sortie en mars 2014, soit utilisé par près de la moitié des applications Java ?
Pour ceux qui ont des applications JavaFX, ça paraît normal de vouloir rester sur Java 8 vu qu'après, les bibliothèques liées à JavaFX ne font plus partie de la distribution.
Pour ce qui est de la stabilité, je n'ai pas constaté de différences avec l'OpenJDK 11, donc l'argument ne me semble pas pertinent, mais peut-être que pour certains types d'applications il y a des risques, je fais quasi exclusivement des applications RIA.
0  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 04/08/2022 à 22:55
La mise en place des modules et leur utilisation, soit qu'on utilise des libs anciennes non-modulables, soit que le projet a le même package présent dans plusieurs sous-projets, ainsi que toutes les restrictions qui vont avec quant a l'introspection s’avèrent casse gueule aussi pour des projets pré-existants/legacy.
0  0 
Avatar de lvr
Membre extrêmement actif https://www.developpez.com
Le 13/09/2022 à 10:01
Moi je reste sur Java8 sur certains de mes applications, car des classes internes de Java ont disparu au delà de la (comme les Component.getPeer(), sun.awt.windows.WComponentPeer, dont je me sers pour intégrer des composants LibreOffice Writer dans une GUI Java Swing). Je n'ai pas trouver d'alternatives gratuite et fonctionnant.
Le coût d'identifier une autre approche, de tout réécrire ne me semble pas valoir les bénéfices de passer à OpenJdk 11 ou 17.
0  0