Un petit kata pour découvrir les features de Java 17

261 views
Skip to first unread message

Remi Forax

unread,
Nov 10, 2021, 9:09:17 AM11/10/21
to lescastcodeurs
Bonjour à tous,
il fait froid dehors, demain c'est férié, donc c'est le bon moment pour un petit kata sur les nouvelles features de Java 17 [1].

En fait, j'ai préparé le code car Mardi soir prochain je suis au BordeauxJUG [2] et qu'un peu de live-coding pendant une présentation cela fait de mal à personne,
mais en regardant le truc fini, je me dis que cela peut intéresser un peu tout le monde.

Rémi
PS: non, c'est pas un kata qui arrache la tête, ceux là je les réserve à mes étudiants lors des examens :)

[1] https://github.com/forax/kata-java17
[2] http://bordeauxjug.org/

Samuel Le Berrigaud

unread,
Nov 10, 2021, 10:34:26 AM11/10/21
to lescast...@googlegroups.com
Merci Rémi. Fait. Et partagé avec quelques collègues. Ça rend les choses plus concrètes. Maintenant y'a plus qu'à passer un projet interne à Java 17.


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

Fred Bricon

unread,
Nov 10, 2021, 10:43:33 AM11/10/21
to lescast...@googlegroups.com
Ca s'ouvre tout seul dans mon IDE préféré, c'est beau.

On Wed, Nov 10, 2021 at 3:09 PM Remi Forax <fo...@univ-mlv.fr> wrote:
--
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/1669804123.1529764.1636553348156.JavaMail.zimbra%40u-pem.fr.


--
"Have you tried turning it off and on again" - The IT Crowd
And if that fails, then http://goo.gl/tnBgH5

Henri Tremblay

unread,
Nov 12, 2021, 12:17:22 PM11/12/21
to lescastcodeurs
Super comme exercice.
Je viens de jouer.

J'ai regardé la solution Java 17 preview
Le pattern matching me trouble.
Ça me semble plus orienté objet.

Je me demande un peu pourquoi, ci-dessous, ceci n'est pas mieux?

public sealed interface Expr {

  int eval(Map<String, Integer> variableMap);
// ...
record Value(int value) implements Expr {
  @Override
  public String toString() {
    return "" + value;
  }

  @Override
  public int eval(Map<String, Integer> variableMap) {
    return value;
  }
}
//...

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

Remi Forax

unread,
Nov 12, 2021, 12:46:02 PM11/12/21
to lescastcodeurs
From: "Henri Tremblay" <henri.t...@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Vendredi 12 Novembre 2021 18:17:10
Subject: Re: [LCC] Un petit kata pour découvrir les features de Java 17
Super comme exercice.
Je viens de jouer.

J'ai regardé la solution Java 17 preview
Le pattern matching me trouble.
Ça me semble plus orienté objet.

Je me demande un peu pourquoi, ci-dessous, ceci n'est pas mieux?

public sealed interface Expr {

  int eval(Map<String, Integer> variableMap);
// ...
record Value(int value) implements Expr {
  @Override
public String toString() {
    return "" + value;
  }

  @Override
public int eval(Map<String, Integer> variableMap) {
    return value;
  }
}
//...

La prog "objet" à un coût, répartir l'algo dans plein d'implantation d'eval() cela a un coût.
Les 2 principaux problèmes sont
- ta a du mal à modifier ton algo, c

si tu réparties le code de ton algo dans plein d'eval() différents cela rend l'algo pas lisible, pas facile à modifier
(et je parle même pas des problèmes quand tu as des tours d'héritage).



Remi Forax

unread,
Nov 12, 2021, 12:52:36 PM11/12/21
to lescastcodeurs


From: "Henri Tremblay" <henri.t...@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Vendredi 12 Novembre 2021 18:17:10
Subject: Re: [LCC] Un petit kata pour découvrir les features de Java 17
Super comme exercice.
Je viens de jouer.

J'ai regardé la solution Java 17 preview
Le pattern matching me trouble.
Ça me semble plus orienté objet.

Je me demande un peu pourquoi, ci-dessous, ceci n'est pas mieux?

public sealed interface Expr {

  int eval(Map<String, Integer> variableMap);
// ...
record Value(int value) implements Expr {
  @Override
public String toString() {
    return "" + value;
  }

  @Override
public int eval(Map<String, Integer> variableMap) {
    return value;
  }
}
//...

[mail parti trop vite]

La prog "objet" à un coût, répartir l'algo dans plein d'implantation d'eval() cela a un coût.
Les 2 principaux problèmes sont
- tu a du mal à modifier ton algo, car tu as plein de petits bouts de sémantique répartie un peu partout façon puzzle
  (et je parle même pas des problèmes quand tu as des tours d'héritage)
- tu as un problème de perf, l'algo est pas inliné si tu as trops d'implantations diverses.

Cela me dérange pas de payer ce coût si l'interface est ouverte, car je sais ce que je gagne,
je permets aux gens qui utilisent mon API de venir avec leur implantation, donc je permet l'extensibilité.
Mais dans notre cas, on veut pas l'extensibilité, tu peux pas venir avec ta propre implantation de Expr et espérer que cela marche,
car Patter.parse() ne marchera pas.C'est pour cela que l'on ferme la hierarchie avec le mot-clé sealed.
Si la hierarchie est fermée, je vois pas l'intérêt de payer la surtaxe du polymorphisme sans en avoir les bénéfices,
donc dans ce cas, le pattern matching est meiux que le polymorphisme.

Rémi

Henri Tremblay

unread,
Nov 13, 2021, 2:41:53 PM11/13/21
to lescastcodeurs
Intéressant.
Je ne sais pas si j'adhère, mais c'est intéressant.
Je me dis qu'à un moment donné, tout va être codé eval.
Les tests unitaires vont être plus tannants et à force ça va faire pas mal de code dans cette méthode pour avoir une grammaire au complet.
On va perdre le inlining de la méthode mais j'imagine qu'on peut mettre des sous-méthodes au besoin.

Ceci étant, je suis d'accord que ça permet de lire le tout d'un seul coup d'oeil.

Question à côté: Si c'est plus rapide, pour la JVM ne remplace pas toute seule en switch le polymorphisme? En particulier sur des sealed classes?


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

Laurent Forêt

unread,
Nov 16, 2021, 2:33:51 AM11/16/21
to lescastcodeurs
Je n'ai pas joué, je ne voulais pas me spoiler la conférence de demain ( { "modeTroll": true,  { "content": "Excuse à deux balles"}}) .

Donc avis à tous les bordelais, n'hésitez pas à venir demain soir à l'ENSEIRB, pour le faire en live. 


Laurent


Frédéric Camblor

unread,
Nov 16, 2021, 2:33:51 AM11/16/21
to lescastcodeurs
Si on commence à regarder avant mardi on se spoil ta prez ? :-)

Frédéric Camblor  



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

Remi Forax

unread,
Nov 16, 2021, 2:33:51 AM11/16/21
to lescastcodeurs


From: "Henri Tremblay" <henri.t...@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Samedi 13 Novembre 2021 20:41:40
Subject: Re: [LCC] Un petit kata pour découvrir les features de Java 17
Intéressant.
Je ne sais pas si j'adhère, mais c'est intéressant.
Je me dis qu'à un moment donné, tout va être codé eval.

Tu auras pas tout, car le code des cases de ton switch appel eux-même des méthodes.

Les tests unitaires vont être plus tannants et à force ça va faire pas mal de code dans cette méthode pour avoir une grammaire au complet.

Je vois pas vraiment que cela change en terme de test unitaire, vu de l'extérieur pour les tests tu as une méthode eval() dans les deux cas.

On va perdre le inlining de la méthode mais j'imagine qu'on peut mettre des sous-méthodes au besoin.

Ceci étant, je suis d'accord que ça permet de lire le tout d'un seul coup d'oeil.

Question à côté: Si c'est plus rapide, pour la JVM ne remplace pas toute seule en switch le polymorphisme?

Elle le fait, mais avec certaines contraintes.
Le problème de l'inlining en rêgle générale, si tu inlines trop ton code devient très très lent car le code assembleur ne tiens pas dans le cache L1 et dans ce cas, tu as des cache-miss sur les instructions,
le processeur est ralenti car les instructions sont pas encore arrivée. Et là tu as des perfs catastrophiques. Et si tu inlines pas, tu fais un appel à travers la vtable, et cela coûte pas si chère que cela.

L'autre problème est que le choix de faire l'inlining ou pas est fait sur des informations partielles, un nouvel objet peut apparaitre car ta payload JSON est légèrement différente par exemple.

Donc le choix de remplacer un appel polymorphe par un switch est fait de façon prudente par la VM.
Pour Hotspot, si tu as au plus deux classes différentes à l'exécution, tu auras de l'inlining, sinon l'appel ne sera pas inliné.
(Hotspot a aussi quelques limitations historiques du genre si tu as une méthode dans une classe abstraite, alors l'algo agi come si elle était dupliquée dans chaque sous-classe,
c'est une limitation que Graal n'a pas).

Si tu as un switch écrit par l'utilisateur, la situation est différentes, tu vois tous les cas possible et tu as une idée de la taille totale au pire cas, donc tu peux prendre une meilleure décision.

En particulier sur des sealed classes?

Ce que t'apporte les sealed classes en terme de code généré c'est le fait que tu as pas à prévoir le cas où il y a une nouvelle classe qui arrive si tu as déjà vu toutes les classes listées par la clause "permits", cela marche aussi bien et pour le polymorphisme et pour le switch.
A ma connaissance, les JITs de Hotspot ont pas encore été modifié pour prendre cela en compte, il y a des trucs plus urgent sur le feu :)

Rémi

Remi Forax

unread,
Nov 16, 2021, 3:11:31 AM11/16/21
to lescastcodeurs
From: "Frédéric Camblor" <fcam...@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Vendredi 12 Novembre 2021 19:58:29
Subject: Re: [LCC] Un petit kata pour découvrir les features de Java 17
Si on commence à regarder avant mardi on se spoil ta prez ? :-)

non, on comprend mieux ma prez, voir même on s'entraine à corriger les erreurs que je vais faire en live car je suis particulièrement mauvais en live coding :)


Frédéric Camblor 

Rémi

Remi Forax

unread,
Nov 16, 2021, 3:13:59 AM11/16/21
to lescastcodeurs
Je pense qu'il y a eu un léger problème avec la Mailing list des casts-codeurs,
je sais pas pour vous mais je viens juste de recevoir les deux derniers messages,
où alors c'est de mon coté qu'il y a eu un/une glitch ?

Rémi

Arnaud Héritier

unread,
Nov 16, 2021, 3:31:20 AM11/16/21
to lescast...@googlegroups.com
Il y en a un qui était en modération. Celui de Frédéric je crois.


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


--
Arnaud Héritier
Twitter/GitHub/... : aheritier

Henri Tremblay

unread,
Nov 16, 2021, 8:46:40 PM11/16/21
to lescastcodeurs
De plus en plus intéressant, merci Rémi.

Je parlais des tests dans une optique de tester chaque méthode eval() séparément.
Avec le switch, tous les tests partent du switch.


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

Remi Forax

unread,
Nov 18, 2021, 6:29:06 AM11/18/21
to lescastcodeurs
From: "Remi Forax" <fo...@univ-mlv.fr>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Samedi 13 Novembre 2021 22:01:31
Subject: Re: [LCC] Un petit kata pour découvrir les features de Java 17


From: "Henri Tremblay" <henri.t...@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Samedi 13 Novembre 2021 20:41:40
Subject: Re: [LCC] Un petit kata pour découvrir les features de Java 17
Intéressant.
Je ne sais pas si j'adhère, mais c'est intéressant.
Je me dis qu'à un moment donné, tout va être codé eval.

[...]


Question à côté: Si c'est plus rapide, pour la JVM ne remplace pas toute seule en switch le polymorphisme?

Elle le fait, mais avec certaines contraintes.
Le problème de l'inlining en rêgle générale, si tu inlines trop ton code devient très très lent car le code assembleur ne tiens pas dans le cache L1 et dans ce cas, tu as des cache-miss sur les instructions,
le processeur est ralenti car les instructions sont pas encore arrivée. Et là tu as des perfs catastrophiques. Et si tu inlines pas, tu fais un appel à travers la vtable, et cela coûte pas si chère que cela.

L'autre problème est que le choix de faire l'inlining ou pas est fait sur des informations partielles, un nouvel objet peut apparaitre car ta payload JSON est légèrement différente par exemple.

Donc le choix de remplacer un appel polymorphe par un switch est fait de façon prudente par la VM.
Pour Hotspot, si tu as au plus deux classes différentes à l'exécution, tu auras de l'inlining, sinon l'appel ne sera pas inliné.
(Hotspot a aussi quelques limitations historiques du genre si tu as une méthode dans une classe abstraite, alors l'algo agi come si elle était dupliquée dans chaque sous-classe,
c'est une limitation que Graal n'a pas).

Le bug dont je parlais existe plus, il a été fixé en Java 17, yeah !

Il reste plus qu'à utiliser Java 17 en prod :)

Rémi

Reply all
Reply to author
Forward
0 new messages