Discussion :

[Malick]

Oracle annonce la fin des mises à jour pour Java SE 7 à la fin du mois d'avril 2015
Des améliorations de sécurité pour cette version ne seront plus disponibles

Oracle vient officiellement d'annoncer l'arrêt des mises à jour pour Java SE 7 (Standard Edition) dès la fin du mois d'avril 2015. Via cette information, les utilisateurs sont avertis sur la non-disponibilité des améliorations de sécurité relatives à cette version de Java dans les mois à venir.

Oracle précise dans son communiqué que « les clients qui ont besoin d'un accès continu à des corrections de bogues critiques et des correctifs de sécurité ainsi que d'un entretien général pour Java SE 7 ou des versions plus anciennes peuvent obtenir un soutien long terme. Le processus de migration des utilisateurs de Java 7 à Java 8 via la fonction de mise à jour automatique devrait avoir lieu après la libération de la CPU (Critical Patch Updates) de janvier 2015 ».

Oracle affirme que le téléchargement de Java SE 7 et des versions antérieures préalablement publiées restera toujours possible via l'archive Java sur Oracle Technology Network. Toutefois, il incite les développeurs et utilisateurs à procéder à une mise à jour de leurs versions de Java SE vers des versions plus récentes disponibles afin de continuer à recevoir les améliorations de sécurité et les mises à jour publiques.

Par ailleurs, Eric Maurice explique sur le blog d'Oracle que la dernière mise à jour critique de Java SE 7 disponible en téléchargement public a été libérée mardi dernier et intègre 14 nouveaux correctifs de sécurité parmi les 98 nouveaux correctifs annoncés pour une grande majorité des produits d'Oracle. En effet, les 84 correctifs restants concernent des produits Oracle Database, Oracle Fusion Middleware, et MySQL.

Source : Oracle

Et vous ?

Utilisez-vous encore Java SE 7 ? Que pensez-vous de cette nouvelle ?

[abriotde]

J'ai une application Web Java 6 et je regrette l'utilisation de Java principalement pour la raison que Java évolue vite et n'est que trop peu retro-compatible. Surtout dans le domaine des framework Web. Seul le JSP est utilisable dans le temps...

[redcurve]

J'ai une application Web Java 6 et je regrette l'utilisation de Java principalement pour la raison que Java évolue vite et n'est que trop peu retro-compatible. Surtout dans le domaine des framework Web. Seul le JSP est utilisable dans le temps...

Asp.net est ton amie donc

[Caranille]

Pas mal le coup de l'ASP.NET tu as fait ma journée et presque ma semaine.

Rien que le passage de l'ASP.NET MVC 5 à L'ASP.NET VNext est assez chaotique (même si cela ne sort que dans plusieurs mois)

Pour répondre je penses que toute technologie évolue et que malheureusement il faut s'y faire et si vraiment il faut choisir une technologie mieux vaut faire du Java EE pure et de dépendre du moins de framework possible pour rester compatible (Plus dur à faire qu'à dire)

[dfiad77pro]

Asp.net est ton amie donc

Je ne savais pas qu'ASP était une Fille


Sinon pour Java ce n'est pas un soucis de rétrocompatibilité, mais plutôt de ciblage de la JVM .

Techniquement une application 1.6 tourne sans trop de soucis avec 1.8. ( j'offre le fouet et le gros sel si je dit une connerie )

[Washmid]

Java n'a (en standard) pas besoin de recompilation en ciblant telle ou telle version de la JRE.

Par contre les problèmes arrivent vite avec les framework qui jouent un peu trop avec la JVM et le bytecode, ou les gens qui s'amusent à faire des JRE bidouillés.

.NET, il y a des pages de téléchargement magiques du style : https://www.sqlite.org/download.html

Bref

[Gugelhupf]

Toutes les technologies évoluent, que ce soit Java ou ASP .NET

D'ailleurs la communauté Java pense que la techno évolue plus lentement que les autres, surement à cause de la transition Sun/Oracle mais surtout parce que les spécifications Java sont pris au sérieux, une feature que met en place Oracle est d'abord voté par un groupe de personne et d'entreprise (JCP) avant de passer à l'implémentation de la proposition (JSR). Est-ce que les autres technos y ont droit ? De plus en plus je crois, mais pas sur que ce soit tout à fait comparable.

Parmi toutes les technos que je connais, l'évolution de Java reste l'une des plus rétrocompatible (contre-exemple passage de Python 2 à 3). Depuis Java 6 (époque où je me suis mis à faire du Java), je n'ai pas vu de cas où on pouvait écrire un code de telle manière puis cassage lors d'une montée de version. Après c'est sûr que lorsqu'on touche à des notions choses très avancé comme la gestion des fichiers de policy par exemple, oui il y a des choses qu'on fait autrement, mais parmi tout ceux qui sont ici, qui gère beaucoup les fichiers de policy ? Cela concerne certainement une minorité.

L'exemple des frameworks est plus réaliste pour Java, ces dernières évoluent et cassent la rétrocompatibilité mais c'est peut-être voulu ? (pour le support notamment).

@Caranille
Concernant la spécification des servlets/jsp, c'est sûr que ça ne casse pas avec les versions précédentes et que cela évolue dans le bon sens (surtout avec les annotations, le fichier web.xml devient "presque" facultatif), cependant il n'y a toujours pas d'API standard "orienté objet" pour gérer les formulaires de manière sécurisées (token csrf) je crois et ça c'est pas terrible. Et puis comme la spécification Servlet/JSP reste rétrocompatible, on peut faire beaucoup de choses très moches si on confie la gestion d'un projet Web à un débutant ou quelqu'un de désintéressé (d'où le fait qu'il y ait autant de framework en Java surement).

[CEDRIC_D]

Quid de Java EE 7 ?
Java EE 8 est prévu dans le meilleur des cas pour le troisième trimestre 2016 or Java SE 7 est intégré à Java EE 7 !

[Washmid]

[...] Depuis Java 6 (époque où je me suis mis à faire du Java), je n'ai pas vu de cas où on pouvait écrire un code de telle manière puis cassage lors d'une montée de version. [...].

Non seulement le code, mais également le bytecode compilés avec java 1.1 (ou 1.2 je sais plus lequel des deux) sont utilisables sans problème avec les dernières versions de java. En théorie

[Traroth2]

Quid de Java EE 7 ?
Java EE 8 est prévu dans le meilleur des cas pour le troisième trimestre 2016 or Java SE 7 est intégré à Java EE 7 !

C'est quoi, ta question, au juste ?

La spécification Java EE 7 est sortie en mai 2013. Parmi les serveurs qui implémentent cette version, il y a Glassfish et JBoss Wildfly.

[Traroth2]

J'ai une application Web Java 6 et je regrette l'utilisation de Java principalement pour la raison que Java évolue vite et n'est que trop peu retro-compatible. Surtout dans le domaine des framework Web. Seul le JSP est utilisable dans le temps...

La seule version qui a posé quelques problèmes d'incompatibilité, à ma connaissance, c'est Java 5, à cause de l'ajout d'un mot-clé (enum), ce qui a cassé du code existant. Axis 1.x a été rendu obsolète pour cette raison. Mais si tu as d'autres exemples, je suis impatient de les connaitre.

[LeBressaud]

Donc il n'y aura plus de correctif de sécurité ?

5 ans ça me semble un peu court pour un produit aussi utilisé, c'est pas parce qu'il continue à maintenir un minimum les anciennes versions que ça va ralentir l'évolution de Java.

[adiGuba]

Salut,

La seule version qui a posé quelques problèmes d'incompatibilité, à ma connaissance, c'est Java 5, à cause de l'ajout d'un mot-clé (enum), ce qui a cassé du code existant. Axis 1.x a été rendu obsolète pour cette raison. Mais si tu as d'autres exemples, je suis impatient de les connaitre.

Et encore cela n'a cassé que la rétrocompatibilité des sources, mais pas des binaires.

Toutefois chaque version amène quand même son lot d'incompatibilités (le plus généralement au niveau des sources, parfois au niveau binaire).
Mais c'est généralement des modifications quand même très spécifique et avec peu d'impact pour une application "classique".
Exemple pour Java 8 : http://www.oracle.com/technetwork/ja...e-2156366.html

Donc il n'y aura plus de correctif de sécurité ?

5 ans ça me semble un peu court pour un produit aussi utilisé, c'est pas parce qu'il continue à maintenir un minimum les anciennes versions que ça va ralentir l'évolution de Java.

Il y aura toujours des correctifs de sécurité... mais il faut souscrire au support "premium" pour cela.


a++

[Battant]

Bonjour,
Est-ce que c'est toujours Oracle qui prend la décision d'arrêter le support pour Java comme une autre entreprise le fait ?
Aura qui nous demande de passer à Java 8 mais qu'on est-il d'openjdk, zulu et autre version de Java ' particulièrement celle open source ?
Je me suis intéressé à python Un peu dégoûté par le faite que entreprise qui font des logiciels propriétaires prennent généralement les décisions seul dans leur coin Comme Apple fait par exemple Je t'en les technologies obsolète par la fenêtre . Si on veut prendre une image, avec les logiciels propriétaires, j'ai l'impression que ce sont les entreprises qui ont le volant de la voiture et non pas les utilisateurs. Elle décide de tourner à droite tourner à gauche et les utilisateur n'on qu'a suivre. De plus, il arrive que le logiciel propriétaire soit tu lui parles entreprise qui l'édit. Donc à long terme, à mon avis, utilisation de cette technologie n'est pas sur
Oracle fait-elle la même chose avec ses programmes ?
Merci pour vos renseignements

Salutations

[Traroth2]

Bonjour,
Est-ce que c'est toujours Oracle qui prend la décision d'arrêter le support pour Java comme une autre entreprise le fait ?
Aura qui nous demande de passer à Java 8 mais qu'on est-il d'openjdk, zulu et autre version de Java ' particulièrement celle open source ?
Je me suis intéressé à python Un peu dégoûté par le faite que entreprise qui font des logiciels propriétaires prennent généralement les décisions seul dans leur coin Comme Apple fait par exemple Je t'en les technologies obsolète par la fenêtre . Si on veut prendre une image, avec les logiciels propriétaires, j'ai l'impression que ce sont les entreprises qui ont le volant de la voiture et non pas les utilisateurs. Elle décide de tourner à droite tourner à gauche et les utilisateur n'on qu'a suivre. De plus, il arrive que le logiciel propriétaire soit tu lui parles entreprise qui l'édit. Donc à long terme, à mon avis, utilisation de cette technologie n'est pas sur
Oracle fait-elle la même chose avec ses programmes ?
Merci pour vos renseignements

Salutations

Il faut distinguer la spécification et les implémentations. Là, Oracle met fin aux mises à jour pour son implémentation. Mais si d'autres éditeurs veulent continuer à publier des mises à jour pour leurs propres implémentations, ça n'a rien à voir et c'est tout à fait possible.

Cela dit, les implémentations non-Oracle de Java se font rares. Entre le procès avec Google qui a convaincu la plupart des projets open-source de jeter l'éponge, en commençant par Apache Harmony, IBM qui s'est plus ou moins rallié à la JVM Oracle, Apple qui a refilé à Oracle la JVM Mac et le rachat et JRockit, il ne reste pas grand chose...

[gexian]

En attendant, je note que la nouvelle Debian Jessie reste toujours en openjdk-7 .
Bref, cette fin de vie de Java SE 7 se fait un peu à l'arrache sur les serveurs Linux et les solutions basées sur Java... Le monde java se serait-il habitué à passer 6 ans sans nouvelle ? (troll gratuit)

[Battant]

Bonjour,

Pour avoir java sans passer par oracle, on peut utiliser soit openjdk pour linux soit zulu pour windows, mac et linux

Voici les liens

openjdk :

http://openjdk.java.net/

Zulu :

http://www.azulsystems.com/products/zulu

Que pensez-vous de ces solutions ?

Salutations

[tchize_]

C'est quoi, ta question, au juste ?

La spécification Java EE 7 est sortie en mai 2013. Parmi les serveurs qui implémentent cette version, il y a Glassfish et JBoss Wildfly.

Sa question est légitime. Les specs Java EE sont toujours basée sur une javaSE précise. Changer la javaSE derrière fait qu'on est en dehors de la specs. Ainsi la spec java EE 7 est basée sur java SE 7. Mettre java 8 derrière le serveur jboss / wildfly java 7, c'est sortir de la specs et des conditions de fonctionnement du serveur. Pour beaucoup ce n'est pas un problème, on teste que tout marche et on passe en prod. Pour les très gros trucs, t'as par contre souvent des architecte au dessus qui mettent leur veto... Mais dans ce cas là, on paie le support étendu.

Cependant, il est assez bizarre de concrètement arreter java EE 7 alors que java EE 8 n'est pas pret.

[sekaijin]

Je ne savais pas qu'ASP était une Fille


Sinon pour Java ce n'est pas un soucis de rétrocompatibilité, mais plutôt de ciblage de la JVM .

Techniquement une application 1.6 tourne sans trop de soucis avec 1.8. ( j'offre le fouet et le gros sel si je dit une connerie )

tu peux
mal heureusement bon nombre d'application ne passe pas cap java6 java7
particulièrement celle qui utilise le coeur de java pour utiliser l'isolation et le multi class loader.
étrangement la rétro compatibilité n'est là pas top.

tu me dira qu'il suffit de mettre à jour le conteneur d'application
Mais là c'est l'API de ton conteneur qui change et qui n'est pas nécessairement rétrocompatible.
Donc pas simple.

Sans compter que certains constructeur de machine serveur tardent à fournir des JVM adaptés à leur HARD.
du coup tu dois choisir entre une JVM qui fonctionne avec des perf "normale" mais ancienne ou un eJVM récente mais pas optimisé pour ton HARD.

Non seulement le code, mais également le bytecode compilés avec java 1.1 (ou 1.2 je sais plus lequel des deux) sont utilisables sans problème avec les dernières versions de java. En théorie

c'est le mot

Sa question est légitime. Les specs Java EE sont toujours basée sur une javaSE précise. Changer la javaSE derrière fait qu'on est en dehors de la specs. Ainsi la spec java EE 7 est basée sur java SE 7. Mettre java 8 derrière le serveur jboss / wildfly java 7, c'est sortir de la specs et des conditions de fonctionnement du serveur. Pour beaucoup ce n'est pas un problème, on teste que tout marche et on passe en prod.

pour une PME pourquoi pas mais un SI avec plusieurs milliers d'applications métiers différentes. des millions de cas fonctionnels différents à garantir. le tout sur des tera de données sensibles.

Perso je ne prends pas le risque il y a des vies humaines qui en dépendent.

Pour les très gros trucs, t'as par contre souvent des architecte au dessus qui mettent leur veto... Mais dans ce cas là, on paie le support étendu.

Cependant, il est assez bizarre de concrètement arreter java EE 7 alors que java EE 8 n'est pas pret.

Pas le choix ....

A+JYT