Un an dans le monde Java

L'an dernier, j'ai quitté l'ancienne boîte dans laquelle je travaillais sur Metz afin de rejoindre ma boîte actuelle située au Luxembourg. Avant, je faisais du PHP/MySQL, Javascript, du Python et plein d'autres choses comme de l'administration système et autres. Je regardais pas mal d'articles de Pythoniens qui aimaient bien troller au sujet de Java (quand ce n'était pas PHP), et cela a attisé ma curiosité. Qu'est ce qui peut faire que ce langage soit si mal aimé des utilisateurs de langages dynamiques alors que la plateforme Android qui était en plein boom, en faisait son langage de prédilection ? La haine était-elle liée aux salaires médians plus intéressants des développeurs Java par rapport aux autres langages ? Java est-il aussi merdique ? Peu importe la raison, je me disais que, quitte à changer de boulot, autant essayer Java/J2EE et son écosystème afin de se forger son propre avis.

J'ai eu de la chance, via Twitter, de rencontrer mon directeur actuel qui a eu le cran, voir la folie de m'embaucher alors que je n'avais quasiment jamais touché à l'univers Java en milieu professionnel. D'ailleurs, chose marrante : mon précédent boss, m'avait embauché pour faire du PHP alors que je n'en avais quasiment jamais fait avant. Cela doit être une constante dans ma vie : me faire embaucher sur un truc que je ne sais pas faire. A moins que je sois systématiquement embauché pour mes blagues pourries ... allez savoir !

Sans blaguer, j'ai été embauché suite à ce tweet

Passés les entretiens d'embauche avec l'équipe, début Janvier 2012, je découvrais le Luxembourg, mon nouveau poste et ma première mission. C'était assez excitant !

Le langage Java

J'avais fait un peu de Java en 2001 : lire un code Java afin de fournir un code similaire en C++. Mis à part le fait que Java était d'une lenteur à vomir, je dois avouer que j'étais séduit par ce langage où le mot clef delete n'allait plus hanter mes nuits. Que Dieu bénisse le garbage collector !

Arrivé sur ma première mission, je me suis plongé à hauteur de 50% dans Java, les autres pourcents étant réservés aux réunions chronovores et à la découverte des joies de l'administration et des contraintes d'accès. Le sentiment que j'avais sous Android s'amplifiait : mais pourquoi les Javaistes se compliquent autant la vie ? Pourquoi un fichier par classe ? Pourquoi autant d'inferfaces avec une seule implémentation pour chacune ? Pourquoi une architecture avec autant de couches ?

Le langage Java n'est pas à jeter : il est certes verbeux, mais reste assez lisible. A force de l'utiliser, on utilise toujours et toujours les mêmes types d'objets, les mêmes design patterns et puis, avouons le : depuis les annotations, il y a un paquet de choses qui sont devenus beaucoup plus facile à réaliser. Je pense notamment aux WebServices, à la persistance via JPA, les EJBs. J'avoue même, sans honte, que parfois j'aime coder en Java.

Java, ça peut faire mal

Les bibliothèques / frameworks

Il faut avouer une chose : c'est riche ! Les bibliothèques Java couvrent vraiment tous les usages et je ne peux pas dire aujourd'hui "non, je ne peux pas le faire en Java". Tout est faisable, il suffit juste d'avoir de la patience et du courage pour trouver ce que l'on cherche.

Il faut avouer une autre chose : c'est le bordel ! Si on utilise pas Java tous les jours, le ticket d'entrée est rude. Même avec Maven, je trouve que les bibliothèques et dépendances sous Java sont dans un bordel sans nom et pour retrouver la bibliothèque qui va faire ce qu'on lui demande, il faut se lever tôt ou savoir se servir de Google car même le Maven Central repository est parfois pas évident et pas très clair.

java et sa grande bibliothèque

Ce qui me saoule, ce sont les différentes implémentations d'une même bibliothèque. Difficile de savoir si celle qu'on récupère est la bonne et surtout si elle fonctionne. Je pense notamment à l'implémentation IBM de la classe Base64 qui ne donne pas les mêmes résultats en 32 bits et 64 bits, alors que celle du package common de Java fait très bien le boulot.

D'un point de vue frameworks, j'ai juste vu comment fonctionnaient les applications Web Java classiques, ainsi que celles utilisant Struts 2. Autant dire qu'ayant goûté à Django, Pylons ou autre comme Bottle, l'utilisation de Struts 2 est une catastrophe pour moi. Que ce soit dans la manière de router les URLs, où de gérer les ressources avec une tétrachié de fichiers XML partout. A terme, on s'en accomode mais on ne s'y fait jamais. Je ne dis pas que c'est mauvais, mais je n'en suis pas fan.

La documentation

C'est peut-être une critique infondée, mais globalement, je trouve la documentation Java très mal foutue et souvent pas assez décorée d'exemples. Par moment, c'est simplement pas à jour. La plupart du temps, je ne trouve que des Javadocs d'API, ce qui, pour moi qui débutait, était tout sauf simple. A quoi sert d'avoir le détail d'une méthode, si ni le test unitaire, ni un exemple n'est fourni avec. Je n'aime pas jouer aux devinettes à ce niveau.

Convention de nommage par moment

Si je prends par exemple le site officiel de la bibliothèque display tag , ça pique les yeux. Certaines pages sont en erreur 404 (souvent celles dont j'ai besoin) et au final, je passe mon temps sur les forums d'entraide comme stackoverflow seulement parce que l'information que je cherche n'est pas sur le site officiel (ou du moins, pas facilement accessible).

Je me demande si les mainteneurs de bibliothèques Java, ne font pas exprès de pourrir la documentation online afin de nous vendre, à fort tarif, des bouquins sur l'utilisation de Java et de son écosystème. Les bouquins sur Java, il en existe beaucoup, et des très bons, mais je reste persuadé qu'une bonne documentation en ligne complétée par des exemples, vaudra tous les bouquins du monde ... surtout quand ces mêmes bouquins ne font que donner des exemples d'utilisations courantes.

Les outils logiciels

Alors oui, je l'avoue : j'utilise RAD, Websphere et DB2 dans le cadre de mes missions actuelles. RAD étant un dérivé d'Eclipse à la sauce IBM, il est normal d'avoir les mêmes défauts : support de SVN un peu à la limite, plugin Maven obsolète qui te pond des projets en Java 1.4 par défaut et qui a du mal à se synchroniser quand on travaille sur plusieurs workspaces en même temps. Bref, c'est lent, ça rame, ça plante et même s'il y a de bonnes choses, globalement, je suis très déçu par cet environnement. Parait-il que j'ai commencé par le pire IDE qui n'a jamais été fait pour Java.

Le serveur d'application que j'utilise est WebSphere 7.5. Le WAS est d'une lenteur sans nom, ça bouffe une quantité incroyable de RAM, à configurer c'est horrible, avec une interface graphique qui date et qui n'est pas toujours très claire. Les JSP ne se rechargent pas toujours, ça ne répond qu'une fois sur deux, mais on ne sait pas pourquoi, les logs ne s'affichent pas, bref ... J'espère qu'IBM a fait mieux depuis car là, c'est tout sauf vendeur. J'ai eu l'occasion de tester GlassFish et c'est le jour et la nuit, niveau simplicité de mise en oeuvre.

Comme vous l'avez vu plus haut, j'utilise Subversion. Heureusement, c'est une version récente (avec un seul .svn à la racine du projet), mais après avoir passé quatre années sous Mercurial et maintenant que j'utilise aussi Git, revenir sur SVN est assez douloureux. On subit les commits foireux d'autres personnes, et les caprices du plugin qui ne veut plus synchroniser car il manque un fichier ou qu'il a été écrasé avec une update précédente. J'oublie toujours que je n'ai pas à faire de push après un commit, et cela me perturbe. De plus, étant intégré dans RAD, je suis obligé plus ou moins de l'utiliser en mode graphique et non en ligne de commande. Utiliser un autre outil à côté comme Tortoise, et vous obtenez de belles surprises en revenant dans l'IDE.

Les bonnes surprises pour moi sont Maven, Jenkins et Sonar : l'intégration continue en utilisant ces outils est vraiment sympa. Jenkins a le mérite d'être simple et assez complet notamment grâce à tous ses plugins, et les rapports pondus par Sonar aident vraiment à déceler des soucis d'implémentations que l'on n'aurait pas forcement vus. Enfin, comment s'en sortir sans Maven ? Je peste par moment contre lui et ses pom.xml mais la dernière fois que j'ai vu un script Ant de compilation, j'ai failli me pendre (encore de très jolis fichiers XML). Par contre, je trouve que Maven télécharge beaucoup trop de choses. Faites un projet "Offline" en Java qui utilise Maven, et vous allez avoir une surprise en regardant la taille de votre repository : on dirait qu'il a téléchargé tout Internet rien que pour votre projet.

Maven l'usine qui copie le Net

Le hardware utilisé

Alors, globalement, je ne suis pas mal loti. J'ai un PC très récent (i5 + 8 Go de RAM + double moniteur). Mais il faut au moins ça pour faire tourner son IDE, son serveur d'application et son serveur DB2 Express. Autre problème : je suis sous Windows et c'est ... lourd. Je ne compte plus les écrans bleus de la PIC après une arrivée tôt le matin.

Le truc qui me tue est qu'avant, je me contentais d'un Pentium 4 avec 2 Go de RAM pour programmer en Python et PHP, et bien que j'avais une base de données, un serveur Web, et parfois même une tripotée de programmes parasites autour, ça ne ramait quasiment jamais. Au moins, Java a le mérite de rendre heureux les revendeurs de matériel et d'offrir une justification supplémentaire à l'emploi de centrales nucléaires dans le coin.

Maven Centrale

Luxembourg oblige, je travaille sur un clavier Qwertz et même si on s'y fait, le plus dur est de switcher entre son clavier perso et son clavier pro. Je pourrais très bien mettre mon clavier français en USB dessus, ou remapper les touches, ou amener un Bepo .. mais je préfère m'y faire, pour le jour où je serais sur une mission où il sera impossible d'ajouter son propre clavier.

Le Qwertz

Les méthodes de travail

Quand je suis arrivé, l'équipe était en pleine restructuration et la méthode "agile" était sur toutes les lèvres. Réunion rapide chaque matin, mise à jour du Kanban qui a évolué plus d'une fois, retrospective hebdomadaire ... C'est instructif et permet d'avoir une bonne vision d'ensemble sur un projet. Après tout n'est pas parfait, mais globalement, on arrive à s'adapter aux demandes, et je pense que c'est l'essentiel.

S'il y a bien une chose qui me manque, c'est la maitrise de la chaine de valeur. Dans mon ancienne boîte, une application Web se concevait du début à la fin, en incluant la mise en production. Sur ma mission actuelle, il y a une équipe pour chaque chose (WAS, Batch, DB2, droits, etc ...) : c'est bien, mais ça transforme une simple mise à jour applicative en étape du Paris/Dakar. Et durant cette étape, les autres équipes n'en ont rien à faire de vos méthodologies agiles ou de votre capacité à suivre les désirs de votre client : il faut suivre la procédure, leurs procédures... et certaines fois, la procédure, c'est juste pas réaliste.

Les joies de la mise en production

Le point que je déteste le plus est l'emploi des formats Microsoft pour la documentation : Excel, PowerPoint, et Word. Pire ! Cette documentation n'est pas avec le projet, mais à côté, dans une arborescence parallèle. Tu veux mettre à jour ta documentation, il faut que personne ne l'ouvre sur le réseau sous risque qu'il soit locké. Tu ne peux pas versionner proprement les modifications et faire des diffs. Qu'on ne me parle pas du Track Changes sous Word, où on se retrouve avec du rouge et des ratures imbouffables partout. Pour moi, la documentation du projet, c'est au plus proche du code, et si possible dans un format simple : reStructuredText ou Markdown avec un générateur pour éventuellement pondre cette même documentation au format désiré.

En contrepartie, j'ai des collègues géniaux sur qui je peux compter. Ils ont tous de la bouteille en Java et du coup, il est facile pour moi de progresser rapidement avec autant de ressources à ma disposition.

L'esprit d'équipe

Et moi dans tout ça ?

Je suis plutôt satisfait de mon changement de carrière. L'objectif de découvrir Java/J2EE est rempli et maintenant que j'ai passé la barrière du langage, je vais pouvoir enfin m'attaquer aux choses sérieuses et passer au niveau 2. J'apprends beaucoup, surtout à relativiser. Techniquement, Java est intéressant même si je ne lui prédis pas un grand avenir. Les clients veulent des choses beaucoup plus rapidement, plus sécurisées, mieux maintenables, plus "au goût du jour" et surtout moins chères. Je ne sais pas pour vous, mais si on me demande tout ça, je ne pense absolument pas à Java, sans vouloir troller. Une petite frustration néanmoins, est de mettre rendu compte que ce que j'avais réalisé lors de ma première mission aurait pu être plié en un mois à fond avec Python, là où j'en ai mis sept avec Java. Ce n'est vraiment pas le même monde et je ne peux pas dire que c'est entièrement de la faute de Java mais n'empêche que je suis persuadé que la productivité avec un langage comme Python doit être bien plus grande.

A l'issue de cette nouvelle année de développement, je ne me considère toujours pas comme un développeur référent et/ou bon, mais plus comme un "junior" en constant éveil. Le temps me manque pour tester tout ce que j'aimerais tester (j'ai d'autres loisirs à côté aussi). J'ai moins de temps libre que j'en avais dans mon précédent boulot, temps de trajet oblige. Du coup, ces derniers temps, j'ai beaucoup plus lu qu'expérimenté et cela me manque beaucoup.

Résumé de ce premier 3615 MyLife

Si je dois résumer tout ce qui a été dit plus haut après une année avec Java et une petite partie de son écosystème :

  • le langage n'est pas à craindre : Java reste un langage complet et répondant à la plupart des problèmatiques
  • ses bibliothèques sont riches mais désorganisées, avec une documentation mal fichue "à mon goût" (je précise)
  • ses frameworks sont peut-être bien, je n'ai pas assez de recul. Mais personnellement, je ne suis pas fan de Struts 2 déjà
  • si vous devez avoir un IDE, oubliez et fuyez Eclipse et RAD
  • pas de nouveau projet Java sans Maven, sinon, envisagez sérieusement le suicide
  • Jenkins et Sonar sont vos amis et je suis sûr qu'il existe d'autres amis essentiels au Javaiste
  • par pitié : laissez crever SVN et CVS et orientez vous d'office sur Mercurial et/ou Git
  • la méthode de travail est la même pour tous les langages : communiquez entre vous et avec le client, faites le souvent, restez réaliste et tout ira bien
  • mettez votre doc dans un format universel et au plus proche du code. Réservez la documentation MS Office pour faire de la documentation destinée au fly-fucking
  • vos collègues sont une ressource précieuse, il faut en abuser et ne pas hésiter à donner de votre personne en retour. Ce fût le cas dans mon ancienne boîte, et j'ai de la chance que ce soit encore le cas dans ma boîte actuelle

L'année 2013 va être très sympa. Pourvu que ça dure !

Technologies et outils découverts et/ou utilisés durant cette année :

  • Java / J2EE
  • Struts 2
  • OpenJPA / Hibernate
  • IBM DB2, RAD et WebSphere
  • Maven / Jenkins / Sonar
  • JWay Formpublisher
  • Scala et Play!2 (trop peu encore)

Commentaires