JEP 396 - Oh oui, fait moi mal

[Remi Forax]

En bon sadique que nous sommes, voilà la JEP qui annonce que les accès par réflection aux classes internes du JDK (sun.misc.Unsafe mis à part)
ne font plus un warning mais une erreur par défaut.

https://openjdk.java.net/jeps/396

Rémi

[Henri Tremblay]

Je suis mieux de me mettre à Rust au plus vite, la fin de Java est proche.

Je plaisante à peine.

Je sais que c'est un sujet qui te tient à coeur Rémi, donc je vais être sage.

Mais je demeure convaincu  que la seule raison qui empêche les gens de passer à Java 11, c'est de ne pas être Open to reflection par défaut.

La seule.

Par exemple, j'ai essayé. On a commencé et on s'est brûlé les doigts. En production. Et qu'il n'y a pas de solution.

Dès que tu as un framework qui fait de la réflection tu ne sais jamais s'il va toucher quelque chose d'interdit.

Et pire de pire, avec les modules layers, tu ne peux même pas corriger un coup que tu es tombé dessus.

Quand ta solution c'est de mettre un agent qui met tout en open pour que ça tourne sans danger, tu nages dans le ridicule.

Je suis aussi triste que la JSR dont le numéro m'échappe que voulait Aleksey pour faire des sizeof ne semble pas aller nulle part.

--
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/1557653924.917083.1603821843535.JavaMail.zimbra%40u-pem.fr.

[Cédric Beust ♔]

Rémi, Rémi, ton orthographe... :-(

"Fais-moi mal".

Enfin bref.

Je pense que le principal obstacle pour la lenteur à mettre à jour au-delà de Java 8 n'est pas vraiment sur la réflection des classes internes du JDK mais simplement sur la pilule à avaler sur les modules. Je sais, pour toi et Brian, c'est de l'histoire ancienne, mais c'est une réalité qui est difficile à contourner dans l'industrie...

-- 

Cédric

[Frédéric Camblor]

Ouïe ça va piquer ce changement, vraiment fort.

@Remi à partir de quel statut décide-t-on / connaît-on la version de Java dans laquelle une JEP est prévue d'être implantée ? (j'imagine qu'il est encore bien trop tôt pour en parler concernant cette JEP créée il y a 5j)

Par rapport à l'adoption de Java 11, c'est assez simple pour moi : l'adoption d'une nouvelle version de Java se fait par le bas (par les développeurs applicatifs, voire parfois de librairies) et non par le haut (business / ops).

Apportez une grosse plu-value au quotidien du développeur, vous aurez une adoption massive (Java 5 avec les generics, Java 7 avec les I/O, try-with-resources et coin, Java 8 avec les lambda).

Quand les versions n'apportent que peu de plu value (Java 6) voire des contraintes (Java 9 [1]), cela freine nécessairement l'adoption... et ce n'est pas l'introduction de var qui va contrebalancer les contraintes introduites dans Java 9.

De plus, depuis le changement de fréquence de release, les développeurs mettent évidemment le focus sur les versions LTS pour pas avoir à migrer trop souvent (il faut donc mettre dans la balance toutes les plu-values vs toutes les contraintes apparues entre 2 LTS).

Si ma théorie se confirme, Java 17 avec les Records devrait être plus largement adoptée ... sauf s'il y a des contraintes (comme cette JEP, qui en est une grosse de mon point de vue) dedans.

[1] D'autant que ces contraintes impactent à la fois les développeurs de librairies (en tant que producteurs) et les développeurs d'applications (en tant que consommateurs).

My 2 cents,

Frédéric Camblor  

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

[Arnaud Héritier]

J'imagine/espère qu'une JEP aussi risquée n'arrivera pas directement dans une LTS.

Il faudrait qu'elle arrive en 18 pour être LTS en 23 pour donner assez de temps à la communauté pour prendre les décisions adaptées

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

--

Arnaud Héritier

Twitter/Skype : aheritier

[Remi Forax]

De: "Henri Tremblay" <henri.t...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mercredi 28 Octobre 2020 01:29:24
Objet: Re: [LCC] JEP 396 - Oh oui, fait moi mal

Je suis mieux de me mettre à Rust au plus vite, la fin de Java est proche.

Mauvais exemple, Rust est incompatible tous les 3 ans (2015, 2018, 2021, etc),

pour la petite histoire, un code que j'avais écrit avec la version 1.0 ne marchait pas avec la version 2018 car try est devenu un mot clé [1]

Je plaisante à peine.

Je sais que c'est un sujet qui te tient à coeur Rémi, donc je vais être sage.

C'est juste qu'il y a toujours deux cotés à une histoire,

effectivement, cela veut dire que tu ne peux accéder à l'état des classes internes du JDK comme tu veux,

mais de l'autre coté sans ça, Loom ne progresserait pas aussi vite, une des parties de Loom est de ré-écrire tous les IO/Socket etc pour qu'il marche en non bloquant, forcément cela change le code interne du JDK.

Si n'importe qu'elle librarie peut accéder au code interne du JDK alors ré-écrire le code pour Loom devient beaucoup plus difficile.

L'idée c'est "Move Fast and Break JDK Internals".

Mais je demeure convaincu  que la seule raison qui empêche les gens de passer à Java 11, c'est de ne pas être Open to reflection par défaut.

La seule.

Par exemple, j'ai essayé. On a commencé et on s'est brûlé les doigts. En production. Et qu'il n'y a pas de solution.

Ajoute les --add-exports/--add-opens qui vont bien sur la ligne de commande, c'est ce que j'ai fait pour le soft qui compile du Java pour les briques légos, car Lego supporte plus leur soft sur les anciennes briques.

Je dirais pas que c'est beau mais c'est très mécanique, tu lances le soft, il te fait des warnings, tu copies/colle les --add-machin qui est écrit.

Dès que tu as un framework qui fait de la réflection tu ne sais jamais s'il va toucher quelque chose d'interdit.

Et pire de pire, avec les modules layers, tu ne peux même pas corriger un coup que tu es tombé dessus.

Quand ta solution c'est de mettre un agent qui met tout en open pour que ça tourne sans danger, tu nages dans le ridicule.

sinon, tu peux toujours écrire --illegal-access="warn" (ou même "permit" si tu veux être en mode Java 8), ce que dit la JEP c'est j que maintenant le defaut est plus "warn" mais "deny".

Je suis aussi triste que la JSR dont le numéro m'échappe que voulait Aleksey pour faire des sizeof ne semble pas aller nulle part.

Je pense pas qu'elle aille nulle part, Mais Aleksey a oublié la rêgle numéro 1 pour ce genre de JSR, commencer par discuter sur la mailing list pour avoir une sorte de concensus avant d'écrire le code. Là on est partie pour 120 aller/retours.

Rémi

[1] https://doc.rust-lang.org/nightly/edition-guide/rust-2018/edition-changes.html

On Tue, 27 Oct 2020 at 14:04, Remi Forax <fo...@univ-mlv.fr> wrote:

En bon sadique que nous sommes, voilà la JEP qui annonce que les accès par réflection aux classes internes du JDK (sun.misc.Unsafe mis à part)
ne font plus un warning mais une erreur par défaut.

  https://openjdk.java.net/jeps/396

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.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/1557653924.917083.1603821843535.JavaMail.zimbra%40u-pem.fr.

--
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/CADZL2%3Dt_OrT8tsjNXfsYFggT-rObErYVtZo2G0Gwvwi63kwkzA%40mail.gmail.com.

[Remi Forax]

De: "Cédric Beust" <ced...@beust.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mercredi 28 Octobre 2020 03:19:53
Objet: Re: [LCC] JEP 396 - Oh oui, fait moi mal

Rémi, Rémi, ton orthographe... :-(

"Fais-moi mal".

Enfin bref.

Je pense que le principal obstacle pour la lenteur à mettre à jour au-delà de Java 8 n'est pas vraiment sur la réflection des classes internes du JDK mais simplement sur la pilule à avaler sur les modules. Je sais, pour toi et Brian, c'est de l'histoire ancienne, mais c'est une réalité qui est difficile à contourner dans l'industrie...

Brian a pas vraiment participer aux modules, c'est un truc de la plateforme pas du langage, donc le mec qui s'en occupe chez Oracle c'est Mark Reinhold, pas Brian.

Tu as raison que réfléchir en terme de module est plus compliqué surtout si tu avais pas à le faire avant mais réfléchir en terme de module ça évite le d'avoir un sac de noeuds en terme de dépendances et c'est moins pire que réfléchir en terme de micro-service :)

Et si tu écrits une appli pas une librarie, le seul problème qui reste c'est certaines librariess dont tu dépends qui utilise la reflections sur les classes internes du JDK et qui n'ont pas été mis à jour.

Le fait que et l'écosystème Spring, JBoss/Quarkus ou IntelliJ marche avec Java 11 à rêgler pas mal de problème , par exemple, mes étudiants ont aucun problème à utiliser Java 11/Java 15 mais tu peux toujours tomber sur une lib pas mis à jour.

-- 

Cédric

Rémi

On Tue, Oct 27, 2020 at 11:04 AM Remi Forax <fo...@univ-mlv.fr> wrote:

En bon sadique que nous sommes, voilà la JEP qui annonce que les accès par réflection aux classes internes du JDK (sun.misc.Unsafe mis à part)
ne font plus un warning mais une erreur par défaut.

  https://openjdk.java.net/jeps/396

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.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/1557653924.917083.1603821843535.JavaMail.zimbra%40u-pem.fr.

--
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/CAOphgJD%3DGNV_u5JysWsL9%2BmzgnBN7zix9k2_g7i%2BvfS9W5NOsA%40mail.gmail.com.

[Remi Forax]

De: "Frédéric Camblor" <fcam...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mercredi 28 Octobre 2020 08:40:33
Objet: Re: [LCC] JEP 396 - Oh oui, fait moi mal

Ouïe ça va piquer ce changement, vraiment fort.

@Remi à partir de quel statut décide-t-on / connaît-on la version de Java dans laquelle une JEP est prévue d'être implantée ? (j'imagine qu'il est encore bien trop tôt pour en parler concernant cette JEP créée il y a 5j)

Mark Reinhold propose que la JEP soit target pour une version de Java et à parir de là il y a 2 semaines de discussion possible.

Je pense qu'il est raisonnable d'inclure cette JEP dans Java 16, avant Java 17 la LTS, sinon cela veut dire que le même problème se reposera dans 3 ans.

Par rapport à l'adoption de Java 11, c'est assez simple pour moi : l'adoption d'une nouvelle version de Java se fait par le bas (par les développeurs applicatifs, voire parfois de librairies) et non par le haut (business / ops).

Apportez une grosse plu-value au quotidien du développeur, vous aurez une adoption massive (Java 5 avec les generics, Java 7 avec les I/O, try-with-resources et coin, Java 8 avec les lambda).

Quand les versions n'apportent que peu de plu value (Java 6) voire des contraintes (Java 9 [1]), cela freine nécessairement l'adoption... et ce n'est pas l'introduction de var qui va contrebalancer les contraintes introduites dans Java 9.

De plus, depuis le changement de fréquence de release, les développeurs mettent évidemment le focus sur les versions LTS pour pas avoir à migrer trop souvent (il faut donc mettre dans la balance toutes les plu-values vs toutes les contraintes apparues entre 2 LTS).

Si ma théorie se confirme, Java 17 avec les Records devrait être plus largement adoptée ... sauf s'il y a des contraintes (comme cette JEP, qui en est une grosse de mon point de vue) dedans.

oui,

à ce jour la release qui a été adopté le plus rapidement (et de loin) c'est Java 8, avec les lambdas/stream. La seconde c'est  Java 6, car il n'y avait presque aucun changement par rapport à Java 5.

Ca ne me dérange pas que Java 17 soit pas adopté rapidement,

si tu regardes en Java en terme de langage, on fait une revolution tous les 10 ans,

Java 1 (OOP en 1995), Java 5 (generics en 2004), Java 8 (lambda en 2014) et donc la prochaine c'est Java 23 (pattern matching en 2024).

[1] D'autant que ces contraintes impactent à la fois les développeurs de librairies (en tant que producteurs) et les développeurs d'applications (en tant que consommateurs).

My 2 cents,

Frédéric Camblor 

Rémi

On Wed, Oct 28, 2020 at 3:20 AM Cédric Beust ♔ <ced...@beust.com> wrote:

Rémi, Rémi, ton orthographe... :-(

"Fais-moi mal".

Enfin bref.

Je pense que le principal obstacle pour la lenteur à mettre à jour au-delà de Java 8 n'est pas vraiment sur la réflection des classes internes du JDK mais simplement sur la pilule à avaler sur les modules. Je sais, pour toi et Brian, c'est de l'histoire ancienne, mais c'est une réalité qui est difficile à contourner dans l'industrie...

-- 

Cédric

On Tue, Oct 27, 2020 at 11:04 AM Remi Forax <fo...@univ-mlv.fr> wrote:

En bon sadique que nous sommes, voilà la JEP qui annonce que les accès par réflection aux classes internes du JDK (sun.misc.Unsafe mis à part)
ne font plus un warning mais une erreur par défaut.

  https://openjdk.java.net/jeps/396

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.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/1557653924.917083.1603821843535.JavaMail.zimbra%40u-pem.fr.

--
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/CAOphgJD%3DGNV_u5JysWsL9%2BmzgnBN7zix9k2_g7i%2BvfS9W5NOsA%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.

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

[Remi Forax]

De: "Arnaud Heritier" <aher...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mercredi 28 Octobre 2020 08:48:24
Objet: Re: [LCC] JEP 396 - Oh oui, fait moi mal

J'imagine/espère qu'une JEP aussi risquée n'arrivera pas directement dans une LTS.

Il faudrait qu'elle arrive en 18 pour être LTS en 23 pour donner assez de temps à la communauté pour prendre les décisions adaptées

Pour moi,

cela repousse juste le problème de 3 ans, je pense que avoir Java 11 avec des warnings par défaut et Java 17 avec des erreurs pas défaut me semble pas déconant.

Rémi

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAFNCU-__%3D8E3Rd4F0Sv4tMHtd-unX41BmzbgsieQ%2BSVXZuNaxg%40mail.gmail.com.

[Frédéric Camblor]

> Il faudrait qu'elle arrive en 18 pour être LTS en 23 pour donner assez de temps à la communauté pour prendre les décisions adaptées

>> cela repousse juste le problème de 3 ans, je pense que avoir Java 11 avec des warnings par défaut et Java 17 avec des erreurs pas défaut me semble pas déconant.

Perso, je suis plutôt d'accord avec Arnaud : des changements aussi structurants qui vont péter toutes les libs de l'écosystème (exactement comme toutes les libs ont pété avec le pruning des classes type sun.misc.Unsafe) ne doivent pas arriver dans la version juste avant la LTS.

... ou alors cette LTS sera jamais (ou très très lentement) adoptée, comme Java 11.

A contrario, si ça arrive en Java 20, ça laisse 3 ans aux libs pour s'aligner sur ce changement majeur ... c'est mettre l'écosystème dans une bien meilleure posture que l'introduire au dernier moment.

my 2c

Frédéric Camblor  

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

[Matthieu Baechler]

Salut,

On Wed, Oct 28, 2020 at 1:59 PM Frédéric Camblor <fcam...@gmail.com> wrote:

> Il faudrait qu'elle arrive en 18 pour être LTS en 23 pour donner assez de temps à la communauté pour prendre les décisions adaptées

>> cela repousse juste le problème de 3 ans, je pense que avoir Java 11 avec des warnings par défaut et Java 17 avec des erreurs pas défaut me semble pas déconant.

Perso, je suis plutôt d'accord avec Arnaud : des changements aussi structurants qui vont péter toutes les libs de l'écosystème (exactement comme toutes les libs ont pété avec le pruning des classes type sun.misc.Unsafe) ne doivent pas arriver dans la version juste avant la LTS.

Sur ce point je suis assez d'accord, surtout pour éviter de faire des choses qu'on regrette ensuite. Le passage par un stade expérimental me semble important pour affiner les solutions.

 

... ou alors cette LTS sera jamais (ou très très lentement) adoptée, comme Java 11.

A contrario, si ça arrive en Java 20, ça laisse 3 ans aux libs pour s'aligner sur ce changement majeur ... c'est mettre l'écosystème dans une bien meilleure posture que l'introduire au dernier moment.

Sur ce point je suis plutôt en désaccord.

Dans le cas où ça vient dans une LTS rapidement, on va avoir une phase où tout ne sera pas prêt et donc une adoption progressive mais qui démarre maintenant.

Dans le cas où le changement est reporté à la prochaine LTS, le plus probable c'est que tout l'écosystème attende la LTS et l'adoption sera également progressive, mais avec un démarrage qui intervient 3 ans plus tard.

-- Matthieu Baechler

[Arnaud Héritier]

je comprends très bien que ça n'est qu'une valeur par défaut et que l'on peut mettre le switch qui va bien dans la JVM pour repasser en mode warning mais par défaut ça ne va plus marcher et j'ai peur que cela redonne un gros coup de frein à la communauté quand les "late adopters" vont jeter un oeil à la LTS 17 et qui vont juste voir que ça ne marche pas par défaut et ne vont pas trop chercher si c'est compliqué à fixer ou pas.

J'avoue que perso je vois les warnings 100 fois par jour et je n'y fais même plus attention

WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.findLoadedClass(java.lang.String)

WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)

WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.resolveClass(java.lang.Class)

--
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/CAPd7dr1iVnd%2BKCuoRp3XJyHWaENuMFC1Bnvj0LnqTOQ88Nk3jg%40mail.gmail.com.

[Remi Forax]

---

De: "Arnaud Heritier" <aher...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mercredi 28 Octobre 2020 15:42:12
Objet: Re: [LCC] JEP 396 - Oh oui, fait moi mal

je comprends très bien que ça n'est qu'une valeur par défaut et que l'on peut mettre le switch qui va bien dans la JVM pour repasser en mode warning mais par défaut ça ne va plus marcher et j'ai peur que cela redonne un gros coup de frein à la communauté quand les "late adopters" vont jeter un oeil à la LTS 17 et qui vont juste voir que ça ne marche pas par défaut et ne vont pas trop chercher si c'est compliqué à fixer ou pas.

J'avoue que perso je vois les warnings 100 fois par jour et je n'y fais même plus attention

WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.findLoadedClass(java.lang.String)

WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)

WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.resolveClass(java.lang.Class)

Tu dis toi même que tu fais pas attention aux warnings, je pense pas que la solution soit garder les warnings ad vitam erternam, sachant qu'à un moment, le code de java.lang.ClassLoader va bien devoir être changé.

Sinon, lire l'issue correspondante est assez intéressante

https://github.com/FasterXML/jackson-modules-base/issues/37

Rémi

On Wed, Oct 28, 2020 at 3:07 PM Matthieu Baechler <matthieu...@gmail.com> wrote:

Salut,

On Wed, Oct 28, 2020 at 1:59 PM Frédéric Camblor <fcam...@gmail.com> wrote:

> Il faudrait qu'elle arrive en 18 pour être LTS en 23 pour donner assez de temps à la communauté pour prendre les décisions adaptées

>> cela repousse juste le problème de 3 ans, je pense que avoir Java 11 avec des warnings par défaut et Java 17 avec des erreurs pas défaut me semble pas déconant.

Perso, je suis plutôt d'accord avec Arnaud : des changements aussi structurants qui vont péter toutes les libs de l'écosystème (exactement comme toutes les libs ont pété avec le pruning des classes type sun.misc.Unsafe) ne doivent pas arriver dans la version juste avant la LTS.

Sur ce point je suis assez d'accord, surtout pour éviter de faire des choses qu'on regrette ensuite. Le passage par un stade expérimental me semble important pour affiner les solutions.

 

... ou alors cette LTS sera jamais (ou très très lentement) adoptée, comme Java 11.

A contrario, si ça arrive en Java 20, ça laisse 3 ans aux libs pour s'aligner sur ce changement majeur ... c'est mettre l'écosystème dans une bien meilleure posture que l'introduire au dernier moment.

Sur ce point je suis plutôt en désaccord.

Dans le cas où ça vient dans une LTS rapidement, on va avoir une phase où tout ne sera pas prêt et donc une adoption progressive mais qui démarre maintenant.

Dans le cas où le changement est reporté à la prochaine LTS, le plus probable c'est que tout l'écosystème attende la LTS et l'adoption sera également progressive, mais avec un démarrage qui intervient 3 ans plus tard.

-- Matthieu Baechler

--
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/CAPd7dr1iVnd%2BKCuoRp3XJyHWaENuMFC1Bnvj0LnqTOQ88Nk3jg%40mail.gmail.com.

--

Arnaud Héritier

Twitter/Skype : aheritier

--
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/CAFNCU-9UzeP9Qf1UTQjXj5-zkgkgqggwkGCtPBZ%2BSHZyjgrbjA%40mail.gmail.com.

[Vincent Massol]

> On 28 Oct 2020, at 15:59, Remi Forax <fo...@univ-mlv.fr> wrote:
>
>
>
> De: "Arnaud Heritier" <aher...@gmail.com>
> À: "lescastcodeurs" <lescast...@googlegroups.com>
> Envoyé: Mercredi 28 Octobre 2020 15:42:12
> Objet: Re: [LCC] JEP 396 - Oh oui, fait moi mal
> je comprends très bien que ça n'est qu'une valeur par défaut et que l'on peut mettre le switch qui va bien dans la JVM pour repasser en mode warning mais par défaut ça ne va plus marcher et j'ai peur que cela redonne un gros coup de frein à la communauté quand les "late adopters" vont jeter un oeil à la LTS 17 et qui vont juste voir que ça ne marche pas par défaut et ne vont pas trop chercher si c'est compliqué à fixer ou pas.
> J'avoue que perso je vois les warnings 100 fois par jour et je n'y fais même plus attention
>
> WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.findLoadedClass(java.lang.String)
> WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
> WARNING: Illegal reflective access by com.fasterxml.jackson.module.afterburner.util.MyClassLoader (file:/Users/arnaud/.m2/repository/com/fasterxml/jackson/module/jackson-module-afterburner/2.11.3/jackson-module-afterburner-2.11.3.jar) to method java.lang.ClassLoader.resolveClass(java.lang.Class)
>
> Tu dis toi même que tu fais pas attention aux warnings, je pense pas que la solution soit garder les warnings ad vitam erternam, sachant qu'à un moment, le code de java.lang.ClassLoader va bien devoir être changé.

Euh moi aussi je vois ce genre de warnings tous les jours sur XWiki et j’aimerais bien ne plus les voir :)

Mais je n’ai pas bcp de controle dessus sachant qu'ils proviennent de librairies utilisées par XWiki (et on met a jours les versions de nos libs tout le temps). Donc ou bien ils faut trouver d'autres libs supportees qui font le meme boulot (tres dur et pas sur que cela existe dans notre cas), ou bien il faut attendre (et faire du militantisme) pour qu’elles soient modifiees un jour… Oui on peut aussi corriger et faire des PRs sur ces libs mais bon il faut du temps (et on a 300-400 dependances - elles n’ont pas toutes des problemes heureusement :)).

Me trompe-je ? Y-a-t-il des solutions que je ne vois pas ?

Merci
-Vincent

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

[Arnaud Héritier]

Dans mon cas c'est effectivement l'issue chez Jackson.

Je crois que j'en ai une aussi avec Groovy

Mais voilà, je n'ai pas la capacité en temps et compétences pour les aider à fixer le truc

Après je suis suffisamment averti pour le jour ou je passe en 17 pour trouver en 2 min l'option a passer pour que l'appli démarre (mais nous ne sommes pas vraiment représentatif des masses de développeurs java - faut juste anticiper l'article sur stackoverflow il sera vite populaire)

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/41588031-DA1F-4946-BDE0-E1D5C7781559%40massol.net.

[Remi Forax]

----- Mail original -----
> De: "Vincent Massol" <vin...@massol.net>
> À: "lescastcodeurs" <lescast...@googlegroups.com>
> Envoyé: Mercredi 28 Octobre 2020 16:15:45

si tu utilises les --add-machin sur la ligne de commande, tu veras plus les warnings,
c'est bonne solution car même quand --illegal-access va changer de valeur par défaut, cela continuera à fonctionner.

>
> Merci
> -Vincent

Rémi

[Remi Forax]

De: "Arnaud Heritier" <aher...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Mercredi 28 Octobre 2020 16:47:29
Objet: Re: [LCC] JEP 396 - Oh oui, fait moi mal

Dans mon cas c'est effectivement l'issue chez Jackson.

Je crois que j'en ai une aussi avec Groovy

Avec Groovy 3.x ??

Mais voilà, je n'ai pas la capacité en temps et compétences pour les aider à fixer le truc

Je pense que remonter le problème où ajouter un +1 sur l'issue c'est déjà pas mal.

Sinon, je viens d'avoir ma Fedora qui veut se mettre à jour et en regardant les différences, la version par défaut installer est la 11

Après je suis suffisamment averti pour le jour ou je passe en 17 pour trouver en 2 min l'option a passer pour que l'appli démarre (mais nous ne sommes pas vraiment représentatif des masses de développeurs java - faut juste anticiper l'article sur stackoverflow il sera vite populaire)

sinon, même réponse qu'à Vincent, si tu énumères les endroits où tu veux ouvrir cela marche même avec Java 17 (si la valeur par défaut de --illegal-access change d'ici là).

Rémi

[Guillaume Laforge]

Normalement Groovy 3, ça devrait être bon, sinon faut reporter un bug.

--
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/250805232.1285753.1603900968695.JavaMail.zimbra%40u-pem.fr.

--

Guillaume Laforge
Apache Groovy committer

Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/

Twitter: @glaforge

[Frédéric Camblor]

En fait, j'avais vraiment lu en diagonale la JEP (c'est mal) : je ne pensais pas qu'il s'agissait de la valeur par défaut (qui reste changeable en mettait 10s les mains dans le cambouis) d'un paramètre déjà existant.

Du coup ça me fait complètement changer d'avis : le flag étant là depuis déjà un moment, le signal a déjà été lancé à l'écosystème depuis un bon moment déjà (et donc rajouter 3 ans à tout ça, je suis bien d'accord que ce n'est que reculer pour mieux sauter).

D'autant que si on veut fine-tuner pour n'ouvrir la porte qu'à certains endroits, on a toujours les --add-opens à notre disposition pour éviter d'ouvrir toutes les portes.

Promis, la prochaine fois je lirai pas en diagonale !

Frédéric Camblor  

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAFNCU-9UzeP9Qf1UTQjXj5-zkgkgqggwkGCtPBZ%2BSHZyjgrbjA%40mail.gmail.com.

[Henri Tremblay]

Rust, c'est pour la blague. J'aime pas Rust. La principale raison c'est que le langage ne te permet pas de faire rien de bas niveau sans passer un mode unsafe.

Java, la magie c'est que tu peux tout faire avec du JDK et un peu de Unsafe (de moins en moins nécessaire).

J'aime pas quand les développeurs de l'API peuvent faire des choses et toi, non non non pauvre mortel, tu peux pas.

Les add-opens ne marchent pas tout le temps. Je l'explique ici.

http://blog.tremblay.pro/2020/06/jpms-and-accessibility.html

Et dans un cas de deep reflection de type sizeof, tu le découvres à la dure, au runtime.

Quand tu utilises des classes internes d'un framework. JDK ou pas, tu es conscient que ça peut changer. Donc c'est ton problème.

Ce n'est pas du tout un soucis pour le framework. Sauf s'il est trop gentil. 

Unsafe est spécial, il permet de faire des choses qui n'existe pas dans l'API. Mais c'est en train d'être résolu tranquillement.

Par exemple, quand defineClass a bougé, j'ai ronchonné mais je me suis adapté. J'ai juste juré parce que maintenant il y a plein de Module dans les signatures et que quand tu compiles Java 8 tu n'as pas les modules. Très très pénible.

Je pense que Mark veut la passer pour Java 17. Ça serait logique.

Et je ne pense pas que les Records vont faire grand chose pour améliorer l'adoption.

Les records, depuis que j'ai découvert que je ne peux pas avoir de constructeurs privés, je suis triste.

Pour vrai, la seule affaire qui me manque en Java 8 c'est les Map.of et List.of.

Le reste c'est des détails.

Un petit mot sur les warnings.

Moi j'aime -Werror -Xlint:all.

Sauf que ça marche jamais. Parce qu'il y a des warnings qu'on ne peut pas supprimer:

• L'utilisation de Unsafe
• Les maudits warnings de module
• Les affreux warnings d'annotation qui n'ont pas de processeurs

Ça me tappe sur le système tu peux pas savoir...

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

[Arnaud Héritier]

Pour info si vous utilisez jackson, la version 2.12 est sortie https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.12

Son nouveau module jackson-datatype-blackbird va remplacer/deprecier jackson-datatype-afterburner. Il est compatible avec Java 9+ ce qui retire les fameux warning et nous permet d'etre prets pour Java 16 ou +

https://github.com/FasterXML/jackson-modules-base/tree/master/blackbird

Bonne semaine à tous

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

[Pierre Templier]

Il semble que le module Afterburner apportait des gains de performance de l'ordre de 10% par le passé ce qui n'est plus vrai avec les JVM récentes si j'en crois cette issue JHipster : https://github.com/jhipster/generator-jhipster/pull/10283

Cela a conduit a l'arrêt de l'utilisation des modules Afterburner et Blackbird dans JHipster vu que si gain il y a, il est marginal.

Je cite (tests faits avec AdoptOpenJDK (build 11.0.7+10))

In fact, in the past, I've run some tests showing 10% performance increase with Afterburner, so I can confirm that those project's claims were real.
Then, I did more tests today, including testing with Java 8: it's very hard to spot any difference between "vanilla", "afterburner" and "blackbird". Also, Blackbird only works with Java 11, and that will cause an issue as many people are still stuck on Java 8.
So I'm extremely disappointed, and also I don't understand why this happens, but it seems that both Afterburner and BlackBird don't make any significant difference. As they add some significant risk and complexity, I would therefore remove them entirely.  

Hop, une librairie et des warnings en moins :D

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