WordPress: Panneau Java et JVM

WordPress: Panneau Java et JVM

Transcription

Horstmann : Je suis Cay Horstmann. Je suis l’auteur du livre « Core  » qui existe depuis une vingtaine d’années. C’est probablement ce pour quoi je suis le plus connu. C’est ce qui me permet de rester à l’avant-garde de . En ce moment, je travaille sur l’édition 17.

Bordet : Je suis Simone. Je travaille fondamentalement sur le projet Jetty. J’aime pirater les protocoles Web, les composants internes et les performances de la . Je dirige le groupe d’utilisateurs dans ma ville locale, Turin. Nous avons ces interactions avec le panel et , sur les nouveautés et les nouveautés , tous les six mois.

Fonctionnalités à espérer dans la prochaine version de

Ruiz : De quoi devrions-nous rêver dans le prochain ? Ce que vous cherchez avec impatience?

Horstmann : Pour diverses raisons, en tant qu’utilisateur de , en tant qu’auteur de livres, l’une des choses que j’attends vraiment avec impatience, pas dans 17, qui sortira cet automne, mais probablement au cours des trois prochains ans, c’est ce qu’on appelle le Projet Valhalla. Où il va y avoir une grande unification dans la machine virtuelle entre les types et les classes primitifs. Là où cette distinction, vraiment du point de vue du programmeur est assez artificielle, cesse d’exister. Plus que cela, où l’on peut désormais disposer des objets à plat dans la mémoire, sans avoir à avoir ce niveau supplémentaire d’indirection que vous avez actuellement avec chaque pointeur d’objet. Vous pourriez avoir un tableau de 1000 points, et ils sont simplement assis là, XY, XY, XY, dans un seul tableau. Tout cela sera censé être super transparent pour les développeurs. Bien sûr, ce ne sera pas parce qu’il s’appuie sur 25 ans de technologie et qu’il y aura toutes sortes de petits bords tranchants, mais ils travaillent avec diligence pour en éliminer bon nombre. Par exemple, vous pourrez ensuite à un moment donné dans le futur avoir une ArrayList de int, sans avoir à vous soucier de la façon dont cela fonctionne réellement en interne. Cela va grandement nettoyer beaucoup de choses génériques. Si vous pensez en ce moment, où vous avez beaucoup de classes de spécialisation, vous avez un IntStream, un LongStream et un DoubleStream, au lieu d’avoir simplement un flux d’int. C’est quelque chose que j’attends avec impatience. Je pense que tant pour la performance que pour la propreté de la langue, ça va être une énorme avancée.

Bordet : Une chose qui m’a manqué, qui est certes de très bas niveau, c’est la possibilité de faire des champs séparés en mémoire, notamment par exemple pour la mise en file d’attente des trucs, afin de ne pas souffrir de faux partages. Jusqu’à présent, il y a eu un certain nombre d’astuces pour essayer d’y parvenir, mais je pense que si nous pouvons disposer des objets en mémoire, alors je peux simplement disposer un tas de Longs ou autre. Ensuite, faites en sorte que mon espacement soit correctement effectué de manière stable, plutôt que de vous fier aux composants internes ou à la magie de HotSpot.

Horstmann : Ça ne va pas venir, je ne pense pas. C’est tellement contre l’esprit de . Vous allez devoir faire confiance à HotSpot pour faire ces choses.

Bordet : Je sais, mais je ne peux pas créer un tableau de 64 Longs, puis référencer uniquement le premier et ensuite uniquement le dernier.

Horstmann : Vous pouvez le faire. Aujourd’hui, les gens font des choses folles. C’est exactement ce qu’ils feront, puis ils y forceront tout leur stockage, mais ce n’est pas vraiment . Les gens des finances me disent qu’ils doivent le faire parfois, mais ce n’est pas là que ça bouge.

Bordet : Je suis tout à fait d’accord. En fait, j’ai récemment commencé à jouer un peu plus avec des disques dans des classes fermées. Ils sont juste géniaux. Vous codez si bien avec eux que j’ai été surpris. L’effet de surprise est assez bluffant. C’est si facile, si propre. Vous pouvez écrire beaucoup de code en un rien de temps, et le simple fait de le lire prend tout son sens. Il n’y a pas de cachette, très peu de passe-partout. En fait, j’ai été agréablement surpris de ces améliorations.

Le concept d’immuabilité

Horstmann : C’est intéressant que vous disiez cela, car il y a eu des doutes sur l’utilisation des disques. Que tous ceux qui voient des records pour la première fois disent : « C’est génial. Je peux me débarrasser de toutes mes classes de porteurs », tous ces getters et setters, mais pas les setters car les records sont immuables. Tu as dû le faire correctement, parce que tu as dit, c’est ce dont j’ai besoin, donc tu n’avais pas besoin de mutation. L’inquiétude là-bas est que toutes les personnes qui font des trucs Beans, et comme les données des employés, et JPA, qu’elles vont être très déçues quand elles voient qu’en fait, leurs dossiers ne vont pas faire ce que ils voulaient. Bien sûr, ils pourraient réécrire ce code pour qu’il soit modifiable. C’est bien sûr dans cette direction que la plate-forme veut nous conduire. Oui, je pense que les records sont une victoire rapide quand ils fonctionnent.

Il y a eu des recherches par un membre de Google, qui avait une fonctionnalité similaire dans une bibliothèque où ils ont un générateur de code qui crée des choses semblables à des enregistrements. En regardant à quelle fréquence les programmeurs en ont profité, ont-ils dit, les enregistrements sont de l’ordre de grandeur comme enum. Ils avaient un générateur d’énumérations avant l’arrivée des énumérations, et les gens utilisaient un certain pourcentage de cas. Ils ont dit, avec les records, c’est du même ordre de grandeur. Ce sera une fonctionnalité intéressante, mais cela ne changera pas la donne. Lorsque vous l’utilisez, votre code est propre. Vous exprimez ce que vous voulez exprimer, et c’est ce que le langage devrait être.

Bordet : Vous dites que les records étaient en fait générés 10 fois plus que les énumérations ?

Horstmann : Non, à peu près aussi souvent. C’est pourquoi je ne vois pas qu’il va y avoir un grand exode vers les disques. J’ai parlé à quelqu’un qui enseigne cela. Il a dit qu’il pense en fait à enseigner d’abord les disques, puis à donner des cours, parce que les disques, si vous y réfléchissez bien, sont conceptuellement plus simples. Je ne sais pas vraiment à quel point les gens vont se sentir à l’aise de dire que l’encapsulation est un plus. C’est ce qu’il propose.

Ruiz : En fait, j’aime cette idée, parce que vous commencez par le concept d’immuabilité, que si vous postulez plus tard, nous en souffrons, comme appliquer ce concept trop tard, et les problèmes surviennent.

Horstmann : Non, ça pourrait être vrai. Vous avez moins de bagages. Vous enseignez les disques, vous enseignez les méthodes, et ensuite vous entrez dans le public, le privé, alors peut-être qu’il est sur quelque chose.

Bordet : La dissimulation d’informations est la chose. Parce que les enregistrements, en fait, sont conçus de manière à ne cacher aucune information. Ils n’essayent même pas. Ils essaient d’être aussi transparents que possible avec les données qu’ils encapsulent.

8 ou mise à niveau

Juste pour revenir à la première question, « Si vous êtes toujours en 8, pourquoi ne bougez-vous pas ? » Je vois des gens dire que j’aime le numéro 8. C’est évidemment une réponse magique. Ensuite, plus que cela, c’est comme passer à 11, génial, les limitations héritées de notre organisation. Cependant, je voudrais demander à ces personnes qui ont des limitations dans leur organisation, si elles utilisent d’autres bibliothèques. Par exemple, le cas dont je parle toujours lors de la migration hors de 8 est le suivant : utilisez-vous une ancienne version du système d’exploitation ? Cela signifie que vous n’avez pas mis à jour votre système d’exploitation depuis des années. Êtes-vous sur Spring 2, si vous utilisez Spring 2 ? Si vous n’êtes pas sur Spring 2, et que vous êtes sur Spring 5, ou si vous utilisez le dernier patch pour votre système d’exploitation, pourquoi êtes-vous toujours sur 8 ? C’est la réponse que j’aimerais obtenir, car il y a des cas où il faut rester sur 8. Absolument.

Il y a un autre exemple qui dit 8, car AWS l’exige ou ne prend en charge rien d’autre. Pour le support AWS, c’est juste. Je n’ai pas envie de juger là-dessus dans le sens où je ne connais pas assez la plate-forme AWS pour dire pourquoi elle ne prend pas en charge 11, ou même des versions plus récentes. Le point clé pour moi est que 17 va durer du point de vue OpenJDK, six mois, comme toute autre version. L’étiquette de support à long terme n’appartient pas à OpenJDK, elle appartient à un fournisseur qui le dit. Fondamentalement, 17 n’est pas différent de 16, du point de vue du OpenJDK. Il est aussi stable que n’importe quelle autre version.

Horstmann : C’est en fait quelque chose qui me préoccupe toujours un peu. Je pense qu’Oracle n’a pas fait un excellent travail avec la messagerie. Il y a eu juste une discussion de Mark Reinhold, il a dit: « Oui, mettez simplement tout ce que vous voulez dans 17. » Je pense que c’est une erreur. Si 17 obtient un tas de choses expérimentales, alors que va-t-il se passer après six mois ? J’ai posé cette question, et on m’a dit, oui, ils allaient les geler à cet état expérimental pendant trois ans, cinq ans, quelle que soit la durée d’un LTS. Je pense que cette chose doit être un peu repensée. Je pense que certains des fournisseurs seraient sages de dire, bien sûr, qu’ils supprimeraient simplement les éléments expérimentaux après six mois ou autre. C’est une complexité. Nous comptons sur ces fournisseurs. Je suis content qu’ils soient nombreux maintenant. Au début, il semblait que ce n’était peut-être qu’Oracle et un autre. Maintenant, nous avons l’embarras de la richesse là-bas, des fournisseurs qui sont prêts à prendre en charge ces versions pendant longtemps, et souvent sans frais, et pendant plus de trois ans. On ne peut pas se plaindre là-bas. Le processus, on pourrait penser qu’après toutes ces années, devrait être fluide, mais je pense qu’il pourrait être mieux défini. Je pense que nous avons besoin des versions LTS.

Bordet : Au niveau OpenJDK, plutôt qu’au niveau du fournisseur.

Horstmann : Ce serait mieux s’il y avait une reconnaissance au niveau OpenJDK, à mon avis, que ceux-ci devraient être qualitativement différents. En ce moment, ce n’est pas le cas. Nous allons devoir voir ce que font les différents fournisseurs pour mieux comprendre cela. Nous n’avons jamais vraiment été dans cette situation auparavant. Maintenant avec 11, ok. 17 est le premier qui entre dans ce train rapide. Ce que j’aimerais voir, c’est une version LTS de 17 moins les fonctionnalités expérimentales. Je ne pense pas qu’il y ait quoi que ce soit qui empêcherait un fournisseur de faire cela, car il me semblait fou de rétroporter pendant trois ou cinq ans dans quelque chose que personne n’utilise. Cela n’intéresse personne. Si j’étais roi, je dirais 5 fois sur 6, Oracle peut mettre ce qu’il veut. Les 6 fois sur 6, ils devraient penser à la stabilité.

Bordet : C’est juste. C’est peut-être une proposition qui peut être tentée et voir, est-ce que cela s’appliquerait ? Cela ne semble pas trop hors du monde.

Ruiz : Si vous voulez vraiment des retours, cela peut arriver dans différentes versions, pas précisément dans une LTS. Je suis avec toi là-bas. Parce que le tout est de le geler pour avoir un support à long terme. Vous ne voulez pas avoir des choses à essayer là-bas.

Bordet : Même si c’est le processus habituel où, par exemple, nous sommes tombés sur un bogue MethodHandle qui a été introduit dans 14, et qui a cassé un certain nombre de tests que nous avions dans Jetty pour implémenter WebSocket. Le bogue a été corrigé dans 16. Il a fallu deux versions majeures de pour être corrigé. Ce n’était pas un bug facile. Nous l’avons signalé, puis ils ont travaillé dessus. Cela n’a pas été corrigé et ils ont dû passer par un long processus d’évaluation du bogue et de trouver la bonne solution. Cela a pris un an. En ce moment, nous avons des tests qui sont désactivés. Et si quelque chose comme ça se produisait dans 17 ? Cela peut arriver, mais c’est une raison de plus pour moi d’essayer de rester à jour, autant que possible.

Horstmann : Totalement. Tout peut arriver. Bien sûr, un mauvais bogue pourrait être introduit dans 17, vraisemblablement, alors il y aurait un effort supplémentaire pour le traiter. Regarde le bon côté. Il y avait un bug dans 14, et il a été corrigé dans 16. Vraiment, personne, sauf toi et moi, ne s’occupe de 14 et 16. Personne n’est en production, j’imagine. Le système fonctionne.

Bordet : A moins que nous ayons le bug en 17, et maintenant il faut attendre le 19 pour qu’il soit corrigé.

Horstmann : Il y a maintenant 5 chances sur 6 que cela n’arrive pas, mais c’était là avant. Je pense qu’avoir ces sorties fréquentes est une victoire. Il faut savoir qui est le public de ces sorties ? Vous êtes le public de ces sorties, et tout le monde ici ne veut pas les mettre en production. Soyez reconnaissant que les versions fréquentes soient là. Comprenez pourquoi ils sont là. Je pense que c’est positif. C’est juste que les subtilités doivent être réglées. Cela signifie pour moi qu’un LTS devrait avoir un statut plus spécial. Voici l’autre chose, cela ne pourrait pas avoir un meilleur numéro de version, vraiment, 11, 17, 23 ?

Bordet : Ce sont presque tous des nombres premiers, alors ne vous inquiétez pas.

Horstmann : Non, ils ne peuvent pas être tous des nombres premiers. C’est une suite arithmétique.

Le coût de la mise à niveau

Bordet : Un autre commentaire ici, qui est très laconique, c’est le coût. Combien cela vous coûte-t-il de mettre à jour vers la dernière version de Spring, vers la dernière version de toutes les bibliothèques que vous utilisez ? Par exemple, si vous utilisez Tomcat, ou Jetty, ou Undertow, ou JBoss, vous devrez éventuellement mettre à niveau pour corriger les bogues, ou pour être sur le dernier, par exemple, en raison de problèmes de sécurité. Cela a bien sûr un coût. Il en va de même avec le JDK, et rester sur 8 plutôt que de passer à une version plus récente, a le même coût que pratiquement tout le reste. L’inconvénient, c’est que vous restez sur 8, et ce qui se passe, c’est que vous accumulez des dettes techniques, car finalement vous devez payer un coût plus élevé lorsque vous passez de 8 à 17, ou vers une version ultérieure. Non seulement cela, c’est que, parce que vous êtes hors du marché depuis des années, vous ne savez pas que maintenant vous pouvez créer des blocs de texte, une instance avancée de syntaxe, que vous pouvez utiliser des enregistrements dans des classes scellées. Cela ne met-il pas l’entreprise qui maintient 8 hors du marché, en particulier pour les personnes qui y travaillent, est-ce qu’elles sortent du marché ? Ne craignent-ils pas cela, de devenir en quelque sorte une vieille entreprise, où les gens sont maintenant vraiment, « Nous sommes toujours en 8, nous pourrions utiliser 17 mais nous ne pouvons pas, nous sommes maintenant à court de marché ? I’ Je vais chercher un nouvel emploi. » Est-ce quelque chose qui effraie peut-être les gens ? Êtes-vous inquiet à ce sujet ou pas du tout ?

La fragmentation dans les versions de mise à jour pour 9 et 11

Ruiz : Une version de mise à jour 11 ou 9 contiendra très probablement différents correctifs, si vous l’obtenez d’Oracle, AdoptOpenJDK, Corretto et Azul. Dans quelle mesure êtes-vous inquiet de cette fragmentation ?

Bordet : Je peux répondre, tout de suite, car c’est une question que j’ai posée, au tout début, quand OpenJDK est devenu open source. J’ai posé exactement cette question. J’ai été renvoyé avec, ne vous inquiétez pas. À l’époque, le concept d’une étiquette GA appliquée à OpenJDK n’était même pas dans l’image. Les gens diront, nous avons coupé un certain commit Git, et puis c’est la sortie, et tout va bien. Ensuite, les gens ont commencé à ajouter des fournisseurs et des fonctionnalités, ou à obtenir un autre commit Git et tout. J’ai dit, comment puis-je savoir quelle version du JDK j’utilise ?

Au tout début, il y a eu cet incident avec Debian qui a ramené à 9, une fonctionnalité de 10. Ensuite, la était en fait installée en tant que JDK 9, mais si vous faisiez moins la version, elle imprimait 10. C’était un désordre royal. C’était une erreur évidente qui s’est produite dans le passé. Cela faisait peur aux gens. C’est comme si je téléchargeais cette version à partir d’un référentiel de confiance, changeais celui de Debian, mais j’obtiens quelque chose qui est au milieu de nulle part, il n’a pas passé le TCK et ainsi de suite, qu’est-ce que je fais ? Suis-je en train d’exécuter quelque chose qui est digne de confiance de quelque manière que ce soit ? Cela a soulevé une grande question. Les vendeurs ne répondent pas à ces questions. Mon point de vue est que je m’en tiens à AdoptOpenJDK, car j’espère qu’ils prennent le tag GA sur OpenJDK GitHub, et ils le construisent. C’est ça. C’est la seule chose en laquelle j’ai confiance. Je n’utilise pas de vendeurs. Je pouvais faire confiance aux vendeurs. Ils doivent être clairs pour moi à ce sujet. Ils devraient pouvoir dire, voici les notes de version. Nous avons pris le code de cette balise dans OpenJDK, qui est une balise publique. Nous avons appliqué ces correctifs, et c’est ce que vous exécutez. Nous verrons.

Horstmann : Cela va devenir complexe. Je suis absolument d’accord. AdoptOpenJDK, ou Adoptium, comme on l’appellera bientôt, est l’endroit rationnel où aller. Ou vous pourriez payer Oracle et vous savez que vous obtenez Oracle. Avec ces autres, je ne sais pas trop quelle est ma motivation car je vais aller en zoulou. Avec Corretto par exemple, si j’exécute quelque chose dans AWS, il y a de fortes chances que je l’obtienne juste, ou c’est le plus facile à obtenir. Bien sûr, bien sûr, je pourrais trouver une image qui ne l’a pas. Cela va vous rendre la vie beaucoup plus difficile en tant que fournisseur de bibliothèque, qui peut très bien avoir des bogues subtils à cause de quoi que ce soit.

Ruiz : Le fait qu’il passe le TCK ne signifie pas qu’ils suivent la même implémentation de certaines bibliothèques. Il y a des différences. Parfois, ils essaient d’améliorer leurs performances chez certains fournisseurs particuliers comme Corretto.

Bordet : C’est là que l’encapsulation OpenJDK, comme l’encapsulation forte qui vient avec 16 puis 17, va aider d’une manière ou d’une autre parce que les bibliothèques ne pourront pas trop jouer avec les internes JDK. Ils ont limité leur capacité à jouer avec le JDK uniquement via des API publiques. C’est une bonne chose. Cela évitera éventuellement que les gens tirent parti des différences de mise en œuvre.

Horstmann : C’est peut-être une autre bonne raison d’aller de l’avant.

Bordet : Par exemple, nous venons de déplacer la version Jetty de 15 à 16. Bien sûr, nous avons eu, je pense, 20 échecs de test ou probablement 40 ou quelque chose autour de cela. La raison en est que nous intégrons une bibliothèque qui joue mal avec le JDK, faisant une réflexion approfondie sur les classes JDK. Bien sûr, la valeur par défaut du JDK pour 16 est désormais deny, alors ne faites pas cela. Nous avons eu 40 échecs aux tests juste à cause de cela. Nous devons maintenant ajouter un tas d’ouvertures d’ajout en attendant que cette bibliothèque se mette à jour et supprime ces hacks.

Horstmann : Cette friction va continuer, que personne ne voudra probablement passer à 17 pour la production en août. 11 semble être un bon point à présent.

Les avantages pertinents pour l’utilisateur de 11, par rapport à 8

Ruiz : 11 apporte-t-il des avantages pertinents pour l’utilisateur par rapport à 8, comme de grandes améliorations des performances ? C’est parce que les gens utilisent des applications basées sur le cloud. Quel pourrait être le point culminant, certaines des raisons les plus attrayantes de mise à niveau qui peuvent être justifiées pour les clients ?

Bordet : La première fois que j’ai déployé Jetty pour servir notre propre site Web, et je suis passé de 8 à 9, même pas 11, le temps de démarrage de Jetty était d’environ 30 secondes, avec 8 pour notre propre site Web, qui est super petit, en fait, transfère l’appel à . Avec 9, cela est revenu à 4, 5 secondes, à tel point que la première fois que j’ai exécuté Jetty sur le nouveau site Web, c’était comme si Jetty démarrait, Enter, puis boum. Ensuite, j’étais comme, il y avait une erreur. Je pensais qu’il y avait une erreur parce que ça a commencé trop vite. Il y a des améliorations de performances à ce sujet, qui peuvent vous faire économiser de l’argent, surtout lorsque vous exécutez sur le cloud, car cela consommera moins de CPU. Il se chargera plus rapidement, et tout ce truc magique. Il ne s’agit pas seulement de la grande amélioration des performances ou d’autres choses. À l’heure actuelle, je pense qu’il vous incombe de justifier pourquoi vous voulez rester sur 8, quand vous savez que la plate-forme va s’améliorer et être bien meilleure à chaque version majeure. Pourquoi veux-tu rester sur 8 ? Par exemple, je mets à niveau Spring de 4 à 5. Pourquoi ? Parce qu’ils rationalisent les choses. Ils ont une amélioration des performances avec cela. Pourquoi ne faites-vous pas cela pour  ? Il n’y a aucune explication pour moi, fais-le.

Horstmann : Permettez-moi également de faire écho à votre problème de dette technique, car passer de 8 à 11, c’est à ce moment-là que vous franchissez l’obstacle du module la première fois. Si vous devez monter de 8 à 17, cela peut être un saut assez raide, car 8 à 11 est encore assez permissif. Lorsque vous rencontrez des problèmes de module, vous recevez des avertissements, mais vous pouvez y réagir. Si vous passez de 8 à 17, tout va être proche de vous et vous allez passer un sacré moment. Je pense que puisque, à un moment donné, il faut payer cette dette technique, autant le faire en tranches raisonnables.

Bordet : Je suis tout à fait d’accord avec vous, que le gros obstacle est, à mon avis, de 8 à plus de 8, où que vous alliez. Maintenant, le cas courant est de 8 à 11. C’est un grand saut. Vous ne voulez pas accumuler de dettes sur ce saut. Une fois que vous êtes sur 11, alors toutes les autres mises à jour allant à n’importe quelle future version, sont très fluides dans notre expérience. Avec 16, nous avons maintenant ajouté ce problème d’encapsulation. Cela a été annoncé. Cela arrivait. Il est venu. C’est ici. Allez le réparer dans les bibliothèques qui font encore des trucs désagréables avec les internes JDK. Une fois que vous avez terminé les bibliothèques, vous êtes prêt à partir. Avance.

Les vrais hacks de la mise à niveau

Ruiz : En fait, nous avons eu cette session avec Marc et il parlait de, dans les systèmes de production critiques, comment mettez-vous à niveau ? Parce qu’évidemment, il y a toujours une raison impérieuse de mettre à niveau. Que pouvez-vous nous dire sur cette discussion sur les vrais hacks de la mise à niveau ?

Hoffmann : Je ne peux qu’appuyer ce qui a déjà été mentionné ici, et peut-être que le côté commercial de la chose est également important pour les entreprises qui n’ont pas les moyens de se mettre à jour. Surtout si vous êtes avant 8, que vous utilisez une version non prise en charge, vous n’obtiendrez pas de mises à jour pour cela. S’il y a un problème, si vous devez un jour remplacer votre système d’exploitation et acheter de nouvelles machines, vous n’avez peut-être pas de version que vous pouvez même installer sur ces machines. Actuellement, nous avons une forte tendance vers les architectures ARM. Les fournisseurs de cloud, en raison de l’efficacité énergétique, passeront probablement davantage à ARM. Maintenant, nous obtenons de nouveaux systèmes d’exploitation, qui ne sont pas placés sur Intel. Comment obtenez-vous une machine virtuelle 7 pour cela? Vous pouvez probablement les acheter chez Oracle aussi pour des tonnes d’argent, mais vous ne l’obtiendrez pas gratuitement. Vous pouvez penser que vous feriez peut-être mieux d’investir de l’argent dans la migration vers une version plus récente de et que la nouvelle plate-forme soit également prise en charge. Peut-être que vos développeurs vous forceront car ils ne peuvent plus utiliser leurs tout nouveaux MacBooks avec les anciennes versions de .

Bordet : Par exemple, l’une des raisons pour lesquelles on me dit de ne pas mettre à jour est que le côté production des choses est géré par un groupe différent. Ils ne veulent pas mettre à jour parce qu’ils ont causé des choses comme les infâmes sysops. Leur argument est que je peux obtenir des mises à jour gratuites, dans le sens où ils n’ont rien à faire pour le système d’exploitation, car par exemple, si vous avez Ubuntu, il y a une tâche cron tous les jours. Il ping les référentiels et dit, y a-t-il une mise à jour? Puis vous invite avec la mise à jour. Vous pouvez tout automatiser et vous êtes prêt à partir. Nous ne pouvons pas faire cela avec . Ne pouvez-vous pas, vraiment? Parce qu’il existe des outils et tout ce qui peut réellement interroger les référentiels pour et télécharger la version et le fournisseur que vous souhaitez installer sur votre système. Garder le tout à jour.

Je ne dis pas, par exemple, de passer de 16 à 17 en production sans tester auparavant, mais de passer de 16.00 à 16.01, quand les correctifs de sécurité habituels de trois mois arrivent. Pourquoi pas ? Nous le faisons tout le temps dans nos téléphones, en téléchargeant les derniers correctifs pour Android et ainsi de suite. Idem pour Spring et Jetty, nous avons récemment publié quelques versions en raison d’avis de sécurité déposés contre nous. Nous avons demandé aux gens, veuillez effectuer une mise à niveau. Nous disons aux gars de Spring qui dépendent de Jetty, veuillez utiliser la dernière version de Jetty car il y a un problème de sécurité, et ainsi de suite. Je pense que c’est plus comme un processus mental. Vous devez avoir un processus dans votre entreprise pour tout mettre à niveau, du système d’exploitation à votre bibliothèque. Juste parce que JDK 8 fonctionne, ce n’est pas une bonne raison de rester là et de mettre à jour tout le reste. C’est comme, pourquoi ai-je toujours cette vieille chose ici ?

Hoffmann : Absolument. Vous devez vraiment vous habituer à mettre à jour vos systèmes de production. Comme un de mes amis nous le dit toujours, alors si ça fait mal, faites-le plus souvent.

Ruiz : Il y a des améliorations de performances comme les cordes compactes dont vous n’avez rien à faire et vous en bénéficierez. Il arrive parfois que vous deviez investir dans la modification de votre code pour utiliser les fonctionnalités, mais vous en bénéficiez toujours. Vous obtenez le retour de ce qui va être une situation douloureuse dans un proche avenir, que cela doit arriver car les bibliothèques voudront probablement mettre à niveau, ou de nouveaux outils ne voudront pas démarrer avec une ancienne version de . Il y a toujours une raison impérieuse de migrer ou de mettre à niveau.

Bordet : Il y a eu quelques commentaires ici qui disent, non, nous utilisons WebLogic. Nous avons, par exemple, une contrainte de certification pour rester sur une version très spécifique, car c’est la version contre laquelle WebLogic est certifié. C’est une très bonne raison, et c’est une raison économique. Maintenant tu dois t’asseoir et dire, combien de temps je reste ici ? Développer en 17 est bien mieux. Vos développeurs seront tellement plus heureux. Il faut mettre sur la balance, au fond, qu’est-ce qui est important ? Quelles sont les conséquences de rester sur une ancienne plate-forme, l’ancienne WebLogic et tout le reste, et d’essayer de s’en éloigner ?

Il existe des entreprises, par exemple, qui vous aident à vous éloigner de ces vieux scénarios. Peut-être le coût pour obtenir de l’aide pour passer d’une ancienne version de WebLogic à l’endroit où vous n’utilisez peut-être même pas d’EJB, mais c’est juste une application Web dans WebLogic, alors il y a des entreprises qui vous aident. Peut-être que payer ces entreprises pour vous aider à vous éloigner de WebLogic vous a coûté beaucoup moins qu’une seule année d’utilisation de WebLogic.

C’est toujours un compromis. Ne restez pas sur 8, juste parce que vous ne savez pas, ou quelque chose comme ça. Si vous avez une très bonne raison, comme le cas WebLogic, ok. Si vous ne le faites pas, optez simplement pour la mise à niveau.

Horstmann : Les développeurs vous remercieront.

Expérience avec les modules

Ruiz : Quelle est votre expérience avec les modules ? Comme les disques maintenant, il y a quelques années, les modules étaient le mot clé. Il a passé suffisamment d’années, donc le module aurait dû être adopté. Ils ne l’ont pas fait. Que pensez-vous arrivé?

Horstmann : J’ai dit, je vais commencer à croire en des modules pour tout le monde. Les modules ont un avantage indéniable pour Oracle, pour l’architecture de la , et le JDK lui-même. Ils permettent cette encapsulation dont nous avons grandement besoin. Et les autres ? J’ai dit, je vais croire que les modules seront intéressants pour les programmeurs généraux, quand je verrai les serveurs Web EE implémentés avec des modules de plate-forme . Qu’a fait Oracle ? Ils ont immédiatement abandonné l’effort EE, ils n’ont donc pas eu à le faire. Ceux-ci sont là pour les projets à grande échelle, pour les grands systèmes. Personnellement, je n’ai pas vu de gros système doté d’une architecture modulaire. J’ai vu des bibliothèques et des composants qui ont été modularisés, juste au cas où quelqu’un voudrait les utiliser comme modules. Je n’ai pas vu de gros système.

Hoffmann : Je n’ai jamais vu un grand système qui utilise un système de modules , mais j’ai vu beaucoup de grands systèmes qui utilisent d’autres systèmes de modularisation qui ont été établis au fil des ans. Le problème avec les modules est qu’ils sont essentiellement en concurrence avec des systèmes comme OSGi ou d’autres systèmes de composants, qui existent depuis des années. Peut-être qu’il est un peu trop tard dans le jeu pour vraiment l’adopter, et peut-être que certains frameworks majeurs doivent sauter sur les modules, passer la chaîne de module pour les faire réussir.

Voir plus de présentations avec

.

All the CMS Templates You Could Ask For.

WordPress: Panneau Java et JVM

2M+ items from the worlds largest marketplace for CMS TemplatesEnvato Market.



WordPress: Panneau Java et JVM

#Panneau # #