LCC 257 - Interview Java 16 avec José Paumard et Henri Tremblay - partie 2

71 views
Skip to first unread message

Emmanuel Bernard

unread,
Jun 7, 2021, 4:39:01 AM6/7/21
to lescast...@googlegroups.com
José (maintenant Java Advocate chez Oracle - le cachotier) et Henri échangent avec Emmanuel sur la sortie de Java 16.
Cette deuxième partie voit l'équipe discuter de la propriété illegal access (JEP 396), de l'API vectorielle, de la foreign linker API et d'autres choses.


Emmanuel

Remi Forax

unread,
Jun 7, 2021, 9:04:30 AM6/7/21
to lescastcodeurs
Bonjour à tous,
pour la partie sur les modules, vous avez oublié une option importante, le Lookup,
la façon de faire de la reflection à changer en Java 7, il y a deux façon de faire des la reflections,
soit on utilise java.relfect et dans ce cas on est sousmis au fait qu'un module/package soit ouvert (open) ou pas,
soit un utilise java.lang.invoke qui malheureusement demande de changer l'API de ta librarie car il faut passer un objet java.lang.invoke.MethodHandles.Lookup supplémentaire pour l'utilisateur mais cet objet te permet d'aller voir tout ce qui est visible à partir de la classe qui a créer le Lookup.

Pour EasyMock ou tous ce qui est test unitaire, ton test est déjà dans le bon package, donc si tu demande un Lookup dans le test puis que tu le passe à l'API de mocking, tu viens de donner le droit à l'API de mocking de voir et créer des classes (avec lookup.defineClass) dans ce package. Specifiquement pour les proxy/mock, tu as Lookup.defineHiddenClass qui a été ajouté en 15 (avant il faut utiliser Unsafe.defineAnonymousClass aussi avec un Lookup) qui te permet de plus d'accéder aux champs privées car tu à l'option de charger la classe du Mock comme un nestmate.

Cela résoud pas le problème de sizeof qui lui fait de la reflection sur n'importe quoi mais cela résoud le problème de toutes les APIs à base de proxy.

Pour Lombok, le noeud du problème est que Oracle (et SUN avant) ne veut pas exposé publiquement des parties privées de javac (tree API) que Lombok utilise
C'est le genre de situation qui dans le passé a mené à la création de LLVM (car gcc voulait pas d'un système de plugin dans gcc) [1].
Je suis pas sôr qu'il y ait une bonne solution pour ce problème, la tree API de javac change constament en ce moment, dès qu'il y a une nouvelle syntaxe + refactoring en prévision de Valhalla.
Pour l'instant, les devs de lombok utilisent un hack basé le fait que le layout d'un objet dépend des types des champs et de l'ordre des champs dans les classes, il n'y a pas de randomization comme tu peux l'avoir dans le kernel linux pour les structures importantes,
donc un jour où l'autre cela va plus marcher quand l'ordre des champs sera randomizés.

Une possible solution consisterait peut-être à revoir la "spec" des beans de Spring ou Hibernate pour ajouter la notion de bean virtuelle, déclarer un bean sous forme d'interface avec juste les getters (et possible setter) abstrait,
eE laisser le framework compléter comme cela Lombok est plus vraiment nécessaire. Les repository de Spring data ou Panache sont déjà basé que sur des interfaces et maintenant que l'on a des méthodes par défaut, on peut écrire du code dans les interfaces donc on est pas forcé d'avoir une interface et une implantation comme avec les beans v1 et v2. Une autre solution serait d'utiliser des records, mais cela demande de changer le tracking des objets dirty et comme il n'y a pas de d'opérateur with, on est revenu au même problème que les gens utiliseront Lombok pour générer les withers.

Henry, il existe TornadoVM si tu veux offloader du calcul sur GPU [2]. Henry, tu confonds les registres AVX et les buffers PTX. L'API de vectorisation utilise des regitres spécialisés mais la mémoire classique. Il n'y a pas de copie comme Emmanuel le dit.
Pour José, on utilise déjà du SIMD en Java, par exemple pour la manipulation des Strings, mais l'API est en C++ à l'intérieur de Hotspot. L'idée de l'API de vectorisation est de pouvoir écrire ce genre d'algo en Java.
Par exemple, il y a pelin de gens qui se demande comment accélerer le parsing JSON à base de SIMD [3].
Henry, c'est WORA, car tu as SPECIES_PREFERRED qui dit prend la taille des registres du CPU sur lequel tu tournes. En fait, l'astuce de cette API est de demander au JIT de faire le boulot comme cela ton algo s'adapte pile poil à la machine sur laquelle il tourne car le JIT regarde qu'elle son les operations et taille des registres (SSE, AVX2, AVX-512 ou Neon, MVE sur ARM).

Le problème de JNA est que l'API est cool mais c'est lent. Il y a aussi JNR mais cela marche vite que sur intel 64 bits.

Emmanuel a raison, un des buts de l'API de foreign memory est d'avoir une API safe et efficace pour gérer la mémoire off-heap, donc de ne pas avoir a utiliser Unsafe.
Unsafe est pas forcément super efficace, par exemple, Unsafe ne supporte pas l'auto-vectorisation alors que jdk.incubator.foreign le supporte.

Pour la big picture, ce qu'il faut voir derrière Panama que cela soit l'API des vecteurs, la foreign memory ou le foreign linker est que ce sont des APIs qui sont nécessaires si on veut ré-écrire la VM en Java.

Primitive object vs record, pour Henry, le primitive object (ex inline type ex value type) et les records sont deux concepts séparés.
- primitive object, on écrit une classe et cela se comporte comme un int, donc pas de synchronize, == compare les champs pas les addresses et pas de struicture récursive (A dépend de B qui dépend de A).
  Globalement, c'est un objet mais pas manipulé par pointer. Contrairement à ce qu'à dit José, un primitive objet peut contenir des Objets dans les champs, comme n'imporet quel objet.
- un record est un tuple nommé, une classe sans encapsulation si vous préférrez. Un record c'est fait pour faire des classes comme Pair, Entry, etc ou modéliser des objets métiers que tu passent entre les couches,
   les fameux DTO.

Donc c'est pas vraiment la même chose, mais on peut les combiner, cela marche déjà dans le repo Valhalla, un primitive record se comporte comme un type primitive (pas d'addresse, manipuler par valeur) et n'a pas d'encapsulation.

Rémi

[1] l'ironie est que LLVM a pas une API stable donc écrire un système de plugin est pas faisable non plus à part si tu es un boite avec un certains nombre de devs.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjK%3DZcmix356actOb3r4NqNBkK39WOGU0SvYZYkDhBqfng%40mail.gmail.com.

Henri Tremblay

unread,
Jun 7, 2021, 10:46:04 PM6/7/21
to lescastcodeurs
Super intéressant. Merci Rémi.

Je ne sais pas quelle niaiserie j'ai dit mais oui, l'histoire de la mémoire c'est sur GPU, pas sur Intel.

Je ne comprends pas ton exemple du Lookup. Quand tu crées un mock, il n'est jamais dans le package du test. Donc tu as EasyMock dans org.easymock qui doit créer un mock d'une classe dans le package x.y.z et le test est dans a.b.c. Idéalement la classe créée devrait être dans x.y.z. Ce qui est impossible car on a pas le Lookup de la classe à mocker.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/1202714002.527921.1623071063835.JavaMail.zimbra%40u-pem.fr.

Remi Forax

unread,
Jun 8, 2021, 9:02:28 AM6/8/21
to lescastcodeurs
De: "Henri Tremblay" <henri.t...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mardi 8 Juin 2021 04:45:51
Objet: Re: [LCC] LCC 257 - Interview Java 16 avec José Paumard et Henri Tremblay - partie 2
Super intéressant. Merci Rémi.
Je ne sais pas quelle niaiserie j'ai dit mais oui, l'histoire de la mémoire c'est sur GPU, pas sur Intel.

Je ne comprends pas ton exemple du Lookup. Quand tu crées un mock, il n'est jamais dans le package du test. Donc tu as EasyMock dans org.easymock qui doit créer un mock d'une classe dans le package x.y.z et le test est dans a.b.c. Idéalement la classe créée devrait être dans x.y.z. Ce qui est impossible car on a pas le Lookup de la classe à mocker.

Nope, le mock doit être dans a.b.c pas dans x.y.z, ce que tu veux en mockant c'est faire la même chose que écrire une classe de mock à la main, si tu écrits ta classe
qui implante l'interface que tu veux mocker à la main, tu va bien l'écrire dans le package de test, pas de le package de l'interface que tu veux mocker.

Donc fournir à ton API de mocking (à EasyMock) un Lookup représentant la classe de test quand tu créés le mock c'est excatement ce que tu veux.

Si tu as déjà un truc qui sait créer des proxies [1] en utilisant des hidden classes [2], alors mocker c'est juste comparer deux traces d'exécution avec une API marrante [3].
Une API qui te laisse appeler le mock directement pour génerer la trace "expected" puis une fois que tu switches d'état qui te permets d'utiliser le mock comme proxy ou bouchons pour générer la trace "actual".

Le seule cas où tu as besoin de faire des manips pas catholique est si tu as des classes et pas des interfaces et sans constructeur par défaut, car la classe de ton mock va hériter de la classe que tu veux mocker et tu veux by-passer l'appel au constructeur.
Pour by-passer l'appel au constructeur, tu as besoin de sun.reflect.ReflectionFactory, et ça tombes bien car il est toujours dispo dans le module jdk.unsupported.
Pour ce scénario specifique, je pense qu'il serait bien de demander à l'API de mocking de passer en mode 'crado' pour dire qu'il y a un problème de design plutôt que d'encourager à ne pas utiliser des interfaces lorsque tu as des dépendances entre package comme le get started de EasyMock le suggère.

Rémi




Henri Tremblay

unread,
Jun 8, 2021, 1:02:29 PM6/8/21
to lescastcodeurs
En fait, pour limiter les différences entre un mock et la vraie classe (par exemple, si la classe fait un getClass().getPackage() ou pour OSGi, ou autres hacks comme ça),  je crée dans le package de la classe mockée.
Ce qui est en effet plus puissant que ce que peut faire un mock à la main.
Mais là on me l'interdit.

Je n'appelle jamais le constructeur (sauf pour des mocks partiels bien sûr) 
J'utilise ReflectionFactory parce que la dernière fois que j'ai fait un benchmark, c'était beaucoup plus rapide que Unsafe.allocateInstance qui est le fallback.

Et je me bats depuis 20 ans pour dire que d'ajouter des interfaces juste pour le plaisir de mocker c'est une énorme complexité inutile.
Une interface quand il n'y a qu'une seule implémentation c'est juste du bruit. Et c'est 95% des classes.
Être capable de mocker des classes c'est nécessaire.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/1300020072.1296258.1623157250267.JavaMail.zimbra%40u-pem.fr.

Remi Forax

unread,
Jun 8, 2021, 3:44:05 PM6/8/21
to lescastcodeurs


De: "Henri Tremblay" <henri.t...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mardi 8 Juin 2021 19:02:15
Objet: Re: [LCC] LCC 257 - Interview Java 16 avec José Paumard et Henri Tremblay - partie 2
En fait, pour limiter les différences entre un mock et la vraie classe (par exemple, si la classe fait un getClass().getPackage() ou pour OSGi, ou autres hacks comme ça),  je crée dans le package de la classe mockée.
Ce qui est en effet plus puissant que ce que peut faire un mock à la main.
Mais là on me l'interdit.

Dans le podcast, tu parles du fait qu'on te l'interdit à cause d'une idée de pseudo-sécurité, mais je pense qu'il y a un problème de traduction vers le français,
c'est un problème de "safety" plus que de "security".

Une question que mes étudiants me posent souvent, pourquoi on s'embête avec les privates, plus généralement la notion d'encapsulation si tu peux tout voir et tout modifier par réflection.
Le truc est que lorsque tu écrits une classe c'est très dure de penser à tout les scénario d'utilisation possibles si tout est publique, où si tu peux tout changer par réflection.

Fondamentalement, c'est une question de responsabilité, dit différemment sur qui il faut taper quand il y a un problème.
Lorsqu'une méthode d'une classe plante parce que quelqu'un à utiliser la reflection, sur qui on tape ?
Bah, on regarde le stacktrace, et dans le stacktrace, il y a pas marqué que machin c'est amusé à changer la valeur d'un champ par reflection ou à créer des classes dans un package qui lui appartenait pas,
il y a marqué que la méthode d'une classe de ce package plante.


Je n'appelle jamais le constructeur (sauf pour des mocks partiels bien sûr) 
J'utilise ReflectionFactory parce que la dernière fois que j'ai fait un benchmark, c'était beaucoup plus rapide que Unsafe.allocateInstance qui est le fallback.

Et je me bats depuis 20 ans pour dire que d'ajouter des interfaces juste pour le plaisir de mocker c'est une énorme complexité inutile.
Une interface quand il n'y a qu'une seule implémentation c'est juste du bruit. Et c'est 95% des classes.
Être capable de mocker des classes c'est nécessaire.

Je pense que tu prends le problème à l'envers, si tu veux mocker qqchose, alors forcément ce truc à deux implantations, la normale et ton mock, donc cela devrait être une interface.
Je suis complètement d'accord que dans l'absolue avoir des interfaces partout cela obscurcit le code, mais c'est un strawman, même mes étudiants qui ont du mal ne font pas ça.

Vouloir tout mocker cela à un coût, car juste écrire un test cela à un coût, donc tu va mocker là où c'est imporant, là où il y a des dépendances entre des classes de packages différents.
Une dépendance de ce type se traduit normalement par une interface, où une classe avec un constructeur sans paramètre, si tu utilises des vielles bibliothèques comme le JDK.

Donc permettre de pouvoir tout mocker me parait contre productif, car tu aides pas tes utilisateurs à faire la différence entre un bon mock et un mauvais mock ...
Je suis conscient que je parle à monsieur mock et donc que la citation d'Upton Sinclair s'applique [1],
mais je persiste à penser que permettre de tout mocker en créant des mocks dans les packages des autres me semble pas aller dans le bon sens.


Rémi

[1] It is difficult to get a man to understand something when his salary depends on his not understanding it


Henri Tremblay

unread,
Jun 8, 2021, 5:20:04 PM6/8/21
to lescastcodeurs
On va être pas d'accord :-)

Upton Sinclair ne s'applique pas. J'ai développé des concepts parce que je suis pragmatique et que c'est utile.
Ça a simplifié ma vie et celle de milliers de développeurs.
Par exemple, je n'utilise EasyMock que quand c'est nécessaire.
Je fais beaucoup de mock à la main.

En 2000, quand Tammo Freese a créé EasyMock, il était opiniâtre. On ne mock qui les interfaces.
Moi pendant ce temps, je construisais des applications financières avec des milliers de classes... et des milliers d'interfaces juste pour le plaisir de tester.
C'était l'enfer.

Quand l'idée des mocker des classes est venue, c'était easymock-classextension pendant des années.
Le marketing était: C'est mal mais si vous en avez besoin, allez-y.
Sauf que en 2005, Tammo s'est rendu compte que ce n'était pas vrai.
Que c'est bien mignon la pureté théorique mais en pratique, c'est tannant et contre-productif.
Le mock partiel c'est pareil. C'était le mal pendant un moment (même pour moi). 
Mais on a fini par trouver des cas d'usage légitimes.
Donc dans Mockito, ils en ont mis direct.

C'est un peu pareil avec Hibernate et Spring.
Ils font plein de trucs louches d'un point de vue design mais c'est drôlement pratique.

Le concept de package en java n'a jamais très bien marché. Donc tout le monde s'en fout. On essaie de mettre les choses à un endroit pertinent.
En particulier comme un package n'a pas accès à un sous-package, ça fait rapidement un gros tas de classe dans un package.
Les modules sont mieux.

Ce qui a toujours bien marché en Java et qui est selon moi la principale raison de son succès, à part la simplicité historique (qui l'est de moins en moins), c'est qu'il y a toujours un moyen de s'en sortir.
Une classe est boguée, pas de problème, j'en mets une devant dans le classpath.
Un valeur est tout pourri, pas de problème je vais arranger ça avec un petit coup de réflection.

Par exemple, le driver JDBC Oracle a leaké un thread pendant des années.
Un machin pour nettoyant les connections avec un timeout.
Donc, la solution, changer un flag à la dure pour faire sortir le thread.

Tranquillement, on rend ça très très compliqué.
Et je voulais bien dire "security", car c'est l'argument.
De la réflection c'est dangereux parce qu'on peut tirer sur n'importe quoi dans le JDK.
Et oui on a eu des failles de type serialization injectés qui exécute du code.
Donc oui, réduisant les possibilités, on réduit la surface d'attaque.

Mais on réduit aussi ma joie de vivre.
Et celle de tous les développeurs.
Et le côté magique de Java qui a amené Groovy, Lombok, Hibernate, EasyMock, XStream, ByteBuddy et je ne sais quoi d'autre.
Parce que l'autre truc c'est qu'il faut être drôlement intelligent de nos jours pour faire quelque chose.

Avant: Je vais générer dynamiquement une classe qui va en étendre une autre et appeler le même truc que la sérialization pour créer la classe dans constructeur. C'était déjà pas facile mais ça se fait.
Aujourd'hui: Pareil mais en plus je vais le mettre en nestmate dans mon package. JUnit ayant fait un patch au-dessus de mon projet. Et je vais la faire hidden parce que c'est mieux caché. Et si je veux faire plus compliqué je prend ByteBuddy et je crée un processus externe qui va s'enregistrer comme agent pour ajouter de l'instrumentation sur ma JVM pour être capable d'injecter du code dans les classes existantes pour pouvoir mocker... Vive le progrès.


Remi Forax

unread,
Jun 8, 2021, 7:22:32 PM6/8/21
to lescastcodeurs


De: "Henri Tremblay" <henri.t...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mardi 8 Juin 2021 23:19:51
Objet: Re: [LCC] LCC 257 - Interview Java 16 avec José Paumard et Henri Tremblay - partie 2
On va être pas d'accord :-)

Papa et Maman sont pas d'accord :)


Upton Sinclair ne s'applique pas. J'ai développé des concepts parce que je suis pragmatique et que c'est utile.
Ça a simplifié ma vie et celle de milliers de développeurs.
Par exemple, je n'utilise EasyMock que quand c'est nécessaire.
Je fais beaucoup de mock à la main.

En 2000, quand Tammo Freese a créé EasyMock, il était opiniâtre. On ne mock qui les interfaces.
Moi pendant ce temps, je construisais des applications financières avec des milliers de classes... et des milliers d'interfaces juste pour le plaisir de tester.
C'était l'enfer.

Quand l'idée des mocker des classes est venue, c'était easymock-classextension pendant des années.
Le marketing était: C'est mal mais si vous en avez besoin, allez-y.
Sauf que en 2005, Tammo s'est rendu compte que ce n'était pas vrai.
Que c'est bien mignon la pureté théorique mais en pratique, c'est tannant et contre-productif.
Le mock partiel c'est pareil. C'était le mal pendant un moment (même pour moi). 
Mais on a fini par trouver des cas d'usage légitimes.
Donc dans Mockito, ils en ont mis direct.

C'est un peu pareil avec Hibernate et Spring.
Ils font plein de trucs louches d'un point de vue design mais c'est drôlement pratique.

Je vois deux bonnes raisons de ne pas supporté tous les cas possible,
- cela augmente le cout de maintenance: tu râles car tu dois maintenir le support des classes et c'est moins facile avec les JDKs récents.
- cela rend ta librarie plus complexe à utiliser: quand cela marche pas, il faut être un expert pour comprendre le problème.

Si tu regardes les lambdas en Java, c'est aussi des proxy glorifiés donc les mêmes questions que pour EasyMock se sont posées,
est-ce que l'on support les classes, les classes abstraites, est-ce que l'on by-pass le constructeur, etc. donc les mêmes questions.

Pourtant la solution choisie par Java est que les lambdas ne supportent que les interfaces. Tu le monde a trouvé cela bête au début et maintenant tout le monde s'en fout.
Il y a plusieurs raisons à ce choix, une des raisons est que le modèle de fonctionnement est beaucoup plus simple, pas de champs initialisés ou pas initialisés, de problème de publication, etc.

Donc oui, tu peux toujours trouver des cas légitimes (si, si tu plisses bien les yeux) d'utilisation de classes au lieu d'interfaces,
mais cela vient avec une complexité en bagage qui est la raison pour laquelle tu râles au départ.


Le concept de package en java n'a jamais très bien marché. Donc tout le monde s'en fout. On essaie de mettre les choses à un endroit pertinent.
En particulier comme un package n'a pas accès à un sous-package, ça fait rapidement un gros tas de classe dans un package.
Les modules sont mieux.

Comme unité de ré-utilisation, les modules c'est mieux, cela fait longtemps que l'on s'échange des jar par l'intermédiaire de Maven Central.
Cela dit, les packages ont une utilités, en terme segmentation de la connaissance, je suis pas obligé de connaitre tous les packages pour utiliser une librarie,
c'est la raison historique des packages, si j'interagit pas avec le réseau ou une BDD, j'ai pas besoin de connaitre java.net ou java.sql.
Puis, est venu la notion de package publique (exported) et de package interne (concealed), qui est aussi une distinction importante.


Ce qui a toujours bien marché en Java et qui est selon moi la principale raison de son succès, à part la simplicité historique (qui l'est de moins en moins), c'est qu'il y a toujours un moyen de s'en sortir.

Java est simple car il t'offre pas, par exemple, la possibilité de débrayer le GC et faire les mallocs à la main même si cela serait drolement pratique.
La simplicité vient du fait que tu decides de ne pas gérer les cas particuliers.
Contraste cela avec la gestion des exceptions, en Java, tu as 3 sortes d'exceptions que tu dois gérer différemment et les méthode qui lèvent des checked exceptions ne se composent pas avec celles qui ne lèvent pas de checked exceptions.

Bien sûr, la question est où placer la barre, qu'est ce qui est un cas particculier, qu'est ce qui ne l'est pas ?
Pour reprendre mon exemple avec les lambdas, est-ce qu'une lambda serializable est un cas particulier ou pas ?

Une classe est boguée, pas de problème, j'en mets une devant dans le classpath.
Un valeur est tout pourri, pas de problème je vais arranger ça avec un petit coup de réflection.

Par exemple, le driver JDBC Oracle a leaké un thread pendant des années.
Un machin pour nettoyant les connections avec un timeout.
Donc, la solution, changer un flag à la dure pour faire sortir le thread.

Ce que tu veux c'est un hotfix, modifier le bytecode est ce qui est recommandé pour ce genre de situation, donc bytebuddy est ton ami.
Le fait que tu puisses libérer la thread en allant mettre null dans le champ est juste un heureux hazard, la plupart du temps c'est un peu plus compliqué.


Tranquillement, on rend ça très très compliqué.
Et je voulais bien dire "security", car c'est l'argument.
De la réflection c'est dangereux parce qu'on peut tirer sur n'importe quoi dans le JDK.
Et oui on a eu des failles de type serialization injectés qui exécute du code.
Donc oui, réduisant les possibilités, on réduit la surface d'attaque.

Mais on réduit aussi ma joie de vivre.
Et celle de tous les développeurs.
Et le côté magique de Java qui a amené Groovy, Lombok, Hibernate, EasyMock, XStream, ByteBuddy et je ne sais quoi d'autre.

La liste est intéressante, j'ai trouvé l'intru, EasyMock, tous les autres ont la capacité de faire ce pourquoi ils ont été créé à compile time et pas que à runtime. EasyMock est runtime only :)
Cela veut dire qu'ils ne font que des choses supportés par le bytecode, sinon ils pourraient pas faire leur traitement pendant la compilation.

Parce que l'autre truc c'est qu'il faut être drôlement intelligent de nos jours pour faire quelque chose.

Nan, on devient juste plus vieux et donc on a la malédiction de la connaissance qui vient frapper à notre porte.
Et tous est pas forcément plus compliqué, je suis super content de pouvoir faire un groupBy en une ligne (ou un sort() pour ceux qui sont assez vieux pour se souvenir qu'avant Java 1.2, il n'y avait pas d'algo de trie dans le JDK).


Avant: Je vais générer dynamiquement une classe qui va en étendre une autre et appeler le même truc que la sérialization pour créer la classe dans constructeur. C'était déjà pas facile mais ça se fait.
Aujourd'hui: Pareil mais en plus je vais le mettre en nestmate dans mon package. JUnit ayant fait un patch au-dessus de mon projet. Et je vais la faire hidden parce que c'est mieux caché. Et si je veux faire plus compliqué je prend ByteBuddy et je crée un processus externe qui va s'enregistrer comme agent pour ajouter de l'instrumentation sur ma JVM pour être capable d'injecter du code dans les classes existantes pour pouvoir mocker... Vive le progrès.

Comme je le disais plus haut, vouloir tout gérer à un prix en terme de maintenance.

Et pour lacher une autre bombe, en plus tu as plus besoin de supporter le security manager :)

Rémi

Henri Tremblay

unread,
Jun 9, 2021, 7:29:14 AM6/9/21
to lescastcodeurs
Ma joie de vivre est grande devant la disparition du security manager. J'aime beaucoup l'autre proposition sur les limites de la sérialisation.

L'intrus n'est pas EasyMock. XStream crée des classes sans appeler de constructeur, car ils font de la sérialisation et que l'idée était de faire comme la sérialisation Java. Objenesis vient de là en partie.

Quand je parle de complexité, tu le représente très bien. J'ai un bogue dans le driver JDBC. Les solutions:
1- Je change un flag par réflection pour m'en sortir. C'est un coup de chance que je puisse
2- Il n'y a pas de flag. Je copie le classe, je corrige et je la mets en avant dans le classpath. De nos jours ça serait un patch
3- Je fais de la manipulation de Bytecode avec une librairie fabuleusement compliqué sous et sur le couvert

Là tu me dis: "Henri, fais 3 direct". Tu imagines le niveau de complexité pour un développeur? De générer du bytecode pour ajouter un close() sur une classe qui change un flag volatile et injecter un "if" dans la loop pour sortir de là? Même moi faudrait que je cherche quelques jours. C'est intense.

J'ai toujours eu la partie pris que si c'est de l'API privé, je l'utilise à mes risques et périls. Je sais que je fais un truc louche. C'est mon problème. Donc le JDK n'a pas à vouloir arranger tous les usages. Mais des fois on se rend compte que le hack est super utile. Donc dans ce cas, ça vaut la peine de trouver une solution. Quand PowerMock est sorti, ils tapaient sur les API internes d'EasyMock. S'ils avaient pas pu, il n'y aurait pas eu de PowerMock. J'haïe PowerMock mais dans certains cas c'est utile, en début de refactoring surtout. Je le fais disparaître après. Quand j'ai réalisé ça, j'étais pogné à ne pas trop changer mes APIs internes. Mais ça veut juste dire que mes API publiques n'étaient pas correctement ouvertes à l'extension. À aucun moment je me suis dit que c'était pas correct ce qu'ils ont fait. Ils n'avaient pas le choix.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/1565838837.1600874.1623194547060.JavaMail.zimbra%40u-pem.fr.

Nicolas Delsaux

unread,
Jun 17, 2021, 12:59:10 PM6/17/21
to lescast...@googlegroups.com

Un épisode particulièrement intéressant.

J'ai beaucoup aimé la râlerie d'Henri contre les modules et l'encapsulation apparue depuis Java 11 parce que, sur deux applications que j'ai migré (une vieillerie Java 6 et un projet open-source qui lance du CDI dans un exec-maven-plugin maven), j'ai été putain de mordu A CHAQUE FOIS par les modules. Et même si j'ai eu la discussion il y a des années à Devoxx avec Rémi, le fait que, pour des raisons politiques, Oracle ait remplacé OSGi par une solution à moitié aussi subtile, et offrant le quart des fonctionnalités, ben franchement, pour les modules, je suis clairement dans la team "jamais de modules dans mon code".

Et va-t-en lire le blog de Nicolai Parlog qui te donne des astuces louches pour faire marcher maven à grands coups de fichiers non documentés (là : https://nipafx.dev/maven-on-java-9/).

Et va-t-en découvrir la "magie" des split packages avec des messages de compilation pénibles. A ce sujet, je trouve que les équipes qui font évoluer le JDK devraient se soucier un poil plus de l'expérience développeur en s'inspirant, par exemple, de ce que font les gens de Rust.

Et va-t-en découvrir que les dernières versions du JDK virent des classes comme s'il en pleuvaient. sur ce point spécifique, ça me rend dingue : pendant mes quinze premières années de développeur Java, je pouvais passer d'une version à la suivante limite les yeux fermés. Et maintenant, comme on est dans l'informatique en tant que mode, il faut absolument supprimer chaque référence au mot XML. Et du coup aux saloperies SOAP. Alors d'accord, c'était de la merde, mais on se retrouve avec des migrations poussées de force dans lesquelles on perd en features. Et ça, c'est fatiguant.

Oui, je râle fort. Mais c'est parce que j'aime beaucoup continuer à bosser en Java, et je n'aime spécialement pas l'idée de ce tweet https://twitter.com/scanlime/status/1405259826964307970 (je cite "went from a dream of "write once, run anywhere" to "write yearly, runs in chrome") que semble adopter même l'équipe définissant les évolutions.

En tout cas, encore merci pour le podcast, et pour les notes de Rémi !

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

Cédric Beust ♚

unread,
Jun 17, 2021, 10:57:38 PM6/17/21
to lescastcodeurs
Si tu veux retrouver ton zen, suis mon chemin: Kotlin et Rust.

Ces deux langages sont en train de définir le futur des langages de la décennie à venir.  Ce serait super si le podcast leur consacrait un peu plus de temps, mais bon, je comprends qu'il y a un peu de "bad blood" à cause de Ceylon.

-- 
Cédric


Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/f2a68fc6-4eaf-5124-3168-9675053ea293%40gmx.fr.

Nicolas Delsaux

unread,
Jun 18, 2021, 2:10:51 AM6/18/21
to lescast...@googlegroups.com

Je fais déja du Rust (et j'aime beaucoup ça). Malheureusement, on ne va pas se mentir, les objectifs de sûreté d'exécution et leurs impacts sur le code sont incompatibles avec les applications de gestion qu'on écrit habituellement chez les clients des ESN françaises ...

Quant à Kotlin, j'ai des réserves liées non pas à Ceylon, mais à Groovy, qui faisait déja presque tout ce que fait Kotlin, mais qui semble avoir une mauvaise image auprès des développeurs, pour la raison traditionnelle : ils ont dû en faire sans avoir choisi d'en faire.

matthieu...@gmail.com

unread,
Jun 18, 2021, 3:01:26 AM6/18/21
to lescast...@googlegroups.com
Salut,

On Thu, 2021-06-17 at 19:57 -0700, Cédric Beust ♚ wrote:
> Si tu veux retrouver ton zen, suis mon chemin: Kotlin et Rust.
>
> Ces deux langages sont en train de définir le futur des langages de la
> décennie à venir.  Ce serait super si le podcast leur consacrait un peu
> plus de temps, mais bon, je comprends qu'il y a un peu de "bad blood" à
> cause de Ceylon.

Autant je vois bien ce que Rust apporte, autant Kotlin, j'ai plus de
réserves : le compilateur est très lent (et impossible de savoir
quelles features du langage le mettent en difficulté), les coroutines
c'est beaucoup trop compliqué, le when-expression est vraiment trop
limité, etc.

Bref, je trouve que Kotlin n'est une solution à pas grand chose et je
pense que le futur n'est pas dans un langage qui fait "un peu mieux que
Java".

My 2 cents,

-- Matthieu



Remi Forax

unread,
Jun 18, 2021, 3:18:19 AM6/18/21
to lescastcodeurs
De: "Nicolas Delsaux" <nicolas...@gmx.fr>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Jeudi 17 Juin 2021 18:59:07
Objet: Re: [LCC] LCC 257 - Interview Java 16 avec José Paumard et Henri Tremblay - partie 2

Un épisode particulièrement intéressant.

J'ai beaucoup aimé la râlerie d'Henri contre les modules et l'encapsulation apparue depuis Java 11 parce que, sur deux applications que j'ai migré (une vieillerie Java 6 et un projet open-source qui lance du CDI dans un exec-maven-plugin maven), j'ai été putain de mordu A CHAQUE FOIS par les modules.


C'est le but des modules, c'est un vigile à l'entrée d'une boite et tu as des baskets ...

Plus sérieusement, pour une application, si tu utilises des modules c'est que tu es pret à en payer le cout car ton code est suffisamment compliqué pour que tu ne veuilles pas que n'importe qu'elle partie puisse accéder à n'importe quelle autre partie.
Sinon, arrête d'utiliser des modules, cela ne vaut pas la complexité que tu introduits. Java marche très bien avec les applis PAS modulaire.
Et si tu publies une librarie, la packagée sous forme de module offre que des bénéfices car tu définies plus clairement ce qui est de l'API et de l'implantation dans ton code et si tu dépends d'autres libs, pareil, est ce que tu en dépends en terme d'API ou d'implantation.

Pour ce qui est de CDI, je crois beaucoup plus en l'approche de Quarkus ou maintenant Micronaut, tu fais toutes la partie "bean discovery" à compile time et pas à runtime.
Comme cela, tu as pas besoin de permissions spéciales quand tu exécutes ton code.

Et même si j'ai eu la discussion il y a des années à Devoxx avec Rémi, le fait que, pour des raisons politiques, Oracle ait remplacé OSGi par une solution à moitié aussi subtile, et offrant le quart des fonctionnalités, ben franchement, pour les modules, je suis clairement dans la team "jamais de modules dans mon code".


Cela c'est pas passé comme cela, Oracle a payé 2 ingés, Alan Bateman et Mandy Chung, pendant 3 mois pour faire un proto de modules qui bootait le JDK basé sur OSGi.
Après, ironiquement vu de maintenant, il y a eu une bataille rangée entre RedHat qui était furieusement contre et IBM.
Je suis arrivé dans le projet a ce moment là, j'avais l'impression d'être à la maternelle.
La vrai décision de ne pas poursuivre dans cette voie est venu du fait que tous les autres systèmes de module déjà existant ne fonctionnaient pas sur le prototype.


Et va-t-en lire le blog de Nicolai Parlog qui te donne des astuces louches pour faire marcher maven à grands coups de fichiers non documentés (là : https://nipafx.dev/maven-on-java-9/).


C'est plus un truc historique qu'autre chose, il veut faire marcher Maven avec Java 9 avant que Maven ait été patché pour Java 9.

Et va-t-en découvrir la "magie" des split packages avec des messages de compilation pénibles. A ce sujet, je trouve que les équipes qui font évoluer le JDK devraient se soucier un poil plus de l'expérience développeur en s'inspirant, par exemple, de ce que font les gens de Rust.


Heu tu veux parler d'Elm ici, non.
Pour l'anectote, il a 2 semaine, j'ai passé une demi journée avec un prof de système sur une page de Rust, l'idée était juste de pouvoir de façon asynchrone arréter une tâche asynchrone, bah c'est super dure.
Je sais que je vis un peu dans le futur mais avec Loom c'est un try() et c'est fini.


Et va-t-en découvrir que les dernières versions du JDK virent des classes comme s'il en pleuvaient. sur ce point spécifique, ça me rend dingue : pendant mes quinze premières années de développeur Java, je pouvais passer d'une version à la suivante limite les yeux fermés. Et maintenant, comme on est dans l'informatique en tant que mode, il faut absolument supprimer chaque référence au mot XML. Et du coup aux saloperies SOAP. Alors d'accord, c'était de la merde, mais on se retrouve avec des migrations poussées de force dans lesquelles on perd en features. Et ça, c'est fatiguant.


Je suppose que tu parles du fait que JAXB est plus intégré avec le JDK et que tu as besoin de l'ajouter en dépendance dans ton pom.xml.
Pour ce qui est des parsers XML, de ce que j'ai compris, le gars qui fait principalement la maintenance dessus il est payé par Oracle dans le cadre de l'OpenJDK.

Oui, je râle fort. Mais c'est parce que j'aime beaucoup continuer à bosser en Java, et je n'aime spécialement pas l'idée de ce tweet https://twitter.com/scanlime/status/1405259826964307970 (je cite "went from a dream of "write once, run anywhere" to "write yearly, runs in chrome") que semble adopter même l'équipe définissant les évolutions.


Twitter a pas fini son évolution, il manque la feature "virtual friend TM" qui te permet de ventiler comme d'hab sur Twitter sans embéter les vrai gens, actuellement tu as seulement 50% des folowers qui sont des bots.

En tout cas, encore merci pour le podcast, et pour les notes de Rémi !


Rémi


Le 07/06/2021 à 10:38, Emmanuel Bernard a écrit :
José (maintenant Java Advocate chez Oracle - le cachotier) et Henri échangent avec Emmanuel sur la sortie de Java 16.
Cette deuxième partie voit l'équipe discuter de la propriété illegal access (JEP 396), de l'API vectorielle, de la foreign linker API et d'autres choses.


Emmanuel
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjK%3DZcmix356actOb3r4NqNBkK39WOGU0SvYZYkDhBqfng%40mail.gmail.com.
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

Nicolas Delsaux

unread,
Jun 18, 2021, 4:30:04 AM6/18/21
to lescast...@googlegroups.com


Le 18/06/2021 à 09:18, Remi Forax a écrit :

J'ai beaucoup aimé la râlerie d'Henri contre les modules et l'encapsulation apparue depuis Java 11 parce que, sur deux applications que j'ai migré (une vieillerie Java 6 et un projet open-source qui lance du CDI dans un exec-maven-plugin maven), j'ai été putain de mordu A CHAQUE FOIS par les modules.


C'est le but des modules, c'est un vigile à l'entrée d'une boite et tu as des baskets ...

Plus sérieusement, pour une application, si tu utilises des modules c'est que tu es pret à en payer le cout car ton code est suffisamment compliqué pour que tu ne veuilles pas que n'importe qu'elle partie puisse accéder à n'importe quelle autre partie.
Sinon, arrête d'utiliser des modules, cela ne vaut pas la complexité que tu introduits. Java marche très bien avec les applis PAS modulaire.


Il y a une doc lisible qui explique comment dire à Java "n'utilise pas les modules dans ce cas" ?


Pour ce qui est de CDI, je crois beaucoup plus en l'approche de Quarkus ou maintenant Micronaut, tu fais toutes la partie "bean discovery" à compile time et pas à runtime.
Comme cela, tu as pas besoin de permissions spéciales quand tu exécutes ton code.

Moi aussi, mais on commence à avoir un poids de l'existant assez fort. Et pour l'instant, je me vois mal réécrire mon bout de code qui me génère une doc d'architecture sympa avec Quarkus/Micronaut (quoique dans la mesure où Quarkus implémente une part significative de CDI https://quarkus.io/guides/cdi-reference, ça me semble possible, faudrait que je teste).


Et même si j'ai eu la discussion il y a des années à Devoxx avec Rémi, le fait que, pour des raisons politiques, Oracle ait remplacé OSGi par une solution à moitié aussi subtile, et offrant le quart des fonctionnalités, ben franchement, pour les modules, je suis clairement dans la team "jamais de modules dans mon code".


Cela c'est pas passé comme cela, Oracle a payé 2 ingés, Alan Bateman et Mandy Chung, pendant 3 mois pour faire un proto de modules qui bootait le JDK basé sur OSGi.
Après, ironiquement vu de maintenant, il y a eu une bataille rangée entre RedHat qui était furieusement contre et IBM.
Je suis arrivé dans le projet a ce moment là, j'avais l'impression d'être à la maternelle.


Ca s'appelle la politique, ça, non ? 😋



Et va-t-en lire le blog de Nicolai Parlog qui te donne des astuces louches pour faire marcher maven à grands coups de fichiers non documentés (là : https://nipafx.dev/maven-on-java-9/).


C'est plus un truc historique qu'autre chose, il veut faire marcher Maven avec Java 9 avant que Maven ait été patché pour Java 9.


Beeeeen quand tu migres un vieux projet, tu en passes par ces trucs louches.


Et va-t-en découvrir la "magie" des split packages avec des messages de compilation pénibles. A ce sujet, je trouve que les équipes qui font évoluer le JDK devraient se soucier un poil plus de l'expérience développeur en s'inspirant, par exemple, de ce que font les gens de Rust.


Heu tu veux parler d'Elm ici, non.
Pour l'anectote, il a 2 semaine, j'ai passé une demi journée avec un prof de système sur une page de Rust, l'idée était juste de pouvoir de façon asynchrone arréter une tâche asynchrone, bah c'est super dure.
Je sais que je vis un peu dans le futur mais avec Loom c'est un try() et c'est fini.


Non, je n'ai pas été clair.

Je voulais parler de la lisibilité des messages d'erreur. L'un des gros avantages de Rust, c'est que les messages d'erreurs sont bien plus clairs que ... dans tous les autres langages que je connaisse, en fait. A chaque fois, il t'explique où ça a merdé, pourquoi ça a merdé, et essaye de te proposer une solution.

Et typiquement, pour les split packages, j'ai bien l'impression qu'il est possible à la JVM de me dire "je ne démarre pas parce que le package A est défini dans bidule.jar et machin.jar. Essaye de renommer tes packages ou relance ton appli sans les fonctionnalités de modules"



Et va-t-en découvrir que les dernières versions du JDK virent des classes comme s'il en pleuvaient. sur ce point spécifique, ça me rend dingue : pendant mes quinze premières années de développeur Java, je pouvais passer d'une version à la suivante limite les yeux fermés. Et maintenant, comme on est dans l'informatique en tant que mode, il faut absolument supprimer chaque référence au mot XML. Et du coup aux saloperies SOAP. Alors d'accord, c'était de la merde, mais on se retrouve avec des migrations poussées de force dans lesquelles on perd en features. Et ça, c'est fatiguant.


Je suppose que tu parles du fait que JAXB est plus intégré avec le JDK et que tu as besoin de l'ajouter en dépendance dans ton pom.xml.

Exactement ça.

A chaque fois je trouve les chemins de migration. Mais je ronchonne parce que la migration vers les nouvelles versions commence à bien piquer.

Remi Forax

unread,
Jun 18, 2021, 5:36:56 AM6/18/21
to lescastcodeurs


De: "Nicolas Delsaux" <nicolas...@gmx.fr>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Vendredi 18 Juin 2021 10:30:00
Objet: Re: [LCC] LCC 257 - Interview Java 16 avec José Paumard et Henri Tremblay - partie 2
Le 18/06/2021 à 09:18, Remi Forax a écrit :

J'ai beaucoup aimé la râlerie d'Henri contre les modules et l'encapsulation apparue depuis Java 11 parce que, sur deux applications que j'ai migré (une vieillerie Java 6 et un projet open-source qui lance du CDI dans un exec-maven-plugin maven), j'ai été putain de mordu A CHAQUE FOIS par les modules.


C'est le but des modules, c'est un vigile à l'entrée d'une boite et tu as des baskets ...

Plus sérieusement, pour une application, si tu utilises des modules c'est que tu es pret à en payer le cout car ton code est suffisamment compliqué pour que tu ne veuilles pas que n'importe qu'elle partie puisse accéder à n'importe quelle autre partie.
Sinon, arrête d'utiliser des modules, cela ne vaut pas la complexité que tu introduits. Java marche très bien avec les applis PAS modulaire.


Il y a une doc lisible qui explique comment dire à Java "n'utilise pas les modules dans ce cas" ?


Si ton jar est dans le classpath et pas dans le modulepath alors le module-info est pas lu.

Le truc est que par defaut Maven met tous les jars qui ont un module-info.class dans le modulepath et je sais pas si on peut changer ce comportement.
Au moins avec Gradle, tu actives ce comportement avec "modularity.inferModulePath = true", donc tu peux décider plus finement quel jar va où.



Pour ce qui est de CDI, je crois beaucoup plus en l'approche de Quarkus ou maintenant Micronaut, tu fais toutes la partie "bean discovery" à compile time et pas à runtime.
Comme cela, tu as pas besoin de permissions spéciales quand tu exécutes ton code.

Moi aussi, mais on commence à avoir un poids de l'existant assez fort. Et pour l'instant, je me vois mal réécrire mon bout de code qui me génère une doc d'architecture sympa avec Quarkus/Micronaut (quoique dans la mesure où Quarkus implémente une part significative de CDI https://quarkus.io/guides/cdi-reference, ça me semble possible, faudrait que je teste).

Et même si j'ai eu la discussion il y a des années à Devoxx avec Rémi, le fait que, pour des raisons politiques, Oracle ait remplacé OSGi par une solution à moitié aussi subtile, et offrant le quart des fonctionnalités, ben franchement, pour les modules, je suis clairement dans la team "jamais de modules dans mon code".


Cela c'est pas passé comme cela, Oracle a payé 2 ingés, Alan Bateman et Mandy Chung, pendant 3 mois pour faire un proto de modules qui bootait le JDK basé sur OSGi.
Après, ironiquement vu de maintenant, il y a eu une bataille rangée entre RedHat qui était furieusement contre et IBM.
Je suis arrivé dans le projet a ce moment là, j'avais l'impression d'être à la maternelle.


Ca s'appelle la politique, ça, non ? \uD83D\uDE0B


Tu triches, tu as coupé la ligne suivante
"La vrai décision de ne pas poursuivre dans cette voie est venu du fait que tous les autres systèmes de module déjà existant ne fonctionnaient pas sur le prototype."

Et va-t-en lire le blog de Nicolai Parlog qui te donne des astuces louches pour faire marcher maven à grands coups de fichiers non documentés (là : https://nipafx.dev/maven-on-java-9/).


C'est plus un truc historique qu'autre chose, il veut faire marcher Maven avec Java 9 avant que Maven ait été patché pour Java 9.


Beeeeen quand tu migres un vieux projet, tu en passes par ces trucs louches.


Et va-t-en découvrir la "magie" des split packages avec des messages de compilation pénibles. A ce sujet, je trouve que les équipes qui font évoluer le JDK devraient se soucier un poil plus de l'expérience développeur en s'inspirant, par exemple, de ce que font les gens de Rust.


Heu tu veux parler d'Elm ici, non.
Pour l'anectote, il a 2 semaine, j'ai passé une demi journée avec un prof de système sur une page de Rust, l'idée était juste de pouvoir de façon asynchrone arréter une tâche asynchrone, bah c'est super dure.
Je sais que je vis un peu dans le futur mais avec Loom c'est un try() et c'est fini.


Non, je n'ai pas été clair.

Je voulais parler de la lisibilité des messages d'erreur. L'un des gros avantages de Rust, c'est que les messages d'erreurs sont bien plus clairs que ... dans tous les autres langages que je connaisse, en fait. A chaque fois, il t'explique où ça a merdé, pourquoi ça a merdé, et essaye de te proposer une solution.

Et typiquement, pour les split packages, j'ai bien l'impression qu'il est possible à la JVM de me dire "je ne démarre pas parce que le package A est défini dans bidule.jar et machin.jar. Essaye de renommer tes packages ou relance ton appli sans les fonctionnalités de modules"


Sauf que la "vrai" façon de résoudre le problème se fait au niveau de l'outil de build et que en Java, "l'outil de build" est pas intégré au langage. Rust à actuellement l'avantage d'avoir cargo comme seul et unique outil de build. Mais dans 10 ou 20 ans, cela risque de leur poser problème car un outil de build cela se périme vite.
Si Java était arrivé avec un outil de build, on aurait eu "ant" pour tout le monde :(




Et va-t-en découvrir que les dernières versions du JDK virent des classes comme s'il en pleuvaient. sur ce point spécifique, ça me rend dingue : pendant mes quinze premières années de développeur Java, je pouvais passer d'une version à la suivante limite les yeux fermés. Et maintenant, comme on est dans l'informatique en tant que mode, il faut absolument supprimer chaque référence au mot XML. Et du coup aux saloperies SOAP. Alors d'accord, c'était de la merde, mais on se retrouve avec des migrations poussées de force dans lesquelles on perd en features. Et ça, c'est fatiguant.


Je suppose que tu parles du fait que JAXB est plus intégré avec le JDK et que tu as besoin de l'ajouter en dépendance dans ton pom.xml.

Exactement ça.

A chaque fois je trouve les chemins de migration. Mais je ronchonne parce que la migration vers les nouvelles versions commence à bien piquer.


Oui, mais ça a été une belle connerie d'ajouter des packages javax.pouet à Java 4 et 6.
Car 10 ans plus tard, tu dois maintenir des trucs que les gens utilisent plus.

Perso, je pense que c'est assez saint pour un langage de ne pas s'encrouter avec des packages qui correspond plus au standard de l'industrie du moment.

Enfin, pour ce qui est de la migration, je trouve le guide de migration à Java 11 est bien fait

Et pour les dépendances qui n'existe plus, utilise jdeps comme marqué dans le quide, l'outils a des beaux messages qui t'explique comment upgrader.

De façon général, configure ton CI pour pendre la dernier release de Java et fait tourner jdeps et jdeprscan sur ton code,
même si tu essayes pas de compiler ton code avec la nouvelle version, au moins tu as une bonne idée de la complexité de la migration à la prochaine LTS.

Rémi

Emmanuel Bernard

unread,
Jun 18, 2021, 8:13:26 AM6/18/21
to lescast...@googlegroups.com
Ce n'est pas une question de ressentiment, c'est une question d'usage et de visibilité des hôtes sur ces technologies.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAOphgJBaMr%3DvOyRwA6JxGMo4dXabYOUgosj_RrFMjY7mnoCbdQ%40mail.gmail.com.

Cédric Beust ♚

unread,
Jun 18, 2021, 2:35:20 PM6/18/21
to lescastcodeurs
Mais vous parlez de Javascript tout le temps !  :-)

-- 
Cédric


Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEW2Rj%2B6vhnL96EFA19KifYBrwDcm_pvOgRzZrmmeV%3Dckv1mog%40mail.gmail.com.

Arnaud Héritier

unread,
Jun 18, 2021, 2:44:52 PM6/18/21
to lescast...@googlegroups.com
🤣😘

--
Arnaud Héritier
Twitter/Skype : aheritier

Guillaume Laforge

unread,
Jun 18, 2021, 3:57:22 PM6/18/21
to lescast...@googlegroups.com
C'est comme Java, non ? 😂

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAFNCU-9nbR-s9hMg7OW7S4WggZRsDfACFwT4PNVabhHUq1UTKg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages