Discussion :

[yildiz-online]

Coté intellij, ça fonctionne plutôt bien avec java 9, la modularité est bien supportée, c'est pas parfait (se mélange parfois un peu les pinceaux entre les modules et les dépendances maven) mais c'est tout à fait utilisable.

L'écosystème maven a un support assez correct aussi, surefire a quelques soucis (mais c'est peut-etre juste JUnit aussi) sinon tout fonctionne.

Reste le support des librairies tierces, ça avance mais il y a encore du boulot.

[bouye]

Que ça soit chez Eclipse ou Intellij le support des modules est bancal est ne suit pas le layout officiel d'un projet modulaire. Netbeans s'en sort mieux sur le papier avec un layout plus standard mais même la dernière bêta d'Apache* a encore des soucis. Dans ce dernier, la gestion des legacy jar est toujours foireuse entraînant exception, erreurs dans l'IDE et surtout des classes not found/not accessible puisque la gestion des noms automatiques des modules, la résolution du modulepath et la résolution du classpath ne fonctionne pas comme sur le papier. Et en plus sur ces deux derniers points c'est un soucis du JDK lui-même (puisque ça le fait aussi en ligne de commande, en JDK 9.0 et 9.0.1, pas encore teste le 9.0.4)

Par contre en restant avec du Java "normal" (cad sans modules) ça va bien mieux. Intellij supporte d'ailleurs très bien le JDK 10 et j'ai pu commencer a taper du code avec des var partout (mais y a pas val bien sur puisque abandonne lors de la rédaction des specs donc faut se taper des final var partout )


* Car Netbeans est en beta permanente depuis 2016. Aucune version stable ne supporte ke JDK 9.

[ben51]

C'est normale que sur le sita java.com c'est toujours le JRE 8 qui est proposé au téléchargement ?

[prikama]

je n'aime plus ces technos qui changent rapidement, genre comme angular chaque deux jours une version, laissez au moins le temps pour les gens pour écrire leurs problèmes dans stackoverflow

[sekaijin]

Vu que SAP ne livre qu'au compte goute les évolution de ses lib

passer de java6 à ja 8 ha non trop tard java 9 ha non trop tard java 10 ha non trop tard java 11

m@rd# la compilation plante avec java 8

il ne reste qu'une solution passer à java 7

je crains que ce rythme ne permette pas de suivre.
Qualifier des centaines de milliers de code tous les six mois est une c@nn#ri# pour ne pas dire plus.

toutes les entreprise n'ont pas des millions d'euro à dépenser pour rien tous les six mois.
si je regarde autour de moi je pense qu'on va droit vers le syndrome windows XP IE6
c'est a dire que le coût de migration trop fréquente ne soit considéré par les instance dirigeant comme inutile et qu'on se retrouve comme avec XP avec de vielle version de Java qui restent en place. et plus le temps passera plus il serra difficile voir coûteux de migrer.

je rappelle que les logiciels développés sont pour des client qui eux n'ont pas d'équipes de développeur et dont les direction ne veulent pas d'une rente à vie pour les SSII .
si donc en tant que dirigeant j'ai le choix entre un soft qu'on me livre et que je peux garder 10ans et un ou tous les 6 mois je doit payer une migration du code le choix va être vite fait.

pour info je viens de migrer en java 7 une application critique (au niveau national) qui était écrite en java 1.4 à la sauce java2 oui java 2. le nombre de dépendance n'existant plus est considérable. comment faire ?
trouver une autre techno et re-développer une partie de l'appli oui tenter de décompiler la dépendance et la porter vers java 7 ?
cela à peine fini java7 n'est plus supporté. java8 et en voit de l'être Java 9 passe comme l'éclair.

Comment suivre le rythme quant une migration prends 1 an alors que les versions sortent tous les 6 mois ?
Comment aujourd'hui puis-je miser sur java 12 vu que java 11 sera obsolète lorsque j'aurais fini la migration ?

à vouloir aller trop vite on va droit sur ce qu'on constate en entreprise avec PHP. 80 à 90 % des appli son en php4 ou 5 alors que php à mis des années avant d'avancer d'une version.

je pense qu'aujourd'hui si je devais avec les effectifs actuels et les difficulté à recruter des profils adéquats migrer l'ensemble des appli java de mon entreprise il me faut environ 10 ans.

oops java 56 n'est pas spécifié zut on sait pas à qui il va resembler.

A+JYT

[adiGuba]

Il n'y a aucun besoin de migrer vers chaque version, et il y aura régulièrement des versions LTS...

=> Si tu as besoin des nouveautés, tu fais vite évoluer tes versions (une tous les 6 mois)
=> Si tu as besoin de stabilité, tu restes sur les versions LTS (une tous les 3 ans) et cela revient au même que précédemment...

[sekaijin]

ce n'est pas une question de fonctionnalités mais une question de sécurité.

la LOI nous oblige à être à jour question sécurité. or java n'est pas compatible avec les anciens code.

un exemple simple une classe datasource compilé avec jdk6 ne compile pas avec le jdk7 pas même avec les option pour produire un code compatible jdk6
alors passer à java 56 on en est loin.

pire le code des appli jse6 ne s'exécutent pas sur java 9 pour certaine même pas sur java 7
il s'agit donc bien d'une course qui vise avant tout à nous forcer à toujours tout réécrire. donc à payer grassement les SSII.

ce n'est rien juste quelque milliard d'euro de vos impôts. je ne suis pas sur que vous soyez d'accord pour doubler le budget des administrations et établissements public parce que l'industrie à décidé de partir dans une rythme de mise à jour qu'in n'a plus de sens.

A+JYT

[tchize_]

la LOI nous oblige à être à jour question sécurité. or java n'est pas compatible avec les anciens code.
un exemple simple une classe datasource compilé avec jdk6 ne compile pas avec le jdk7 pas même avec les option pour produire un code compatible jdk6

Tu confond compilation et exécution. Tu peux toujours compiler le code avec java 6 et le lancer sous java 7.

Pour les méthode manquantes, le seule moyen de compiler contre d'anciennes API, c'est de bien dire au compilateur où sont ces anciennes APIs. Il y a 3 paramètres au compilateur concernant la version: la version cible du binaire, la version source de la grammaire du code et la version de l'api à utiliser:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

javac -source 1.6 -target 1.6 -bootclasspath <chemin vers Java 1.6 JRE>/lib/rt.jar

Ce problème devrait disparaitre avec le temps, avec l'introduction des méthodes par défaut qui devraient faciliter dans le futur ce genre de migration.

En ce qui concerne la sécurité, il y a toujours des patchs de sécurité sur l'open jdk 6. http://mail.openjdk.java.net/piperma...ch/003670.html

Au passage la loi n'oblige nullement d'être à jour (en tout cas pas là où je suis et à priori pas en France non plus), mais bien de mettre en oeuvre ce qui est raisonnable pour protéger les données qui te sont confiées. C'est toujours au final une analyse: risque, impact, coût. Là où je suis pour le moment c'est un peu le mode parano avec les audits etc. Dans d'autres boîtes c'est plsu relax car l'impact de la sécurité est moindre coté conséquences. Pour dire simplement, un serveur de calcul à 5 000 000 € qui traite des données scientifiques, osf un peu qu'il y aie des failles voir que des users partagent leur mot de passe. Un serveur à 2000€ qui gère les paiement des 5000 personnes, ça deviens vachement plus critique

[sekaijin]

Tu confond compilation et exécution. Tu peux toujours compiler le code avec java 6 et le lancer sous java 7.

NON, l'expérience montre que non. La plateforme sur laquelle s'exécute notre cone ne démarre pas. elle plante dès l'initialition. en cause des changement bas niveau dans la JVM en 6 et 7 donc pas 8 nin 9 et encore moins 10.

Quant à la sécurité tu iras dire au service de l'état qui nous auditent tous les ans que non ce n'est pas un problème.
et la paie de 5000 personnes ne concerne que des donnée de faible sensibilité. Chez moi cela concerne des millions de personnes, sans intervention humaine autre que la supervision. quant au données je suis sur que vous et moi préférerions voir nos donnée bancaire dévoilées.


A+JYT

[rawsrc]

à vouloir aller trop vite on va droit sur ce qu'on constate en entreprise avec PHP. 80 à 90 % des appli son en php4 ou 5 alors que php à mis des années avant d'avancer d'une version.

Je suis clairement d'accord avec ton point de vue, la seule différence avec PHP c'est que même les changements majeurs de branche sont bien moins douloureux qu'avec Java.
Avez PHP, la durée de vie d'une branche est de 3 ans et là quand même faut avouer que tu restes assez tranquille.
Par exemple la branche 5.3 est sortie le 30/09/2009 et le support de la dernière ramification (5.6) se termine cette année soit 9 ans de support.
Bon le passage de la 5.x à 7.x est un peu plus compliqué à cause des nombreuses dépréciations. Mais c'est sans commune mesure avec les changement de versions de Java.

[bouye]

Oracle vient de se fendre d'une FAQ a ce sujet : Update and FAQ on the Java SE Release Cadence