#SylvainCher journal, la dernière fois, je te racontais comment j'étais arrivé sur ce fameux projet Java. après mes 15 années et un peu plus sur une stack.net. Aujourd'hui, il me faut te raconter en détail comment ça se passe une fois qu'on est dedans. Parce que je te cache pas que les questions fusent bien souvent, et pas forcément dans des directions très constructives. Parce qu'autant vouloir connaître les difficultés d'un changement de langage, c'est légitime. Autant chercher à me faire dire quel langage est le meilleur, pour moi ça n'a absolument aucun sens. Je vais d'ailleurs commencer par ça. Non, Java n'est pas meilleur que C#. Qui n'est pas meilleur que Java ! Cette comparaison pourrait éventuellement avoir lieu si on mettait en présence des versions hétérogènes, genre comparer C#11 à... Java 8, là oui, je te dirais clairement que la dernière version de C# est meilleure. Mais cette comparaison-là n'a ni valeur, ni intérêt. En revanche, cette histoire de version me semble tout de même pertinente à évoquer. Je suis globalement passé de C#, je ne sais plus, je crois que j'étais en 10 ou 11, à Java 21. Autant dire les versions parmi les plus récentes de ces deux langages. Et je dois bien vous dire qu'il y a très peu de différence entre les deux. En fait, Java 21 a en réalité plus d'écart avec lui-même dans sa version 8 qu'avec C# dans ses dernières versions. L'équipe que j'ai rejoint se traînait un historique en Java 8 depuis pas mal d'années. Et j'ai assez rapidement pu constater que je maîtrisais mieux certains aspects modernes du langage que d'autres personnes. Typiquement, la gestion du pattern matching, et en particulier la syntaxe des switches qui va avec, c'est semblable à ce qu'il y a en C#. J'étais pas perdu, et j'ai pu l'expliquer à mon équipe, alors que ça faisait vraiment pas longtemps que j'étais là. Il en va de même pour les records, et la plupart des classes de base en fait. La seule grosse différence, je dirais, ça tient à la gestion des collections. .NET possède tout un tas d'interfaces, d'implémentations qui permettent de choisir finement sa stratégie de collection. Sauf que, spoiler, la plupart des devs s'en foutent et utilisent toujours les mêmes types et ne comprennent même pas ce qu'il y a dans chaque implem. Côté Java, on a quelque chose que je qualifierais peut-être de plus straightforward. Et l'apprentissage majeur à envisager, je pense que ça se trouve côté utilisation des streams. Mais à part ça, Java, C#, Java, C#, rien de bien notable. Bon, maintenant que je peux constater que passer de C# à Java est globalement un non-événement, il va falloir que je le confesse, mais il y a quand même un truc vraiment chaud quand on fait ce switch-là. C'est pas le langage, mais c'est tout aussi impactant. Il s'agit de l'IDE. J'ai passé 15 ans à maîtriser à fond mes raccourcis clavier, toutes les fonctions spécifiques de Visual Studio, de plein de plugins auxquels je m'étais habitué. Et là, bim, du jour au lendemain, je me retrouve sur IntelliJ, avec absolument aucun raccourci clavier en commun. Je ne te raconte pas la tronche de mon écran les trois premières semaines quand je tapais par automatisme mes raccourcis clavier Visual Studio. Il se passait bien souvent des choses étranges et pas forcément souhaitées. Pour pallier à ça, un collègue m'a conseillé un petit plugin pour IntelliJ qui s'appelle Key Promoter. Et en fait, il t'affiche les raccourcis à chaque fois que tu fais une action au clic. Et en vrai, c'est salutaire quand on doit prendre en main un nouvel environnement. C'était assez cool ça. Enfin bref, cette acclimatation m'a quand même pris quelques, allez, courtes semaines. Mais il fallait vraiment passer par là pour que je puisse retrouver mon aisance, ma vélocité minimale au quotidien. Donc je disais, switch langage, facile. Check. L'IDE, un peu plus compliquée. Mais, allez, check aussi. Qu'est-ce qu'il reste à switcher dans ce genre de choses ? Eh bien, en fait, le plus gros morceau. Si Java en tant que langage n'est pas vraiment un problème, Java en tant qu'écosystème, c'est une autre histoire. Dans le désordre, j'ai découvert et j'ai dû apprendre à naviguer, à utiliser des trucs comme Maven, Spring, JPA, auxquels sont venus s'ajouter des éléments de stack que je ne connaissais pas encore trop bien, genre Kafka. Et là, je vais pouvoir causer. Pour Maven, j'ai pas cherché à en avoir une compréhension bien profonde. J'utilise au quotidien, ça fait le taf. Mais au moindre problème, faut que j'aille demander aux experts. Mais en vrai, ça me convient super bien, parce que c'est une situation rare, la plupart du temps, il n'y a pas de problème autour de Maven. Les configs sont posées, ça build, ça fait le taf. Pour JPA, je suis pas fan de l'approche. Mais en vrai, ça reste anecdotique, on passe pas notre temps à écrire des requêtes. Moi je suis là concrètement pour amener du craft, de la bonne pratique. Donc je me concentre sur la complexité essentielle et du coup sur le code plutôt métier. Donc allez, c'est ok aussi. Enfin, gros gros incontournable... Spring. Ah là ça va faire grincer mais... Putain, je déteste Spring. Il y a trop de magie, c'est trop envahissant. Je me suis retrouvé à poser des questions que j'avais jamais eu à me poser en .NET à cause de Spring. Quand on fait de l'archi hexa, avec un cœur de domaine globalement très propre et vraiment agnostique de toute dépendance externe, Spring est une purge. Le système par annotation qui a l'air simple, qui cherche à faciliter l'expérience de dev, moi je le trouve beaucoup trop intrusif et pas du tout explicite. On va coller des décorations sur des interfaces, sur des implémentations, et Spring, poum, il va te faire la magie, les lier, les instanciéer comme il veut. Et j'aime pas ça. Vraiment, j'aime pas ça. J'ai une très nette préférence pour les déclarations explicites des conteneurs d'injection de.NET Core. Mieux, ces déclarations explicites, elles me permettent de paramétrer beaucoup plus sainement quand j'injecte des implémentations. In-memory côté test, par exemple, ou quand je souhaite justement paramétrer mon implèm réel pour la prod. Mieux encore, je peux mettre ces injections sous test unitaire, sous test d'archi. Pour faire tout ça, Spring gère une espèce de magie qui est cachée des devs qui, je suis désolé, mais la plupart ne comprennent pas du tout ce qui se passe sous le capot. Et comme le disait Jérémy, l'ami Jerem sur le podcast PunkinDev il y a quelques années, "si c'est magique, c'est que t'as rien compris". Et je déteste utiliser des trucs sans comprendre ce qu'il y a dessous. J'ai l'impression d'être le chien du mème avec les pattes sur son clavier où il y a le titre "I have no idea what I'm doing". Donc ouais, clairement, cette partie-là ne me plaît pas dans l'écosystème Java. Le dernier petit truc qui me chafouine un peu, c'est plus côté environnement global. Et c'est lié plus quelque part à mon client et au contexte dans lequel je suis qu'à Java en général. Là, on se coltine un WSL, donc un Linux sous Windows. Ce qui, globalement, selon moi, synthétise le pire des deux mondes. On a la lourdeur, la laideur d'un Linux, tout en ayant la lenteur et l'instabilité d'un Windows. C'est fantastique. Mais peut-être un jour, il faudrait que je parle des Linuxiens, d'ailleurs. Non, ce n'est pas le sujet. En résumé...Ouais, Java c'est un chouette langage. C'est une chouette stack, globalement. J'attends bien impatiemment quelques features qui arriveront normalement avec Java 23 et qui me manquent par rapport à C# que j'avais déjà avant. Mais en vrai, c'est pas grave. Donc non, Java n'est ni pire ni meilleur que C#. Je trouve que les deux sont vraiment équivalents et permettent de faire globalement les mêmes choses avec les mêmes qualités d'expressivité. Passer de l'un à l'autre, pour moi, ça n'a pas été le grand chamboulement auquel j'avais tendance à m'attendre et que la plupart des gens semblaient me promettre. Et quelque part, ça en devient même frustrant. Au final, j'en viens vraiment à me demander pourquoi le monde du recrutement dans le dev est aussi siloté et aussi rigide autour de ces deux stacks qui sont pourtant tellement compatibles...
