Bizarrement, je me retrouve souvent sur des projets anachroniques pour un prestataire, là en l'occurence Java au sein d'un groupe bancaire (alors que je ne représente que la production du fait de mon affectation actuelle).
Bref sur le contexte personnel, sur lequel j'aurai l'occasion de revenir et parlons de Java ou plutôt d'adoptOpenJDK
Promotion de adoptOpenJDK comme solution groupe
_Rappel_ que les applets sont obsolètes dans les navigateurs et actuellement non disponiblesSi une application reste sur des technologies obsolètes, c'est qu'il n'y a plus de support en réalité : manger tous les midi paraît normal, pourquoi ne pas entretenir les applications apportant de la valeur de la même manière ? C'est la première réponse que je demande et qui détermine mon implication, si non (que j'ai déjà reçu, parfois retourné lorsque cela le méritait avec le budget afférant qui va de soi...)
La directive est claire : promouvoir adoptOpenJDK 11 et _à défaut_ rester sur adoptOpenJDK 8.
Reste à en faire la déclinaison et ça peut bien se passer
L'enjeu étant d'avoir à payer plusieurs millions pour l'infrastructure de virtualisation en place (la licence unitaire a un coût acceptable, multiplié par 2 à 3000 cœurs beaucoup moins).
Normalement : ce paragraphe est synthétique et cadre les enjeux (quelques millions), je détaille ci-dessous comme c'est bien compris et pris en compte (ou pas).
Les points positifs et adjuvants à la démarche
Les contrats incluent une clause demandant adoptOpenJDK et c'est pris en compte par les éditeurs. Si cette clause n'est pas acceptée ou remplie, c'est un critère d'élimination et de résorption du produit de cet éditeur. Au vu des coûts induit, c'est légitime, une refacturation peut être envisagée si l'éditeur souhaite se maintenir sur le marché (ou il prend à sa charge de savoir gérer adoptOpenJDK, ce qui donne confiance dans sa compétence et sa pérennité).Des éditeurs comme webMethods ont choisi zulu et leur support inclut celui de la JVM qui n'apporte pas de coûts supplémentaires, cela est forcément accepté
Pour le cloud, il y a la JVM de AWS, ça répond aussi au sujet.
Lorsque une PIC (Plateforme d'Intégration Continue) est en place, cela facilite la démarche. Du CI/CD (intégration continue / déploiement continu) déjà dans une logique devops est un plus, pas forcément suffisant.
Des structures proposent un socle Debian avec openJDK par défaut dès le dév et la recette : si cela crée un souci,
- cela se voit au plus tôt et côté dev c'est remonté (vu que cela n'arrivera pas en prod')
- en terme de support, ce n'est pas forcément contractualisé explicitement, même si cela va de soi lorsque la cible de la prod' est sur du Debian.
- Une exigence préalable de télécharger la JVM Oracle n'est désormais plus acceptable et ne peut être un axe de contournement de la directive.
Quelques retours mitigés, axes d'amélioration :-)
- adoptOpenJDK 8 ne demande pas trop de boulot mais le passage à JDK 11 entérine l'obsolescence de beaucoup de méthodes avec un coup de développement réel (annoncées depuis 3 versions, nous sommes d'accord ; normalement, un _refactoring_ permet de gérer l'avenir et l'à venir... mais tout le monde n'applique pas les bonnes pratiques de développement, bien documentées depuis la démarche devops apparue depuis ~2010, en visibilité des entreprises, ça remonte à avant vu que j'en ai fait même avant 2003 et que cela fait partie des bonnes pratiques appliquées dans le libre _release early, release often_ :p)
- une facturation des tests de non régression au mieux fantaisiste voire malhonnête (2 j.h effectifs vs 60 j.h présentés, par exemple), sans engagement de mise en conformité par la suite : non accepté, réalisé en interne pour 1 j.h en fait
Quelques anomalies à expliciter
JDK 8 maintenu jusqu'en 2024
JDK 11 maintenu jusqu'en 2023
WTF ?! oui, c'est le discours de Red Hat (mainteneur de JDK8) pas celui d'Oracle, ni d'openJDK : bien sûr que le support va perdurer tant qu'il y a les compétences et c'est cohérent avec le choix de rester sur des versions obsolètes et non maintenues, il n'y a pas plus de risque ; soit ça fonctionnait avant, soit ça continuera à fonctionner (avec pas de mise à jour dans un cas, avec capacité à évoluer dans l'autre cas)
Quelques intégrateurs voire éditeurs proposent de l'ordre de 60 jours de tests de non régression (et passent la prise en compte en évolution), là où 1 ou 2 jours suffisent à faire remonter les warnings concernant des méthodes qui vont passer en obsolescence.
Pour JDK 8, il y a peu de travail, pour JDK 11 c'est l'occasion de rentrer dans la modernité et avoir un produit pérenne (ce que tout client attendrait de son fournisseur, sans que cela lui soit facturé vu que c'est censé être déjà payé...)
L’inacceptable
- « On fait comme avant » o_O « on a toujours fait comme ça », du classique : l'accompagnement au changement ne devrait même pas être nécessaire, même si certains ont besoin d'être pris par la main (leur couper tout budget d'évolution est plus efficace)
- Préférer l'archéologie à l'adoption de technologies innovantes ayant quelques apports : amélioration de performance, correctifs de sécurité, accompagnement du devops dans l'air du temp).
- « Ah mais c'est du java 1.4 sur windows 2003, on ne peut que passer à java 1.7 vu que java 8 ne fonctionne pas sur windows 2003 » (sic) : euh, autant passer sur Linux avec un JDK 11 ; oui, il vous faut une ligne budgétaire :-) La non prise en charge de TLS 1.2 par Java 1.4 aide bien à vous faire prendre en compte certaines des limites de ce raisonnement...
- les développeurs sont sous windows, _donc_ on déploie en prod' sous windows o_O WTF ça doit être le mot multi-plateforme qui n'est pas compris (outre un souci de compétence de part et d'autre, vu que je l'ai entendu d'une entité ayant _technical services_ dans son intitulé : j'ai quelques doutes sur les deux mots depuis...)
Démarche en tant qu'architecte
Tenir la position, obtenir sa prise en compte, gérer les exceptions si engagement de résorption (avec coût + délai)Ne pas prendre de raccourci : c'est JDK 11 et ensuite, pas « ok JDK 8 maintenant », un architecte est embêtant car il ne s'inscrit pas que dans le projet mais dans la durée, nous avons des comptes à rendre à l'exploitation aussi (ce qui inclut nos amis et néanmoins collègues de la sécurité qui essaient de faire prendre en compte le _patch management_ alors que cela devrait aller de soi...
Off-the-topic
J'ai des difficultés à tolérer les mal-comprenants et suis un peu sec dans mes réponses à certaines questions qui pourraient passer pour ingénues. C'est connu et assumé : cela fait partie de la formation (oui, je crois encore que tout un chacun peut s'améliorer).Je confonds JRE et JDK, car cela n'a que peu d'impact au final : même en prod' le JDK est utile pour bénéficier d'outils de diagnostics et la différence entre les deux s'est estompée depuis JDK 6 au moins.
Je ne tire pas à vue sur tout intégrateur, je ne fais que relever les meilleures pratiques à appliquer, forcément les mauvaises auront du mal à trouver une quelconque justification (certains s'y essaient, même sur un malentendu ça ne va pas forcément passer...).
Cela fait plus de 5 ans que j'entends Mark Reihnold en parler (l'architecte de Java dès le début), mais je n'avais pas pris en compte la résistance au changement qu'il a pu rencontrer (notamment face aux éditeurs et intégrateurs). Je comprends mieux les versions LTS auquel j'adhérais auparavant, mais c'est bien tout le cycle qui doit être pris en compte : éditeur + achat + prod
