Pourquoi je n’aime pas Java

jeu. 16 février 2012

Je n’aime pas Java. Pourtant il s’agit du langage où mon expertise est le plus pointu ! j’ai en effet commencé le Java il y a 5 ans. Depuis maintenant 3 ans j’en fais un usage intensif dans le cadre professionnel.

Quand je dit ici que je n’aime pas le java, je parle de l’eco-système Java, pas du langage. A vrai dire mon impression s’arrête plutôt du coté Java EE, vu que je l’ai toujours utilisé dans ce cadre.

Java, le monde de la branlette intellectuelle

Pour moi, Java, c’est ça ! Un monde où on passe plus de temps à penser de belles architectures, des architectures robustes, modulaire, soit disant maintenable, en oubliant son vrai besoin et le confort du développeur.

Durant mes années de travail, j’ai pu voir des applications en 5-6 couches avec des objets de données (réduit à leur plus simple expression, c’est à dire juste porteur de donnée) sont transformé par adapter en des DTO pour le passage à la couche suivante. Normal me direz vous si on est dans un cadre « service» ou la réutilisabilité des couches est essentiel. Sauf que non, nous étions dans une application « block » ou les couches étaient vraiment réservé et spécifique à notre application.

J’ai pu également me heurter aux applications EAR avec leur étrange structure/séparation EAR, Web, Module, … Cette étrange séparation qui rend parfois la gestion des dépendances complexe. Ce matin encore je me suis prit la tête avec une annotation qui ne s’appliquait pas à l’ensemble des éléments.

La raison ? L’annotation était dans un JAR et, même si elle était bien dans tous les build path, je ne l’avais pas packagé au bon endroit dans l’EAR pour qu’elle soit appliqué à toutes les classes. En l’occurrence c’était mes classes du projet EJB qui était oublié.

L’exemple ci-dessus n’est qu’un exemple parmi d’autre. Mais dans le monde Java, il y a des tas de préconisation et de norme d’architecture que l’on ne s’imposerait pas dans d’autre technologie…

Oh, un dernier point… A quoi ça sert de découper en des dizaines de petits jars qui sont, au final, tellement lié entre eux que l’insertion d’un jar entraîne automatiquement l’insertion du second ? Essayez d’introduire Spring dans votre projet et vous comprendrez. Pas de tricherie, faites le sans un gestionnaire de dépendance tel que Maven ! Au final vous verrez que, en plus du spring « core», vous aurez embarquez 5-6 autres jar de spring (je ne compte pas les dépendances externes que je comprend parfaitement).

Java, le monde du framework faussement simple

Autre chose que je déteste dans Java ? Les frameworks !

Ne vous trompez pas, je ne suis pas pro from-scratch. J’aime les frameworks qui me facilite le travail. Malheureusement, j’ai du mal à rentrer les frameworks Java dans cette catégorie. Pourquoi ?

Voilà comment se sont déroulées toutes mes expériences d’intégration de framework :

  • J’intègre le framework. Je me rends alors compte qu’il faut faire un fichier XML de paramétrage obligatoire d’environ 10 km de long. Je prends des tutoriels, j’essaye de comprendre, je reproduis. Go, ça a l’air de marcher !
  • Je commence donc à travailler tranquillos ! Maintenant que j’en ai * pour le paramétrage, le framework me fait gagner du temps, c’est cool.
  • Et là, pof ! c’est le drame ! J’ai un comportement étrange :/ La recherche sur internet me faire dire que j’ai configuré de façon incomplète ou mal mon Framework.
  • Et hop c’est parti pour une seconde vague de configuration qui va me couter un bras pour faire marcher le tout. Ok, sur une grosse appli j’aurai peut être gagné du temps. Mais quand vous travaillez sur un tas de petites applications, là, ce n’est plus du tout sûr.

Ce dernier constat est celui qui me fait le plus bizarre : les frameworks java sont un gain de temps sur une grosse appli et une perte sur une petite application. Je vais voir coté Python, langage que j’apprécie, et c’est tout l’inverse ! On préconisera un framework pour les petites appli ! A vrai dire, rien d’étonnant ! C’est dans les petits appli que l’on n’a pas le temps d’investir !

Ok, dans mon exemple le réel problème se situe dans mes compétences : j’ai beau être un développeur expérimenté je n’ai encore que peu de recul sur le paramétrage de Framework. En même temps je n’ai pas besoin d’avoir ce recul dans les autres langages…

Mon ressenti concernant les framework Java, c’est qu’ils ont la philosophie inverse du KISS unix que j’apprécie temps => 1 programme = 1 fonction. Les frameworks java veulent faire le code du développeur, le café, et le massage de pieds… Manque de post, moi le massage, ils me les cassent !

La java et son héritage de lourdeur

Dernier point, je pense que l’héritage Java (qui assure une rétro compatibilité quasi totale) est nuisible sur le long terme. On se trimbale beaucoup de difficulté « historique » qui alourdisse inutilement le langage.

Un exemple ? Essayer de manipuler des Buffers par exemple !

Ce n’est pas la seule fonctionnalité qui est difficile à manipuler et entraîne la création de nombreux objets pour « pas grand chose ».

Je sais que ce post est un peu « troll », mais depuis le temps que je me casse les dents sur ces problèmes, il fallait que ça sorte ! Après je me ferai un plaisir de lire vos commentaire qui, peut être, viendront me faire comprendre que mon impression découle uniquement de mon cadre projet.