Ah Nal,
Je sais que les projets de ta SSII sont encore sous Java 1.6, mais il est temps de migrer: la douzième version du langage libre le plus populaire en entreprise vient de sortir.
Les nouveautés sont peu nombreuses, mais sympathiques.
Expression d'aiguillage
boolean joursOuvrees = switch (jour) {
case LUNDI, MARDI, MERCREDI, JEUDI, VENDREDI -> true;
case SAMEDI, DIMANCHE -> false;
};
Unicode 11
Avec 66 nouveaux emojis 💩 et les nombres mayas pour recalculer la fin du monde.
Attention ça va déprécier chérie
Des classes et méthodes sont retirées pour alléger le JDK. N'oublie pas de rappeler à tes collègues roumains et indiens qu'il serait temps d'arrêter utiliser des classes de com.sun.*.
# Fin de support trop proche pour être intéressante
Posté par bosskev . Évalué à 8.
Dans l'administration où je suis, nos fournisseurs utilisent java 7 voir 8.
Quand on regarde la date de fin de support de la dernière version LTS (Java 11) qui est en septembre 2026, elle fait gagner que 1an par rapport à Java 8.
Je ne pense pas que beaucoup d'entreprise entreprendront un changement de version avec tous les tests que cela implique pour 1 année de support additionnelle.
Il va falloir attendre la prochaine LTS pour avoir le droit à un changement chez les fournisseurs à mon avis.
[^] # Re: Fin de support trop proche pour être intéressante
Posté par steph1978 . Évalué à 1.
Un jour viendra où l'on inventera l'intégration continue, et l'homme reprendra foi dans le logiciel…
# On se rapproche doucement des types sommes
Posté par Ontologia (site web personnel) . Évalué à 1. Dernière modification le 26 mars 2019 à 11:38.
Reste plus qu'a définir des enums embarquant des données, et Java va devenir un vrai langage fonctionnel !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On se rapproche doucement des types sommes
Posté par Nicolas Boulay (site web personnel) . Évalué à 6. Dernière modification le 26 mars 2019 à 11:59.
Attention, le plus important dans les type sum c'est d'avoir un filtrage complet dans le switch, sinon, cela peut devenir très chiant.
"La première sécurité est la liberté"
[^] # Re: On se rapproche doucement des types sommes
Posté par rewind (Mastodon) . Évalué à 5.
Je ne suis pas un javaiste mais à l'époque où j'en faisais encore un peu, ça existait déjà. Voir ce tutoriel et l'exemple des planètes.
[^] # Re: On se rapproche doucement des types sommes
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Ce n'est que de l'héritage de enum. Ce n'est pas pareil que de faire :
type bst_t =
| Leafi Int
| Leafs String
| Node of bst_t * bst_t
"La première sécurité est la liberté"
[^] # Re: On se rapproche doucement des types sommes
Posté par barmic . Évalué à 2.
Alors oui et non. Les enum ne serviront jamais à ça. Les enum sont des singletons ils ne peuvent pas servir à ça.
Par contre les value classes sont dans les cartons et ils auront plusieurs choses : je crois qu'ils ont prévu qu'ils soient immuables, ils pourront être déconstruit et ils n'auront pas l'overhead des objets java classiques ! En terme ils devraient être plus proches des types primitifs que des descendants d'Object. Ça demande du coup à pouvoir gérer la généricité sur les types primitifs.
Bref quelques belles choses en vue (par contre je n'ai pas vu de type algébrique).
Il y a un talk en français de Remi Forax qui parle de tout cela : Pattern Matching en Java 10 (bon il était très optimiste sur la roadmap…)
[^] # Re: On se rapproche doucement des types sommes
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
ça va commencer à être aussi compliqué que du C++, donc…
[^] # Re: On se rapproche doucement des types sommes
Posté par Sufflope (site web personnel) . Évalué à 3.
Cool, dans 10 ans ils auront atteint Scala 2.12 (avec des points-virgules). Bon d'ici là y aura Scala 3 (et qui sait pour le 4) mais bon :-D
[^] # Re: On se rapproche doucement des types sommes
Posté par devnewton 🍺 (site web personnel) . Évalué à 1. Dernière modification le 27 mars 2019 à 15:17.
Scala c'est un peu l'incubateur de fritures de Java.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: On se rapproche doucement des types sommes
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
De ce que je vois des dernières fonctionnalités, j'ai plus l'impression qu'ils lorgnent du côté de Kotlin.
La connaissance libre : https://zestedesavoir.com
# et ça marche ?
Posté par harlock974 . Évalué à -10.
J'espère que les pavés numériques USB seront enfin utilisable sous java / Linux…
[^] # Re: et ça marche ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Il y a un rapport de bug?
[^] # Re: et ça marche ?
Posté par steph1978 . Évalué à 1.
Faut penser à le brancher.
# JAVA : Oracle fait peur
Posté par Christophe B. (site web personnel) . Évalué à 3.
Avec la politique commerciale d'Oracle j'ai vu des éditeurs et même des clients s'inquièter de l'avenir de Java
Dans le peu que j'utilise openjdk remplace très bien java mais bon c'est juste pour de l'ezinstall et un peu de Elastic search.
Mais qu'en est il du reste et de l'avenir de ce langage ?
[^] # Re: JAVA : Oracle fait peur
Posté par barmic . Évalué à 10.
OpenJDK c'est le java vanilla.
Maintenant oracle-java est une distribution commercial de java et pleins d'acteurs proposent leur distribution de java. RedHat et IBM évidement, mais aussi Google, Amazon et d'autres encore. Ces distributions diffèrent uniquement dans le support commercial qu'elles proposent. Elles ont pour si je ne me trompe pas une durée de support gratuit relativement courte.
Tu as aussi adoptopenjdk qui est une distribution plus communautaire supportée par plusieurs entreprises. J'ai pas regardé la durée de son support.
Bref ce qu'il y a c'est que maintenant OpenJDK est officiellement le seul vrai java et qu'Oracle a réduit la durée de support gratuit. Un tas d'entreprises en profitent pour faire leur propre distribution.
J'ai pas encore compris pourquoi les gens stressent à l'idée d'utiliser une version à jour de java (c'est le cas qui permet de rester dans les supports gratuits). J'ai l'impression que c'est les même qui te disent qu'ils sont encore en Java6 et qu'ils ont planifié le passage à java 7 sorti en 2011 pour l'an prochain, que C++98 c'est pas si mal et qui ne savent pas que C11 et C18 sont sorti depuis. C'est clairement une dette technique que les gens décident soigneusement d'engranger continuellement.
[^] # Re: JAVA : Oracle fait peur
Posté par ckyl . Évalué à 8.
Cette phrase a peu de sens.
Tu gagnes le droit de t’appeler Java si tu passes le TCK qui valide que tu implémentes la spécification correctement. Le TCK est maintenant librement utilisable pour valider les implémentations dérivées d'OpenJDK.
Le fait est que la plupart des offres commerciales récente sont majoritairement des builds d'un tag d'OpenJDK pour occuper le vide laissé par Oracle JDK et essayer de se faire de l'argent gratos. Mais l'écosystème reste bien plus divers que cela.
Par ce que que 99% de la planète utilise Oracle JDK / JRE qui était sous licence BCL, ie. gratos pour utilisation commerciale, ce qui n'est plus le cas.
Par ce que personne ne comprend les licences ni n'a négocié de changement de fournisseur de JDK dans le passé. Ou pire, ils se souviennent des différences notables lors d'un switch Oracle JDK 7 vers OpenJDK 7.
Par ce que la notion de LTS vient ajouter une variable supplémentaire (on a un journal qui nous dit de migrer à Java 12…).
Par ce que l'offre s'est structurée au dernier moment, et même bien après la GA, avec son lot de FUD et de marketing.
Par ce que Java 11 correspond à la première LTS depuis Java 8. Et que les gens sont donc confronté en même temps au changement de stratégie commerciale et engineering d'Oracle et aux changements techniques de Java 9 qui ne sont pas triviaux.
Par ce que la confusion a régné jusqu'au dernier moment sur comment allait évoluer l’écosystème et l'interaction entre ses acteurs. C'est d'ailleurs toujours le cas puisque quasi personne ne contribue à jdk11u alors qu'Oracle faisait un travail de malade de maintenance et de backport auparavant (regarde https://builds.shipilev.net/backports-monitor/ et compare à la branche 8 avant qu'Oracle ne passe la main à RedHat c'est à pleurer).
Pour avoir gérer l'ajout de Java 11 et la bascule vers un JDK 8 encore supporté dans ma boite, il y a quand même un peu de boulot pour ne pas y aller en modo YOLO et un peu de pédagogie à faire. Je reste globalement d'accord avec toi, mais si tu n'as personne en interne qui sait faire ça, on peut comprendre.
Pour ceux qui veulent des infos factuelles, la référence est toujours là: https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo/preview
D'un point de vu technique, l'adoption de 11 dans la plupart des stack standards commence a être relativement peu douloureuse ce qui n'était pas le cas il y a trois ou six mois. Pour les gros écosystèmes, il faudra encore 6 à 12 mois pour que ça arrive.
[^] # Re: JAVA : Oracle fait peur
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
On peut le résumer en une phrase: les gens sont contents avec Java 8, pourquoi s'embêter à migrer?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: JAVA : Oracle fait peur
Posté par Christophe B. (site web personnel) . Évalué à 6.
Et d'une manière générale pourquoi changer une équipe qui gagne ?
Dans le microcosme des ERPs : faire évoluer un produit qui fonctionne bien coute du temps et de l'argent
et moi cela ne me choque pas d'avoir des version qui ont 9 ou 10 ans mais qui sont parfaitement stable et qui font le job alors pourquoi changer si il n'y a pas de gain quelconque ?
Dites les moules pourquoi -3, j'ai pas compris, je transmettais quelque chose de factuel
faut pas dire du mal de Oracle ?
# Java > 1.8
Posté par MTux . Évalué à -2. Dernière modification le 26 mars 2019 à 14:04.
Chez nous on a interdiction d'installer du jre/jdk > 8
Visiblement l'utilisation commerciale n'est plus permise.
On peut mettre de l'OpenJDK mais beaucoup d'applications métier veulent le jre/jdk propriétaire…
Il est surtout temps de migrer vers un autre langage, on est quand même en 2019, ça fait
1915 ans que ce truc aurait du crever.[^] # Re: Java > 1.8
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Quand on code n'importe comment voilà ce qui arrive.
C'est maintenant que Java est devenu un bon langage qu'il faut migrer. L'IT est vraiment une industrie immature…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java > 1.8
Posté par fearan . Évalué à 6.
Yep nous on abandonne c++ alors qu'on allait passer a c++11…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Java > 1.8
Posté par MTux . Évalué à -2. Dernière modification le 26 mars 2019 à 15:00.
Pré requis éditeur, je n'y peux rien (je fais pas de dev).
A l'inverse je pourrais dire que pas mal de développeurs s'en cognent de la prod et ne comprennent pas à quel point une JVM c'est la merde. Ca bouffe un tas de ram puisque tu dois fixer un minimum/maximum, ça log comme ça veut et ça ne respecte pas les logrotate, ça n'accepte pas les signaux d’extinction, etc.
Ah oui et la tendance naturelle à crasher au moindre pépin, par exemple sur un lag de BDD c'est vraiment génial.
C'est vraiment la préhistoire.
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par barmic . Évalué à 5.
C'est AMHA le même problème pour tous les langages qui ont de gros succès depuis le C ou le C++. C'est des langages simples, tu trouve des développeurs par millions. Quand tu as des millions de développeurs ils ne sont pas tous excellents, ils ne codent pas tous dans des boites qui leur permettent de faire de la qualité, là où les gens qui font du julia par exemple ils sont peu nombreux, c'est mécaniquement des gens qui s'y sont intéressés d'eux-même et qui travaillent dans des entreprises qui veulent garder leur développeurs (va trouver un nouveau développeur julia), c'est souvent des structures plus petites qui ne peuvent pas se permettre de rater un projet, etc
[^] # Re: Java > 1.8
Posté par BAud (site web personnel) . Évalué à 5.
des développeurs excellents en java, j'en ai rencontré : je les compte sur les doigts d'une main
sur les +200 que j'ai croisé, je classe le reste dans « alimentaire » : dur de trouver un bon développeur Java… limite c'est plus facile de trouver un bon développeur PHP (malgré le langage :p).
[^] # Re: Java > 1.8
Posté par dyno partouzeur du centre . Évalué à -3.
Le problème de Java, c'est le même que celui de Basic ou de PHP : c'est très accessible au programmeur moyen. On prend un petit jeune fraîchement diplômé en France ou en Inde, et mois plus tard on le vend comme un développeur Java. Et le mec arrive réellement à faire des programmes qui semblent corrects.
Essaie avec du C, c'est pas la même histoire : Segmentation fault et comportements erratiques aléatoires vont vite te rappeler ce que c'est qu'un langage d'homme où quand tu commets une erreur t'as pas une exception "MallocException at line 42 in foo.c" mais un appel à une fonction de la libc qui segfaulte 200 lignes plus loin…
[^] # Re: Java > 1.8
Posté par barmic . Évalué à 4.
Un langage d'homme ?
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Apparemment pour bien programmer en C, il semble nécessaire de taper au clavier non pas avec ses doigts mais avec ses testicules.
Ce qui m'amène deux remarques :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par dyno partouzeur du centre . Évalué à -1.
Faut arrêter de faire les SJW à tout bout de champ en voyant du sexisme là où il n'y en a pas, et de ramener les bites et les couilles dans des sujets où ils n'ont pas leur place.
C'est hommes par opposition à gamins. Pour ceux qui ne le sauraient pas encore, la moitié des hommes sont des femmes.
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
L'opposé de gamin, c'est adulte non ? Quoique quand je vois le comportement de certains « adultes » j'ai un doute (c'est une vérité générale et pas une attaque sur la personne à qui je réponds).
Cela dit, j'aime beaucoup l'image d'un type qui essaierait de programmer en C uniquement à l'aide de ses attributs. Ça doit vite être complexe quand il faut utiliser des combinaisons de touches.
Et douloureux.
Il y a un équivalent du BÉPO optimisé pour couilles ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Le C c'est un peu la Messe en latin de la programmation?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java > 1.8
Posté par Anthony Jaguenaud . Évalué à 1.
Et le java ? La téléréalité ? :-p
---->[]
[^] # Re: Java > 1.8
Posté par Faya . Évalué à 6.
Je jurerais avoir déjà lu cette phrase. Comme quoi, après quelques années et malgré leurs améliorations, tous les langages "phare" reçoivent les mêmes reproches… D'ici 5 ans (je suis large) on lira la même phrase avec JS (ou Python ?) et dans 10 ans ça sera le tour de Go.
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :
PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par Sufflope (site web personnel) . Évalué à 5.
Je suis globalement bien d'accord avec ton commentaire, mais au contraire sur ce point je ne vois pas comment tu peux dire ça. Tu as une tétrachiée de bibliothèques / cadriciels opensource pour faire quasiment tout, des outils de "qualité" en veux-tu en voilà (notamment pour pondre des métriques pour les Enterprise)…
[^] # Re: Java > 1.8
Posté par barmic . Évalué à 3.
C'est pas le cas de PHP ? Les classes de PHP ont beaucoup évoluées avec le temps. Le transtypages de PHP est très subtile.
facebook a trouvé plus facile de réécrire plusieurs le moteur PHP que de réécrire facebook…
Ça c'est une mauvaise connaissance de ta part à mon avis. Outre le fait que le moteur principal soit open source, si on critiquait maven (qui est open source) parce qu'il téléchargeait « la moitié de l'Internet » il n'a jamais téléchargé autre chose que du code open source… Tu as 2 fondations qui ne font que de l'open source et qui hébergent presque que des projets de l'écosystème java (eclipse et apache). Rien que la contribution de Red Hat au monde java open source est assez immense.
[^] # Re: Java > 1.8
Posté par MTux . Évalué à 0.
C'est ultra commun de mettre du Xmx à 4G voire plus sur des applications métier, sous peine de refus de démarrer. Sous PHP aussi il y a une limite de mémoire, mais je n'ai jamais vu une appli utiliser autant de ram…
Si tu essaie de faire tourner un log avec logrotate, la JVM va continuer d'écrire dans l'ancien. Il faut alors confier à java la rotation (ce que je trouve pas pratique et pas normal) et ensuite coder des crons dégueux pour faire des find qui compressent et suppriment les anciens fichiers.
Je ne connais pas tous les middlewares du monde, mais je n'en vois que deux qui font ça: Java et MongoDB. Ce dernier ayant au moins une option pour permettre l'utilisation propre de logrotate.
La seule chose que j'ai à dire face à ça: ça ne le fait pas avec les autres langages. Je pense qu'il existe un historique très important de bidules en PHP, et pourtant ça tourne sur des serveurs beaucoup plus petits, ça ne fait pas crasher Apache (ou php-fpm) au moindre pépin, on y colle du logrotate sans problèmes. Ah oui et ça démarre instantanément, pas comme les JVM/JBoss/Wildfly où tu attends parfois 1 minute que ton appli démarre, génial quand tu veux automatiser et que tu dois coder plein de check à chaque étape de ton playbook pour attendre.
[^] # Re: Java > 1.8
Posté par barmic . Évalué à 6.
log4j et logback peuvent discuter avec syslog, c'est ce que j'utilise perso. Tu as eu un problème avec ? Les 2 se configurent via un fichier que tu peux forcer au démarrage de l'appli.
Pour les temps de démarrage, je n'ai jamais pu le constater sauf en première installation avec un jdk configuré pour utiliser /dev/random à la place de /dev/urandom.
Mais globalement c'est bizarre de voir les gens reprocher tout à la JVM. Les équipes d'Elastic font comment pour sortir elasticsearch ? De la magie noire ?
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Tu n'aimes pas la JVM? Ca tombe bien le futur de Java sera compilé en natif: https://www.graalvm.org/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java > 1.8
Posté par pmoret (site web personnel) . Évalué à 1.
En fait ça s'est déjà fait par le passé par exemple avec GCJ. Après le problème reste (entre autres) le code généré à la volée et autre joyeusetés. Je ne sais pas comment Graal gère ça…
[^] # Re: Java > 1.8
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Il ne gère pas : https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java > 1.8
Posté par barmic . Évalué à 3.
Oracle JDK est une distribution qui est identique à OpenJDK (le monde de JRockit est terminé depuis un certain temps).
[^] # Re: Java > 1.8
Posté par Nibel . Évalué à 2. Dernière modification le 26 mars 2019 à 15:43.
Pas exactement non. Sinon comment expliquer que Minecraft soit plus véloce sous Oracle JDK que sous OpenJDK dans ce cas ?
C'est globalement identique mais Oracle JDK apporte un peu de cosmétique et de nouveaux packages. Et évidemment, la licence n'est pas la même…
A une époque, la JVM n'était pas la même non plus. Je crois que depuis JDK10 elles sont de nouveau identiques (à confirmer, je ne suis pas certain de la version).
Allez, je retourne sur mon JDK6 :D (au passage, j'aime beaucoup l'expression d'aiguillage, je la trouve très sexy en l'état).
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Java > 1.8
Posté par MTux . Évalué à 2.
Source ?
[^] # Re: Java > 1.8
Posté par Nibel . Évalué à 2.
Mon expérience personnelle sur diverses machines, il y a aussi des comparatifs sur YT avec Minecraft OpenJDK vs Oracle JDK qui confirment mes dires :
https://www.youtube.com/watch?v=oXDbuMD6B74
https://www.youtube.com/watch?v=rhEEU4Jn_7Y
Et je vois que Minecraft utilise toujours du JDK 1.8, je pense que la situation n'a pas évolué à ce niveau là.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Java > 1.8
Posté par steph1978 . Évalué à 3.
En admettant que tu n'aimes pas le langage, la technologie VM est très présente.
La JVM est une bonne VM.
Et elle permet énormément de langages : clojure, kotlin, scala, etc.
# Ne pas utiliser en prod...
Posté par ckyl . Évalué à 2.
Heu non, tu ferais bien mieux d'attendre la prochaine LTS.
Personne n'utilise de non LTS en production. Les releases intermédiaires servent juste pour se forcer à faire de petits incréments et à les évaluer les changements. Mais vu que presque personne ne les utilisent la force de la boucle de feedback est limité…
[^] # Re: Ne pas utiliser en prod...
Posté par barmic . Évalué à 2.
Dans ce cas là n'utilise pas non plus Java11 les derniers chiffres que j'ai vu parlaient de moins de 10% d'utilisation. Sauf que le support gratuit de Java8 pour un usage commercial s'est terminé il y a 2 mois.
Elles font quoi les entreprises sérieuses pleines de gens en cravaté qui font des choses sérieuses ?
[^] # Re: Ne pas utiliser en prod...
Posté par Nibel . Évalué à 4. Dernière modification le 26 mars 2019 à 15:47.
Elles sont toujours sous JDK 6/7/8 (enfin je parle pour mon cas).
Nous sommes un gros éditeur logiciel à destination du monde de la finance et on accumule de la dette technique parce que les clients ne font pas évoluer leur infra… Ils sont très frileux à ce niveau-là…
Bon, pour être un peu plus moderne, on migre doucement sous Angular. Mais on livre un binaire compilé en JDK 6/7/8 malgré tout :p.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Ne pas utiliser en prod...
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 26 mars 2019 à 21:41.
ajoute java 1.4.2 à ta liste, j'en ai un sous le coude là… si, si, on est en 2019 :p
par contre, c'est bien d'avoir les commerciaux Oracle :
sérieux, qui a déjà appelé du support à java ?! Weblogic ou WAS, oui éventuellement…
Heureusement que AdoptOpenJDK 8 a peu de régressions sur l'Oracle JDK 8 côté serveur, la migration sera plus simple si jamais il y a une CVE 0-day en avril :-) Dire que Mark Reihnold a lancé ce travail dès le JDK6 et que même avec JDK11 il reste des choses à remplacer : https://adoptopenjdk.net/MigratingtoAdoptOpenJDKfromOracleJava.pdf?variant=openjdk11&jvmVariant=hotspot (coming soon o_O)
Pour le poste de travail, oublier JNLP va être compliqué :/
[^] # Re: Ne pas utiliser en prod...
Posté par ckyl . Évalué à 9.
Ça na rien à voir.
Java 11 est une LTS dont la maintenance est pour le moment annoncée jusqu'à fin 2024.
Java 12 est une release qui ne verra plus aucune mise à jour dans moins de 6 mois. Le jour ou il y a un CVE ouvert et que tu rends compte que tes dépendances t'empêchent de basculer sur la dernière release t'es mort.
L’écosystème a actuellement du mal à suivre ce rythme. Rien que pour Java 11 j'ai du patcher 4 dépendances, dont Maven, pour faire tourner des projets simples 2 mois après la GA… Même si l'écosystème suivait, virtuellement aucune entreprise ayant plus d'une webapp n'arrive à tenir le rythme de tout mettre à jour tous les 6 mois.
Tu n'as jamais eu de support gratuit de Java 8. Tu avais un Oracle JDK 8 sous BCL, permettant une utilisation commerciale gratuite sans support, qui est passée en statut end of public updates il y a deux mois. Il n'y aura donc plus de mise à jour.
Pour les gens utilisant Oracle JDK 8 tu as donc le choix entre garder une version sans mise à jour possible en cas de CVE, prendre un contrat de support ou migrer vers OpenJDK 8 qui n'est pas à équivalence fonctionnelle contrairement à OpenJDK 11 VS Oracle JDK 11. Potentiellement plus problématique donc mais si la plupart des problèmes sont surmontables.
Elles devraient chercher un fournisseur de JDK 11 qui correspond à leur besoin ET chercher un nouveau fournisseur de JDK 8 ou prendre un contrat de support pour les applications impossibles à migrer en Java 11 actuellement.
Migrer sur du 12, ie. non LTS, sauf cas très spécifique, c'est franchement une mauvaise idée.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.