Les développeurs adorent générer les projets via des archetypes Maven, ou si vous n’avez pas de chance avec JHipster.
Vous n’avez pas commencé à coder, mais vous avez déjà 25 classes et un pom.xml de 2000 lignes. Soyons franc, la seule chose à faire après ça devrait être rm -rf * et repartir sur des bases saines, mais bon, c’est comme ça qu’il faut faire il paraît.

Le projet devient un jeu où le but est simple, le mot-clé new est interdit. Plus il y a de magie, plus il y a d’annotations, mieux c’est.

Métriques ? Annotations.
Mocks ? Annotations.
Dépendances ? Annotations.
Getters ? Annotation (coucou lombok).
Routes HTTP ? Annotations.
Cache de la DB ? Annotation.
Mapping entre objets ? Annotations.

Je pourrais continuer comme ça longtemps…​

La plupart des projets pourraient avoir une class Main qui serait plus ou moins :

Où database et cache implémentent une interface (pour écrire facilement un mock).
Bien sûr, comme dit précédemment utiliser new est interdit, donc vous ne verrez jamais ça. J’ai eu des discussions hallucinantes où les devs ne pouvaient même pas envisager ne pas utiliser @Inject, comme si on leur demandait de coder avec ed à la place de leur IDE.

On préfère avoir une mega usine à gaz qui explose au runtime. Bah oui, c’est super utile d’avoir du typage statique quand derrière on a du bean not found au démarrage du projet (démarrage qui met 2 plombes au passage généralement).

Vous ne pensiez quand même pas pouvoir utiliser les clients officiels Kafka, Elasticsearch etc…​ quand même ?

Non, il faut utiliser Spring Kafka, Spring Elasticsearch, Spring Redis…​ ces libs cachent les implémentations officiels, sont très peu flexibles, et sont surtout totalement inutiles. Bah oui, faire KafkaConsumer consumer = new KafkaConsumer(config) c’est trop compliqué. Mais bon, le but de ces frameworks est de cocher des cases, pour pouvoir dire "Oui c’est supporté !!" dès qu’une techno est mentionnée en réunion.

JPA, AspectJ, Hibernate…​ Il y aurait tellement de choses à dire sur ces technos sorties de l’enfer.

Spring Data ? True story, j’arrive sur un projet : "gnagna microservices, gnagna stack moderne, gnagna on est le meilleur projet de la ville…​" j’ouvre un fichier et je tombe sur une tonne de fonctions ressemblant à :

WTF ? C’est un vrai nom de fonction qui était dans le projet, hein, et que j’ai conservé précieusement pour la ressortir. C’est un peu à ce moment où je me suis dis que je devais soit repasser sysadmin, soit trouver une boîte qui ne fait pas du Java (j’ai fait l’un puis l’autre d’ailleurs). Et ces fonctions ne choquaient PERSONNE sur le projet, c’était "business as usual".

Une classe == une interface, c’est la règle ! Chaque requête HTTP faisant un accès à une base de données devra aussi au moins créer :

Pourquoi ? Car ça fait 20 ans qu’on cargo cult le Gang of Four.

Avec les starters Spring et compagnie, votre pom.xml fait maintenant 3500 lignes. Sauf qu’en fait le pom a aussi un pom "parent", un "BOM"…​ chaque montée de version d’un de ces trucs vous coûtera des jours de travail.

D’ailleurs, parlons en des montées de versions. Chaque montée de version de Spring et de ses starters amènera son lot de bugs bien louches, et beaucoup de projets/libs n’ont même pas de changelog donc amusez-vous bien lors du débugging.

La stack Spring Cloud Netflix (Ribbon & co) est un enfer.

Votre projet est maintenant un load balancer bugué, pas flexible, exposant très difficilement ses métriques. C’est toujours cool quand on on se rend compte que N % des requêtes partent dans les limbes sans avoir aucune métrique et aucun moyen de débuguer le truc.

J’ai travaillé avec de très bons développeurs Java, certains "connus". Des devs qui en font "depuis 199X". Des gens qui font du Spring depuis le tout début. Même eux ne pourront pas vous aider, le framework est juste trop complexe. Et quand ton annotation marche pas car un truc rentre en conflit avec un autre, va trouver la source du problème…​

Je me rappelle d’une montée de version de Spring où mon CTO de l’époque avait tweeté : "Quelle douleur les montées de version Spring et ces dépendances. A la limite de l’abandon mais toujours en cours". Oui, les montées de versions étaient dingues, de mémoire celle là commençait à se compter en mois.

Malgré cette complexité ENORME, il ne faut surtout pas changer ! Incompréhensible.

Tu passes 2 semaines sur un bug Ribbon, tu mets 1 mois à monter de version Spring, tu mets 3 jours à monter de version ton pom parent, ton "microservice" avec 10 endpoints REST a 60 classes, 10 000 lignes de code et a un pom de 3000 lignes…​ Mais tout le monde est content et continue dans sa lancée !

Sur un des projets où je suis intervenu, quelques développeurs (généralement ceux qui avaient codés avec autre chose que Java dans leurs carrières) voulaient lancer un microservice avec Vert.x pour tester (certains l’avaient déjà utilisés en prod, d’ailleurs j’en ai également entendu de bons retours).
Bien sûr les autres développeurs étaient contre (fallait faire du microservice mais avec Spring), et d’ailleurs les décideurs étaient aussi contre car : "Quand je demande à la SSII du coin des développeurs Spring ils en ont en stock". OK.