Pourquoi je n’aime pas Java

jeudi 16 février 2012 | Catégorie Programmation

Pourquoi je n’aime pas Java

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.

Commentaires

Par Phalae le dimanche 25 mars 2012 à 23:11

Yop,

1. Peut de gens sont contre la branlette
2. Effectivement Jave/J2E n'est pas fait pour les humains, mais bien pour des générateurs de code. Un Framework devrait s'utiliser avec un outil ... pas de configuration manuelle.
3. Effectivement cela génère une masse de code impressionante.
4. Essaie de compiler GWT .... gentoo a abandonner.
5. J'aime les Frameworks ... mais il faut capitaliser dessus, sinon c'est une réelle perte de temps ... pas bon pour les trolls ;-)
6. Il faut comparer avec de grosses applis sans Framework ... cf Freenet, cela implique d'autres soucis ...

... en bref, si on peut choisir, c'est une question de combat. Se taper un Controller MVC il a la main cela se faisait il y a 10 ans. On en ai train de peter celui de Freenet car par assez flexible ... ;-)

Par Armaklan le lundi 26 mars 2012 à 09:43

Merci pour ta contribution :)

J'y répond ici même :
1/ Je pense que ta réponse se passe de commentaire :p
Bon en l’occurrence, quand elle est intellectuelle je pense plutôt que c'est de la perte de temps et d'énergie.

2/ Le problème des outils, c'est qu'il masque la complexité. Du coup le jour où tu as un soucis, tu ne sais même plus par quel bout prendre le code et l'analyser.

Un outil c'est bien, mais il faut comprendre ce qu'il fait, sinon c'est un danger.

5-6/ Je ne suis pas fondamentalement anti-framework. Il y a de très bon framework qui sont simple et fonctionnel. Mais pas les framework J2EE :p

Par cyan le lundi 02 avril 2012 à 20:32

Je ne savais pas que j'avais été si galère. (J'en ai pas fait depuis mes classes). Python, que j'utilise beaucoup, reste cependant le langage où le packaging est un des plus pénible à mon goût. Pour un peu que ça dépende d'un framework hors des standard de python, on est dépendant de leur bonne installation sur les setuptools ou de leur bonne implémentation dans les outils comme cx_freeze etc.. Bref si je devais faire du logiciel pour windows, je ne ferais pas de python.

Par Wilhem Scream le lundi 02 avril 2012 à 22:31

"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"

Ben à faciliter le développement, sans doute. Moi-même, j'aime bien séparer en modules, et je trouve ça beaucoup plus pratique que d'avoir un énorme projet. Se passer de Maven (ou autres outils assimilés, même si je n'en connais pas d'autre) me paraît de toute façon être une erreur, même sur un petit projet.

"Voilà comment se sont déroulées toutes mes expériences d’intégration de framework [...]"

C'est parce que tu utilises les frameworks comme beaucoup de monde le fait, à savoir d'une mauvaise manière (je le faisais également au début) : les tutoriels, c'est sans doute bien, mais ça ne dispense pas du tout de lire la documentation du framework. 90% (et même plus) des erreurs de configuration des frameworks viennent de fichiers de configuration copiés/collés depuis des tutoriels, alors que le besoin du projet ne correspond pas tout à fait à ce que montrait le tutoriel.
On perd généralement moins de temps à lire la doc - même si elle est bien fournie, ce qui est d'ailleurs généralement bon signe - qu'à recopier, pour ensuite devoir faire des recherches quand on a des erreurs.
Honnêtement, pour moi, le framework n'est pas là pour forcément faire gagner du temps (surtout quand il est nouveau pour le développeur !), mais pour "standardiser" l'architecture et le développement, et pour rendre l'appli plus solide.
Je suis tout à fait d'accord que les frameworks java ne respectent pas le principe KISS. On aime ou n'aime pas. C'est de toute façon assez compliqué sur des applications d'une certaine taille. Ce serait tout à fait faisable, mais ça décuplerait le nombre de dépendances d'une appli, et les problèmes de versions incompatibles. S'il y a des dizaines de personnes sur le projet, ça le fait... A quelques uns, c'est quasi ingérable.

Sinon, j'ai moi-même pas mal de trucs à reprocher à Java, mais ce serait moins dans son écosystème que dans ses fonctions de bases, sa syntaxe etc. Je trouve qu'il manque pas mal de petits "trucs" pour faciliter le développement.

Par Armaklan le mardi 03 avril 2012 à 11:06

Hum... Pour la lecture de la doc des frameworks, je plaide coupable. J'avoue que je ne m'adonne que rarement à cette activité. Cela dit pas mal des docs que j'ai vu sur les frameworks Java sont un peu... aride à la lecture ;)

Et c'est tout aussi vrai que quand je me suis mis à Django, je l'ai fait avec la doc sous la main...

Pour Python, je rejoint la remarque qui est faite : le packaging est l'un des points faible de ce langage.

Par Wilhem Scream le mardi 03 avril 2012 à 16:02

Vi, j'avoue, les docs ne sont pas toujours faciles à lire. Surtout dans un openspace, où il y a tout le temps quelqu'un qui parle :p

Par Patrick Vandermaesen le mardi 03 avril 2012 à 18:01

Tout à fait d'accord avec ton analyse mais ceci dit je suis dev java depuis 10 ans quand j'utilise Java j'essaye toujours d'éviter les FW un max et de faire du PHP like en jsp/java cela marche assez bien, car java en théorie est un beau language avec assez peu de défaults. Le plus difficile c'est de convaincre les "manager" qui adore certains mots magiques comme J2EE, EJB, Servlet ou web service sans vraiment savoir de quoi ils parlent et ce que ca va leur couter de travailler avec ces usines à gaz.

Par Phalae le mardi 24 avril 2012 à 17:07

Apache Wickets semble tenter de résoudre le problème des Frameworks J2EE.

FProxy, le frontal Web de Freenet est en cours de réécriture avec ce framework ... des avis ?

Par Armaklan le mercredi 25 avril 2012 à 21:57

Malheureusement je ne connait pas ce framework. Je le met toutefois dans ma liste de chose à tester ;)

Si tu as des informations plus concrète sur le sujet, je suis intéressé.

Fil Rss des commentaires de cet article

Taverne d'Arma