Java présente son nouveau train de publication: Embarquez-vous?

Depuis le récent lancement de Java 10, Oracle prend une approche plus moderne pour publier les nouvelles versions de la plateforme Java. Plutôt que d’attendre que les logiciels soient prêts, Oracle utilisera un nouveau calendrier de publication, ayant le train comme modèle. Les nouvelles versions seront publiées tous les six mois — peu importe leur contenu. Traditionnellement, Sun Microsystems, et maintenant Oracle, publiaient de nouvelles versions tous les deux à quatre ans. Grâce à ce nouveau modèle de publication, la plateforme Java aura des mises à niveau de quatre à six fois plus souvent. Les changements chez Java s’accélèrent et les organisations doivent être au courant des innovations afin de garder la cadence.

Java est une plateforme stable, éprouvée et mature — pourquoi toute cette innovation ?

Java est une plateforme éprouvée et reconnue pour sa stabilité et sa maturité ; elle est utilisée par toutes sortes d’organisations. Elle domine toujours le domaine du développement de logiciels et se place constamment aux premiers rangs mondiaux des langages et des plateformes de programmation. Elle occupe une place prépondérante dans les secteurs des systèmes d’entreprise, de l’infonuagique et de la téléphonie mobile, pour n’en nommer que quelques-uns. Mais pour répondre aux pressions de l’industrie, elle évolue rapidement.

Rien qu’au cours des dernières années, Java a intégré modularité et sensibilisation aux conteneurs afin d’aider les applications à se distancer des architectures monolithiques. Elle a diminué son empreinte afférente au déploiement en ajoutant des images personnalisées, en réduisant son utilisation de matériel, en améliorant sa technologie de collecte des déchets et en joignant à son langage, un paradigme de programmation fonctionnel. Plus précisément, Java a ajouté le soutien aux quotas, aux limites de mémoire et aux parts d’UCT de Docker. Java 10 a amélioré son intégration Docker. Tous ces éléments ont contribué collectivement à dynamiser cette technologie afin de bâtir des pipelines CI/CD modernes et basées sur les conteneurs. L’image lourde et ennuyante projetée par Java se modernise – elle devient celle d’une plateforme évolutive adoptant les pratiques DevOps et simplifiant les processus de développement et d’innovation CI/CD.

Mes systèmes fonctionnent si bien sur les anciennes versions de Java — pourquoi les mettre à niveau ?

Les anciennes versions sont continuellement améliorées pour réparer les bogues et les failles relatives à la sécurité. Il est important de se tenir à l’affût des mises à niveau — le pire cauchemar des responsables de la sécurité est de découvrir une brèche à l’intérieur d’un système Java non protégé. À tout le moins, les organisations doivent toujours appliquer les correctifs sur les instances de leur plateforme aussitôt que les mises à jour deviennent disponibles, même si elles utilisent d’anciennes versions.

Les entreprises doivent cheminer vers les versions plus récentes, car les plus anciennes obtiendront de moins en moins de soutien. Les versions actuelles, telles que Java 8, 9 et 10, sont corrigées régulièrement et sont disponibles librement. Par contre, les correctifs pour des versions plus anciennes (Java 7) ne sont disponibles que par un soutien payant et il est très difficile de trouver du soutien pour tout ce qui vient avant. Le soutien pour les versions 8 et 9 ne sera disponible librement que jusqu’à la fin de l’année en cours. De nombreuses organisations ont d’importants inventaires déployés sur des instances de plateformes Java (JVM), peut-être même des milliers, et certaines exploitent des versions qui ne peuvent plus obtenir de soutien. Le rythme accéléré des publications et l’augmentation de la modularité ne feront qu’empirer les choses pour les entreprises qui ne sont pas à l’affût.

Si Java est rétrocompatible, pourquoi ne pas simplement transférer mon système directement dans Java 10 ?

Il est vrai que Java est rétrocompatible, il faut cependant être vigilant. Dans ce contexte, la rétrocompatibilité signifie que l’on peut, sur Java 10, exploiter le bytecode[1] généré d’un ancien compilateur. On peut aussi, avec Java 10, recompiler le code source écrit pour d’anciennes versions. Par contre, c’est une opération délicate. Par exemple, les instructions pour le bytecode peuvent changer selon les versions. Les systèmes qui comptent sur les manipulations bytecode deviennent alors rétro-incompatibles sauf s’ils sont mis à niveau manuellement. Des incompatibilités de comportement peuvent aussi survenir lors de l’utilisation de bibliothèques JDK qui ont été compilées par des versions plus anciennes, mais qui sont exploitées sur des versions récentes. En fait, la pile technologique complète doit être évaluée d’un point de vue holistique ; des incompatibilités peuvent se trouver dans les composantes de la pile découlant de dépendances aux systèmes d’exploitation, aux bibliothèques de tiers, aux structures et aux serveurs d’application. Bref, la mise à niveau vers la nouvelle version de Java nécessite une approche méthodologique qui inclut l’évaluation, ainsi que recoder, recompiler, réécrire les scripts et retester. Quelquefois, il faut refaire des portions des systèmes, car il n’y a pas de voie de disponible vers la mise à niveau, à l’intérieur de certaines composantes de la pile technologique.

Pourquoi ne pas acheter le soutien d’Oracle et continuer d’exploiter mes anciennes versions de Java ?

Payer pour du soutien peut s’avérer très coûteux pour les organisations qui possèdent des milliers d’instances de plateformes Java déployées partout sur leur infrastructure. Cela peut être une option valable pour les systèmes de courte durée de vie, mais pour la plupart des systèmes, c’est une approche qui ne fera qu’augmenter la facture pour les mises à niveau. Les entreprises qui choisissent cette voie devront investir du temps et de l’argent et finiront par avoir à faire la mise à niveau lorsque le soutien payant ne sera plus disponible. Il ne faut pas oublier les frais cachés ; au cours de cette période, les coûts associés aux améliorations importantes de langage et de plateforme seront hors portée. En général, mieux vaut investir dans le futur de Java que dans son passé.

Comment les organisations peuvent-elles garder le rythme des versions ?

Il faut tout d’abord avoir des processus en place pour suivre les piles technologiques déployées. Les organisations réduiront le risque d’être obligées de faire de grosses migrations et de mettre à niveau leurs systèmes de façon précipitée. Mieux vaut adopter une approche plus stratégique en augmentant la souplesse technologique de votre organisation pour ainsi garder facilement la cadence des mises à niveau de Java. C’est ici que les principes fondamentaux des pratiques DevOps, incluant les essais continuels, l’intégration et la livraison, jouent un rôle important. Vous penserez plus tôt aux mises à niveau de versions Java, en automatisant votre pipeline pour rebâtir votre pile Java. Des tests seront effectués et les erreurs seront décelées avant qu’elles ne se rendent à votre environnement de mise en œuvre. Exploiter votre application dans un conteneur Docker cataloguera votre environnement et vous permettra d’exploiter différentes versions de Java sur le même matériel. Cela peut faciliter la phase de migration en liant des systèmes précis à des versions Java précises.

Certaines récentes améliorations dans Java 9 et 10 peuvent aussi aider. Par exemple, Java 9 a introduit le concept des images personnalisées de temps d’exécution, dans lesquelles un temps réduit d’exécution Java peut être incorporé et groupé avec l’application dans un fichier exécutable. Le besoin de compter sur une JVM préinstallée dans l’environnement est éliminé et l’empreinte du temps d’exécution de Java est réduite, car les images personnalisées de temps d’exécution n’incluent que les parties qui sont utilisées par votre système. Aussi, Java 10 est sensibilisé à Docker et donc, s’y intègre mieux. Tandis qu’elle continue d’évoluer, nous ne pouvons que nous attendre à encore plus de dynamisme dans ses fonctionnalités.

Au niveau de l’architecture, les microservices font ressortir les architectures modulaires qui facilitent les stratégies de migration à la pièce afin que votre organisation puisse se mettre à niveau au fil du temps sans affecter les autres systèmes dépendants. Aussi, la fonctionnalité JPMS (Java Platform Module System) de Java 9 facilite la modularité qui force les développeurs à s’éloigner des architectures monolithiques.

Ensemble, ces outils et stratégies aident les entreprises à éviter les pièges présentés dans le présent article. Ils rendent aussi disponibles plus tôt les derniers et les meilleurs paradigmes, outils et bibliothèques aux développeurs, ils peuvent ainsi créer de meilleurs logiciels.

Tandis que Java devient plus orientée sur les conteneurs, comprendre comment implémenter Docker et Kubernetes est bénéfique aux équipes de développement qui cherchent à moderniser leur architecture applicative. Pour en apprendre plus, inscrivez-vous dès aujourd’hui à l’un de nos ateliers pratiques ou pour obtenir de l’information, écrivez-vous à info@cloudops.com.

Avec son expertise, CloudOps peut évaluer votre empreinte Java actuelle, établir des stratégies pour la migration et vous apporter un soutien au cours de votre utilisation des toutes dernières et des meilleures fonctionnalités de Java 8, 9 et 10.

Nick Maiorano

Nick Maiorano est un architecte de logiciel possédant plus de 25 ans d’expérience dans la création de logiciels. Il est auteur de livres et de vidéos et il donne des conférences et des formations sur Java et sur les technologies reliées. Il a été consultant pour une panoplie de sociétés allant d’entreprises en démarrage à de grandes multinationales ; dans divers domaines tels que les communications, les finances et le secteur manufacturier. Il se concentre dernièrement sur l’aide aux entreprises à tirer profit du nuage grâce aux architectures infonuagiques d’AWS. Nick est collaborateur invité au blogue de CloudOps.