Parlez-moi un peu de Guava et Lombok!

Les conférences

Thierry Leriche-DessirierThierry Leriche-Dessirier est invité par le Lyon JUG le 19 septembre prochain pour une soirée dédiée à Guava et Lombok. Agnès Crépet et ses camarades du Lyon JUG sont allés à sa rencontre pour lui poser quelques questions en amont de cette soiréé.

Agnès : Peux-tu te présenter? Quels genres de missions assures-tu en tant que Freelance?
Thierry: J’ai trente-cinq ans. Je suis marié, papa d’une petite fille et très gros consommateur de café. Je travaille depuis une douzaine d’années, quasi exclusivement sur le Web et sur Java. Quand j’étais en SSII, j’avais le poste d’architecte JEE. Depuis que je suis indépendant, je me présente comme consultant.
Mon activité principale, en semaine, est d’assister le leader français de la grande distribution dans ses développements. J’interviens sur plusieurs projets (SSO, référentiels client, portails, QR codes, intranet, drives, etc.) en Europe en en Asie.
A côté, je suis également professeur de Génie Logiciel à l’ESIEA, une très bonne école d’ingénieur sur Paris, et coach sur des projets de formation humaine. Pour compléter le tableau, entre deux biberons, je suis rédacteur pour Developpez.com et le magazine Programmez.

Agnès : Utilises-tu Guava par défaut les yeux fermés sur tous tes projets Java? Quel est le top 3 de tes fonctionnalités préférées de Guava, celles qui en font selon toi un outil incontournable?
Alexis : En quoi Guava est-il mieux que Apache commons ? Est-ce qu’il y a des domaines où il est moins bien ? Est-ce qu’il a d’autres concurrents ?

Thierry: J’ai découvert Guava à la machine à café juste avant de passer freelance. A l’époque, ça s’appelait encore « Google-Collections ». Ça a été un coup de cœur et, par chance, j’ai pu l’utiliser sur un vrai projet dès la mission suivante. Je vois cette bibliothèque comme un incontournable dans mon travail. J’ai tellement l’habitude de l’utiliser que j’ai du mal à écrire du code Java qui ne l’utilise pas.
Ce qui m’a initialement séduit dans les « Google-Collections », ce sont les « static factories » pour créer des collections facilement et sans devoir répéter les génériques de chaque côté du signe égal.
Avec Java 5 :


List<Integer> primeNumbers = new ArrayList<Integer>();
Map<String, Integer> ages = new HashMap<String, Integer>();

Avec Guava :


List<Integer> primeNumbers = newArrayList() ;
Map<String, Integer> ages = newHashMap();

J’ai découvert le concept d’immutabilité, qui existe en Java mais que Guava sublime. Et puis j’ai adoré la programmation fonctionnelle qui devenait enfin accessible en Java.
On trouve une très bonne vidéo de programmation fonctionnelle à l’aide des Google-Collections, présentée par Kevin Bourrillon (le team leader Guava) et Josh Bloch sur Youtube : http://www.youtube.com/watch?v=ZeO_J2OcHYM
Exemple de transformation d’un Dog en SuperChien à l’aide de la méthode « transform » et de la classe « Function » :


List<SuperChien> superChiens = Lists.transform(dogs,
new Function<Dog, SuperChien>() {
@Override
public SuperChien apply(Dog dog) {
SuperChien chien = new SuperChien();
chien.setSurnom("Super " + dog.getName());
chien.setPoids(dog.getWeight());
chien.setPouvoirs(newHashSet("Code en Java", "Vole"))
...
return chien;
}
});

Rapidement j’ai écrit un article sur mon site perso à propos des Google-Collections, que j’ai porté sur Developpez.com
Et par la suite, j’ai complété ce premier article par un blog dédié à Guava.
A l’occasion d’une intervention au Paris JUG, je me suis intéressé de nouveau aux Commons d’Apache dont j’avais oublié jusqu’à l’existence. J’avais alors le sentiment que ça avait mal passé le cap de Java 5 et plus particulièrement l’arrivée des génériques. Etait-ce seulement une fausse impression ? Et quelle bonne surprise ça a été de constater que les Commons valaient de nouveau le coup d’œil.
A mon sens, Guava et les Commons ne se font pas vraiment concurrence. Ils ont des domaines sur lesquels ils se chevauchent mais je trouve qu’ils se complètent assez bien. Sur la question de les comparer, lors de Devoxx France 2012, Kevin Bourrillon proposait de lire un sujet dédié sur Stackoverflow.
A titre personnel, je préfère Guava…

Cyril : Guava est-elle une librairie qui améliore simplement la productivité, ou améliore-t-elle aussi la qualité du code produit, notamment au niveau de la maintenabilité? Le coût d’apprentissage est-il important?
Thierry: Très clairement, Guava améliore la productivité et la qualité. La bibliothèque reprend tous les concepts du livre « Effective Java » à son compte et elle oblige les développeurs à se poser les bonnes questions. L’exemple qui me vient immédiatement est celui des immutables. Pour paraphraser, on se demande souvent si une collection doit être immutable alors que, dans la très grande majorité des cas, on devrait surtout se demander si elle a besoin d’être mutable.
Quand on regarde le code de Guava, à part certains points hyper spécifiques, il n’y a rien d’insurmontable. Je dirais même que tout est d’une clarté effrayante. C’est sans doute le signe de la qualité. Pendant longtemps, le gros point noir a été la documentation mais ce problème est désormais quasi réglé.
Je pense qu’il suffit de quelques heures pour bien prendre Guava en main, au moins pour les fonctionnalités courantes. Là où ça se complique, c’est quand on s’intéresse aux caches ou aux Futures par exemple. Là, il y a une petite mécanique à bien comprendre…

Agnès : Guava permet d’écrire du code Java en respectant une approche de programmation fonctionnelle. Est-ce que tu trouves cet aspect intéressant? Cela t’a-t-il poussé à t’intéresser aux langages respectant plus cette approche?
Alexis : De la programmation fonctionnelle alors que le langage Java n’est pas prévu pour ça, ce n’est pas risqué ? Est-ce qu’on ne risque pas de faire du code plus confus ?

Thierry: On peut répondre à ça de plusieurs manières. Au départ, j’ai trouvé que c’était super cool. Les Functions, les Predicates, les Filters, surtout combinés, c’est magique. Si on ajoute que les filtres renvoient des vues (lazzy loadées) et pas seulement des collections classiques, on a tendance à vouloir les utiliser à toutes les sauces. Et c’est là que ça devient mauvais. La team Guava le reconnait d’ailleurs volontiers. Les développeurs ont tendance à abuser de la programmation fonctionnelle offerte par Guava, là où une simple boucle « for » suffirait plus qu’amplement et serait moins verbeuse…
Ainsi, selon le cas d’usage, le code présenté plus haut pourrait honnêtement se résumer à :


List<SuperChien> superChiens = newArrayList();
for(Dog dog : dog) {
SuperChien chien = new SuperChien();
chien.setSurnom("Super " + dog.getName());
chien.setPoids(dog.getWeight());
chien.setPouvoirs(newHashSet("Code en Java", "Vole"))
...
superChiens.add(chien);
}

En plus, avec l’arrivée de Lambda prévue pour Java 8, la donne risque de bien changer. J’en avais justement discuté un peu avec Kevin. Et pour lui c’est clair, il n’y aura plus aucun développement réalisé autour de la programmation fonctionnelle sur Guava. Ça ne remet pas en cause ce qui existe déjà. Ça signifie simplement que ça n’ira pas plus loin.
En ce qui me concerne, j’avoue être un peu perplexe. Je ne suis pas très fan de la direction que prend Java avec Lambda, notamment sur les interfaces. Pour le moment j’attends de voir. Pourquoi pas ?…

Agnès : Même question sur Lombok : Utilises-tu Lombok par défaut les yeux fermés sur tous tes projets Java? Quel est le top 3 de tes fonctionnalités préférées de Lombok?
Thierry: J’ai découvert Lombok cinq minutes avant de présenter Guava durant un JUG. C’était Florent Ramière qui parlait. Moi j’étais surtout concentré sur mon intervention et j’avais un peu le trac. Je n’écoutais donc que d’une oreille. Sur le coup, je me suis dit : « qu’est-ce que c’est que ce truc la ?… » Ca avait l’air tellement magique… Un peu plus tard, j’ai revu ça sur Parleys et ça m’a fait un choc : Lombok répondait à des problèmes d’écriture de code que je me posais depuis longtemps, sans vraiment trouver de réponse satisfaisante.
Ce que j’aime avant tout dans Lombok, c’est de pouvoir générer du code avec des annotations simples. Par exemple je peux générer les getters de tout mon bean en une seule ligne. Mais surtout ça va créer des méthodes standards. Ça veut dire que je n’aurais pas à vérifier qu’un accesseur de ma classe ne fait pas un truc imprévu. Qui n’a jamais rencontré ce cas, où c’est un setter qui faisait planter tout le programme car il faisait autre chose qu’une affectation simple ? C’est le genre de petite connerie qui prend des heures à détecter. Donc en résumé, ce que j’aime, c’est de pouvoir écrire des beans dont je suis sûr et qui sont lisibles.
J’aime bien « Lombok-pg », qui est le compagnon idéal de Lombok. Il apporte une série de nouvelles annotations (ie. fonctions) assez sympas. Je pense par exemple aux extensions qui permettent d’ajouter temporairement des méthodes à un objet.
Les Dogs manipulés dans la classe « DogWithExtension » bénéficient (localement) de toutes les méthodes de « MyDogExtensionClass » et notamment de « isTooFat() » :


@ExtensionMethod({ Dog.class, MyDogExtensionClass.class })
public class DogWithExtension {
public void foo() {
Dog milou = new Dog("Milou", 12.5, ...);
boolean isTooFat = milou.isTooFat();
}
}

class MyDogExtensionClass {
public static boolean isTooFat(final Dog dog) {
double imc = dog.getWeight() / pow(dog.getSize(), 2);
return 25 &lt; imc;
}
}

Agnès : Certains reprochent à Lombok le côté “trop magique” (l’annotation @Data par exemple) ou encore le problème du contrôle de la qualité du code (warning en pagaille sur les attributs, pas de documentation sur les éléments générés)… Que penses-tu de ces limites? Sont-elles bloquantes pour toi? Cyril : Quels IDEs offrent un support correct de Lombok?
Thierry: Pour être franc, je n’utilise pas Lombok sur tous mes projets, loin de là même… Ce côté magique, ça fait peur à mes équipes. Ils n’aiment pas ça et je le comprends bien… En revanche, quand j’ai besoin d’aller vite, notamment pour des POCs, je l’intègre directement, en même temps que Guava.
J’avais écrit un petit article « rigolo » là-dessus!
J’avais fait un test : pour un bean simple, avec une dizaine d’attributs, il faut plus de deux cents lignes de code pour avoir les méthodes indispensables (constructeurs, getters, setters, hash code, etc.). Avec Lombok, il suffit d’ajouter @Data. C’est incomparable… Et c’est peut-être aussi son plus gros défaut, en plus de modifier le byte code…
Question IDE, je suis un grand fan d’Eclipse. Le Jar de Lombok permet d’ajouter le plugin à Eclipse mais aussi à Netbeans. Je crois qu’il y a quelque chose pour IntelliJ mais c’est à vérifier.

Alexis : On disait pendant un temps que Lombok ne fonctionne que sur un JVM Hotspot. Qu’en est-il aujourd’hui ?
Thierry: Là je ne peux pas répondre. Je n’utilise que la JVM de Sun…

Agnès : Question subsidiaire 😉
Tu es consultant freelance. Es-tu satisfait de ce statut? As-tu rencontré ou rencontres-tu encore des difficultés ?

Thierry: En fait je me demande pourquoi je ne l’ai pas fait avant. J’en avais pourtant eu l’occasion, à plusieurs reprises… A chaque fois, j’avais toujours une (fausse) bonne raison de ne pas me lancer : sécurité de l’emploi, paperasse, impôts, etc. Avec le recul, je réalise à quel point j’étais dans l’erreur. Devenir indépendant a changé ma vie.
Au début, j’avoue que j’avais peur tout le temps. Mon compte en banque était vide et je suis tombé sur des vrais salauds dans ma première mission. Ma petite fille venait alors de naitre. Mes nuits étaient courtes et le risque de me retrouver sans revenu amplifiait mon stress. Et puis au fur et à mesure des mois, j’ai pu souffler un peu. Ouf… A la fin de mon premier exercice, j’avais repris confiance et j’avais quelques mois d’avance à la banque pour voir venir.
Clairement, on ne devient pas freelance pour le fric. On ne le dira jamais assez. Néanmoins, c’est vrai que c’est une préoccupation importante la première année. Aujourd’hui, je peux me payer des formations, que mon ancien employeur me promettait sans arrêt mais dont je n’ai jamais vu la couleur. Je peux m’offrir le luxe d’aller à Devoxx ou de faire le tour des JUGs de France et de Navarre. Je choisis mes projets et mes clients. Je ne me laisse pas imposer ci ou ça parce que mon commercial a fait n’importe quoi. Je peux prendre des jours pour écrire ou lire un article. Bref…

Par contre, au niveau administratif, je me suis fait aider par mon comptable : le cabinet Eko. Dites que vous venez de ma part 😉 Il a écrit mes statuts, déposé tous les documents, etc. Il ne faut pas hésiter à se faire accompagner… Et tous les mois, il faut saisir les factures, faire les déclarations Urssaf, etc. Et j’avoue que ce n’est pas trop mon truc. Les boucles « for », je maitrise mais les bilans me laissent perplexe.
Je conseille le site « java-freelance.fr » qui m’a beaucoup aidé dans mes choix et mes démarches. Il est d’ailleurs tenu par une Duchesse 😉

Merci Thierry ! Rendez-vous donc au Lyon JUG le 18 septembre prochain!

Tags : , ,

Agnès CREPET est Duchess France Leader, et fait partie de l'équipe fondatrice et organisatrice de la conférence Mix-IT. Elle a été également Lyon JUG Leader pendant plusieurs années. Elle a co-fondé avec trois autres développeurs passionnés Ninja Squad, et habite aujourd'hui à Amsterdam, et est en charge de l'IT de Fairphone qui conçoit des smartphones modulables, réparables et éthiques. Suivez-là sur Twitter!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nom*

Email

Website

20 − trois =

*

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer