Reprise du message précédent :

Tu rajoutes une adhérence à une lib invasive pour résoudre ce qui constitue essentiellement un non-problème dans ta base de code, sauf si ton métier au quotidien c'est d'écrire des toString() et des paires de getter/setter, auquel cas il faut quand même sérieusement revoir sa façon de développer.
Je rappelle qu'une dépendance supplémentaire, ça se maintient, c'est potentiellement un problème en cas de montée de version de Java (surtout pour celles qui font de la génération de bytecode et pas mal d'utilisateurs de Lombok ont été emmerdés pour le passage à Java 8 ou Java 11) et il est parfois coûteux de s'en séparer.

Et meme si tu chies des getters setters equals hashC9de au quotidien eclipse te fait ca en 5s et intellij en 3s avec du code encore plus propre.

Je plussoie sur les records, je savoure d'avance.
Un tour sur SOF sur lombok pro/con ça donne des frissons.  

On a le droit d'être content sur la première étape non ?
 

T'es con

Appartement fertile

 
Ah mais carrément, je te le souhaite. L'appart a l'air vraiment cool.

C'est à dire qu'equals et hashcode c'est tout de même un minimum important, néanmoins ça peut être automatisé, tout comme les getters et setters, du code inutile à checkin dans un repository 99% du temps.
 
Les records sont là et font la même chose qu'un @Value de Lombok à la différence des accessors versus getters et d'autres choses plus low-level.
 
Mais Lombok possède apporte plein de choses, ne serait-ce que les builders, qui va s'amuser à en écrire à la main ? Pas moi. Les records ne supportent d'ailleurs pas les builders en standard, il faut passer par des librairies. Autre truc que j'utilises tout le temps @Log/@Slf4j et consort.  
 
Bien sur y'a des downsides, par exemple equals/hashcode sur des entités JPA, faire gaffe au lazy encore sur JPA, l'ordre de paramètres de même type générés pour des constructeurs si on les réorganise ça peut foutre la grouille, et d'autres encore. N'importe quel tooling dans les mains de quelqu'un qui ne sait pas s'en servir peut être dangereux.
 
Autre problème qui peut arriver quand on a plusieurs annotations processor, genre MapStruct, l'ordre peut parfois être délicat, de même Lombok + AspectJ,
 
Est-ce que Lombok est utile et que ça vaut le coup ? chacun à sa sensibilité, moi je pense que oui, dans tous les cas ce n'est pas de la merde, loin de là, il a servi son temps, j'espère qu'on pourra s'en passer le plus tôt sera le mieux, mais y'a tellement de code base avec des architectures tellement WTF et des décisions entreprise cargo cult de merde, qu'il faut limite mieux être au chômage que bosser sans.
 
Mon seul vrai concern est à propos de Lombok qui un jour pourra peut-être plus accéder aux internals de futurs JDK pour faire sa tambouille sans downgrader un level de sécurité qui sera peut-être mis en place, mais je pense qu'on a le temps de voir venir un minimum. Le jour là ce sera la baise, ou alors les gens devront mettre une grosse exception dans un fichier de config java ou autre, et là ça risque de ne plus passer.

 
+1
 

 
Justement non: si tu peux ne pas réfléchir à l'implémentation de Equals/hashCode, alors dans 99.99% des cas tu peux t'en passer.
 

 
Perso j'écris mes builders quand j'en ai besoin, ça me dérange pas plus que ça. Ca permet aussi accessoirement de mettre de la logique de validation dedans.
 
Au passage,la diff entre un annotation processor "classique" à la MapStruct (que j'aime pas trop non plus parce que dès que ça devient complexe tu passes plus de temps à le configurer que tu n'en aurais passé à écrire les mappers à la main), c'est que Lombok ne crache pas de code
 
Donc il casse la navigation dans le code des IDE. Et rien que ça pour moi c'est un chiffon rouge.

ouai mais c'est moche. Ca reste du boilerplate.

L'usage que j'en ai, c'est pour tout ce qui est interface de sérialisation avec une BD ou du JSON ou je ne sais quoi qui est essentiellement des classes de données (DTO, DAO, blabla), tout ce genre de truc. C'est effectivement pas exactement difficile avec les générateurs de code des IDE, mais ça fait quand même plein de boilerplate là où une seule annotation @Data au niveau de la classe fait le job. Tu vois immédiatement tes données membres et pas de bordel autour à te demander si par hasard on n'aurait pas oublié un setter ou autre.
Pour le vrai code métier roulé sous les aisselles, je reconnais que c'est pas indispensable et que ça allonge les temps de build de 2 secondes.
 

Je veux bien voir.

Excuse moi de te le dire, mais tu dis n'importe quoi.
Tu ne peux pas t'en passer, à moins que tu n'utilises jamais de collections peut-être.

Simple exemple:

import java.util.List;
import java.util.Objects;
 
class Person {
    final String firstName;
    final String lastName;
 
    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}
 
class Pet {
    final String name;
    final int age;
 
    public Pet(String name, int age) {
        this.name = name;
        this.age = age;
    }
 
 
    // généré par IntelliJ
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Pet animal = (Pet) o;
        return age == animal.age && Objects.equals(name, animal.name);
    }
 
    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}
 
public class Foo {
 
    public static void main(String[] args) {
        var persons = List.of(new Person("g", "five" ), new Person("foo", "bar" ));
        System.out.println(persons.contains(new Person("g", "five" ))); 
 
        var animals = List.of(new Pet("cat", 10), new Pet("doggo", 5));
        System.out.println(animals.contains(new Pet("doggo", 5))); 
    }
}

Output:

Cela fonctionne de même pour les autres collections comme les Set, les Map etc.

Du coup à choisir je préfère :

import lombok.Value;
 
import java.util.List;
 
@Value
class Person {
    String firstName;
    String lastName;
}
 
@Value
class Pet {
    String name;
    int age;
}
 
public class Foo {
 
    public static void main(String[] args) {
        var persons = List.of(new Person("g", "five" ), new Person("foo", "bar" ));
        System.out.println(persons.contains(new Person("g", "five" ))); 
 
        var animals = List.of(new Pet("cat", 10), new Pet("doggo", 5));
        System.out.println(animals.contains(new Pet("doggo", 5))); 
    }
}

Et l'output qui va avec:

Mais pour ce point nous sommes d'accord qu'utiliser des records aurait fait la même chose et alors je préfère encore les utiliser si disponible:

import java.util.List;
 
record Person(String firstName, String lastName) {}
record Pet(String name, int age) {}
 
public class Foo {
 
    public static void main(String[] args) {
        var persons = List.of(new Person("g", "five" ), new Person("foo", "bar" ));
        System.out.println(persons.contains(new Person("g", "five" )));
 
        var animals = List.of(new Pet("cat", 10), new Pet("doggo", 5));
        System.out.println(animals.contains(new Pet("doggo", 5)));
    }
}

Et l'output qui va avec:

Tu peux également avoir de la validation avec un builder lombok.

Mais même sans ça, entre ceci:

@ToString
@Builder
class Person {
    String firstName;
    String lastName;
}

et cela

class Person {
    String firstName;
    String lastName;
 
    Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
 
    // /!\ le code qui suit a une très très grosse valeur ajoutée, écrivez-le vous même
    public static PersonBuilder builder() {
        return new PersonBuilder();
    }
 
    public String toString() {
        return "Person(firstName=" + this.firstName + ", lastName=" + this.lastName + " )";
    }
 
    public static class PersonBuilder {
        private String firstName;
        private String lastName;
 
        PersonBuilder() {
        }
 
        public PersonBuilder firstName(String firstName) {
            this.firstName = firstName;
            return this;
        }
 
        public PersonBuilder lastName(String lastName) {
            this.lastName = lastName;
            return this;
        }
 
        public Person build() {
            return new Person(firstName, lastName);
        }
    }
}

Pour moi la question elle est vite répondue

De même pour MapStruct, quel est l'intérêt d'ecrire à la main du code de mapping par exemple pour tout ce qui est plomberie DTO etc ? Zéro, d'après moi, mais c'est toi qui écrit le code, pas moi.

Concernant la navigation via Lombok, je ne sais pas quel IDE tu utilises, mais ça fonctionne dans IntelliJ depuis plus de 8 ans, et encore je suis sympa je suis quasiment certain que ça fonctionnait bien bien avant ça , tu click sur un setter ça va sur le field, tu renommes un field ça renomme les setter générés par lombok. Bref pour moi c'est une légende urbaine

Interessant vos arguments.  

Dès qu'il y a un nouveau ça parle dev une journée et après on en revient au vrai sujet de la vie.

 
Ouais enfin si jamais tu supportes pas le boilerplate, faire du Java c'était une erreur majeure
 
Pour tout ce qui est equals/hashcode, je génère ça via l'IDE, c'est pas beaucoup plus compliqué.
Après j'entends bien que Lombok semble apporter de la valeur à certains, je sais que j'ai un biais contre le sucre syntaxique tierce partie, c'est aussi un truc chiant dans le monde Scala (salut cats !).
 

Je me disais aussi que c'était louche, le post de gfive.

Puisque c'est évitable, non.

Effectivement, mais c'est du code que tu dois commit, voir dans ton IDE, ça pollue la vision de l'essentiel. Et de plus faut pas oublier de regénérer le equals/hashcode si tu ajoutes des champs, c'est tout autant error prone qu'un @EqualsAndHashCode qui prendrait un nouveau champ dont tu ne voulais pas (typiquement le cas pour les entités JPA où tu ne veux généralement que le champ id)

Y'a pas quelqu'un qui fait des travaux ?

import java.util.List;
import java.util.Objects;
 
class Person {
final String firstName;
final String lastName;
 
public Person(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
}
 
class Pet {
final String name;
final int age;
 
public Pet(String name, int age) {
this.name = name;
this.age = age;
}
 
 
// généré par IntelliJ
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Pet animal = (Pet) o;
return age == animal.age && Objects.equals(name, animal.name);
}
 
@Override
public int hashCode() {
return Objects.hash(name, age);
}
}
 
public class Foo {
 
public static void main(String[] args) {
var persons = List.of(new Person("g", "five" ), new Person("foo", "bar" ));
System.out.println(persons.contains(new Person("g", "five" ))); 
 
var animals = List.of(new Pet("cat", 10), new Pet("doggo", 5));
System.out.println(animals.contains(new Pet("doggo", 5))); 
}
}

import lombok.Value;
 
import java.util.List;
 
@Value
class Person {
String firstName;
String lastName;
}
 
@Value
class Pet {
String name;
int age;
}
 
public class Foo {
 
public static void main(String[] args) {
var persons = List.of(new Person("g", "five" ), new Person("foo", "bar" ));
System.out.println(persons.contains(new Person("g", "five" ))); 
 
var animals = List.of(new Pet("cat", 10), new Pet("doggo", 5));
System.out.println(animals.contains(new Pet("doggo", 5))); 
}
}

import java.util.List;
 
record Person(String firstName, String lastName) {}
record Pet(String name, int age) {}
 
public class Foo {
 
public static void main(String[] args) {
var persons = List.of(new Person("g", "five" ), new Person("foo", "bar" ));
System.out.println(persons.contains(new Person("g", "five" )));
 
var animals = List.of(new Pet("cat", 10), new Pet("doggo", 5));
System.out.println(animals.contains(new Pet("doggo", 5)));
}
}

@ToString
@Builder
class Person {
String firstName;
String lastName;
}

class Person {
String firstName;
String lastName;
 
Person(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
 
// /!\ le code qui suit a une très très grosse valeur ajoutée, écrivez-le vous même
public static PersonBuilder builder() {
return new PersonBuilder();
}
 
public String toString() {
return "Person(firstName=" + this.firstName + ", lastName=" + this.lastName + " )";
}
 
public static class PersonBuilder {
private String firstName;
private String lastName;
 
PersonBuilder() {
}
 
public PersonBuilder firstName(String firstName) {
this.firstName = firstName;
return this;
}
 
public PersonBuilder lastName(String lastName) {
this.lastName = lastName;
return this;
}
 
public Person build() {
return new Person(firstName, lastName);
}
}
}

Sur le equals/hashcode de ta classe, ok, mais dès qu'on est dans le domaine de la persistance ça ne marche plus.

Parce que l'id entre en jeu, et il definit l'identité de ton objet.
Donc ton contains(new Pet(x,y)) répondra toujours faux si ta collection vient de la DB, mais true si ta collection vient d'un mapping.

Donc bon, je pense que sur le fond du fond on est a peu près d'accord sur un truc : equals, hashcode, et dans une moindre mesure tostring, c'est des trucs sensibles, importants, qui ne doivent pas être pris a la légère.
Or je constate que la plupart des devs qui utilisent Lombok le font de la manière la plus con qui soit, en collant un @Data ou un @Value partout, en définissant des égalités métier dans equals alors que tu devrais plutôt avoir des méthodes dédiées pour ça (d'abord parce que les modèles métier sont pas nécessairement en correspondance 1:1 avec le(s) modèles techniques, surtout côté persistance.

Je préfère voir un dev perdre du temps et se poser qques questions sur ce qu'il fait que de le voir en gagner au moment du dev mais pas piger la moitié du fonctionnement de son code.

Quand au mapping, j'avoue je j'en fais de moins en moins.
J'utilise la config de  Jackson (des serializers/deserializrs dédiés, des views et des mixins) pour les cas où le Json ressemble pas au modèle métier,. Parce que ai final, quand tu mappes entité ->modele->dto et que ensuite tu serialize le dto en Json, je trouve que ça fait beaucoup d'étapes

Pendant qu'on est sur les outils dont on doute de la valeur qu'ils apportent, il y en a ici qui a un avis sur NgRx ? J'arrive pas à arriver à trouver une bonne raison de le garder...

Non pour les entités tu fais fausse route, le seul point d'ancrage pour ton equals et hash code est l'identifiant, donc tu le trouveras également dans la liste de tes mapping sur cette base alors que sans redéfinir equals et hashcode tu ne me retrouvera pas. C'est ta seule source de vérité pour savoir si une collection contient une entité persistee, l'id. Et c'est bien pour ça qu'on dit de ne pas utiliser @Data pour des entités sauf à faire ça proprement avec @EqualsAndHashCode(of="id" )
 
comme je disais lombok est un outil tu peux mal t'en servir après tout j'ai l'impression que les rêve ont déjà du mal avec les basics du langage, le prob est ah niveau de l'humain pas de l'outil.
 
concernant les mixins de jsonviewer pas d'avis ça peut vite devenir compliqué également à configurer, et de toute façon c'est pas une solution hyper pratique quand on fait du schéma first plutôt que du code first par exemple pour des API.

j'aime bien redux c'est clair et bien séparé mais c'est très complexe pour des petites app.  
 
À la COGIP la on a une app qui a grossit les devs voulaient pas partir sur redux ils s'en mordent les couilles à devoir gérer eux même des co effect, des sagas etc à la main

Je sais pas ce que c'est, tu as des exemples ?

euh la sur le tel à la salle de sport entre deux répétitions mais en gros lancer des requêtes qui en appellent d'autres (des actions dans le concept redux). Redux s'occupe d'ordonnancer les promises failure potentiellement multiple etc, à la main c'est la merde a coup de Promise.all sans compter le fait que la réduction peut arriver dans un ordre différent et être sub optimale  
 
sur l'ordinateur je peux te montrer mieux
 
mais principalement moi redux me plaît pour le cadre et la séparation qu'il donne, et l'unique source of truth des données, sans compter que la réduction peut être écrite succinctement

T'essayes de nous dire que tu gagnes plus d'un ratibus ?

Pour avoir utilisé par mal de gestionnaire de State (Redux, MobX et Reaclette ), je reviendrais jamais sur Redux. Ce truc complexifie le code pour quedal, MobX fait aussi bien.

Le simple fait que le store mobx soit mutable c'est un big no pour moi, je suis pas fan des observable, le debugging était à des années lumières de redux la dernière fois que j'ai testé, et c'est pas pure, désolé mais mon petit cœur fait en clojure pleure des larmes de sang

Le debug est casse couille en effet. Mais mnt doit y'avoir du mieux je pense. Ou au moins un gestionnaire de state convenable par rapport à tous ces ancêtres.

redux roi du game sur ce point précis, predictable, time travel, pure.  
 
truc correct vu la sensibilité, je pars pas pour moins bien, ce qui est le cas de mobx pour moi

Non, mais par contre quand tu visites des clapiers de la taille de sa terrasse avec des revenus présentés sans couverture sociale, retraite et sécu, ça fait vite de gros multiples de loyers.  
Bon par contre on est pas des bêtes, donc on est sur de la superhuman à double compartiment

Bah si tu ne met que l'id dans equals/hashcode dans les entités, tu ne peux pas t'en servir comme méthode d'égalité métier.

Et du coup, si l'instance que tu as pour comparer vient de l'entitymanager et qu'elle a le même id, alors en fait, ben c'est la même instance, et le equals par défaut marche .

Si l'instance ne vient pas de l'entitymanager, elle n'a pas d'id, a moins de le coller toi même dedans a la construction.
Si c'est un id métier alors ok
Si c'est une valeur de séquence avec un générateur JPA, tu peux pas faire ça.

Mais sinon, le problème de l'égalité/identité et du partage de cette notion entre le code, le sgbd et le métier est sans réelle solution. Et il est complexe.
L'adresser "a la légère" avec un outil qui a l'air magique pour un gain assez minime, je suis assez contre (du coup: Lombok ça fait des trucs sympa, mais risqués si on maîtrise pas ces notions, et le coût du risque me semble supérieur au gain de son utilisation)

C'est d'ailleurs une question que je pose souvent en ITW :

- la diff entre Set et List?
- il y a pas de doublon dans un Set.
- qu'est ce que vous voulez dire par doublon?

Et la généralement c'est le drame.

A cet égard je trouve que les records qui font entrer la notion d'égalité champ a champ avec le même nom de méthode que l'égalité d'instance du Object.equals() nous préparent de grands moment de perplexité chez les devs qui se sont jamais intéressés au problème.

Oui bon, y'a aussi beaucoup de branlette autour de ça. Souvent quand tu debug ton state c'est parce que tu as mal branlé ton composant.

Le nombre de projet qui l'intègre alors qu'un useContext fait le taf, voilà quoi.
Et dédicace aussi à ceux qui font des milliers de micro composant partout alors que rien n'est jamais utilisé deux fois alors qu'une bonne page suffit et est plus simple à gérer aussi niveau state.

C'est toi qui les amène à ça? Parce qu'une autre différence assez majeure c'est que le set ne maintient pas d'ordre (et par conséquent ne permet pas non plus de le manipuler).

IMO c'est une des grosses améliorations dans les langages modernes (genre Swift ou Rust) héritées des langages fonctionnels: ce genre d'opérations est optionnelle et opt-in, donc tend à être beaucoup plus délibéré, et documenté.able.

L'ordre ils y pensent, mais après le pas de doublon, qui est vraiment le premier truc qui sort.

Ce qui est marrant avec Set, c'est que les objets sont les clés de la Map cachée dedans.
Donc si tu fais pas gaffe à ton equals/hashcode tu peux faire :

Machin truc = New Machin(nom, prénom)
(Hashcode défini sur nom et prénom)
set.put(truc);

truc.setNom(hahaha)
set.contains(New Machin(hahaha, prénom) -> false
Truc.equals(New Machin(hahaha, prénom) -> true.

Diablerie!!!

Je me suis mal fait comprendre. J'aime bien redux, et j'utilise ça dans mes applis. Par contre, ça me semble trivial à implémenter, du coup je vous pas trop l'intérêt de se traîner un truc comme NgRx qui rajoute du frottement et une couche d'abstraction imbitable pour quiconque n'est pas habitué. Je cherche des arguments pour garder NgRx.

C’est pas toujours une map pour raisons d’efficacité (tous les langages ont pas des types de talle 0, donc tu perds de la mémoire pour rien à mettre genre des valeurs nulles).
 
Mais sinon oui, mettre des objets mutables dans un set et garder un handle dessus c’est un piège classique.
 
Ça te nique aussi bien un (b)treeset aussi quand t’as un objet qui est pas au bon endroit

(Je fais des itw que pour du java)

Et c’est une map sous le hashset pas une implémentation séparée? Parce que java étant justement un langage sans zst (afaik) tu perds 8 octets par bucket.

Tiens __alt :

Le jambon-beurre est-il de droite ?

Bon bah j'ai pas été pris...

Les recruteurs étaient assez surpris en voyant ma tronche mais ils l'ont assez bien pris. J'ai pas pu m'attarder j'étais au tennis...

Je croyais qu’il n’y avait pas la vidéo  

Oups

Je te gardais une opportunité de complément de revenus depuis quelques jours mais si tu ne passes même pas les tests du premier round…
 
 

Nouvelle idée dans mon désert médical : un n° de tél mutualisé pour avoir un RDV avec un généraliste en cas d'urgence relative (une vingtaine de médecins de l'agglo ont bloqué des créneaux de 2h pour ces RDV hors patientèle).
 
Lundi c'était le jour de l'ouverture du service : implosion des urgences du CH. 2x plus d'entrées qu'avant. 1 décès sur un brancard. 90% des parameds du SAU s'est mis en arrêt le soir même. Great success.
(L'ARS a répondu : "démerdez-vous" )

Tiens c’est marrant parce que c’est une des propositions de campagne de Macron (et Pecresse aussi ?)