.NET a beau être né dix ans après Java, il reste depuis la version 2.0 systématiquement en avance sur lui. La gestion des lambda, les classes anonymes, la programmation fonctionnelle, les tâches, les délégués, etc. : à part l’injection de dépendances, il n’y avait pas un domaine du langage où .NET ne démontrait sa suprématie (bon, OK, j’exagère peut-être un peu juste pour taquiner Nico 
). Et encore, l’injection de dépendances avait tellement été mise à toutes les sauces avec Spring qu’il fallait presque faire une injection pour ajouter deux entiers.
Un article sur InfoWorld en date du 11 septembre 2015 annonce un effort d’Oracle pour rendre plus simple la gestion des dépendances et de la modularité en Java, et cet article entre en résonnance avec les multiples problèmes que je vois professionnellement autour de la gestion du CLASSPATH ainsi que des conteneurs OSGI. Tous ces problèmes sont réglés depuis longtemps en .NET grâce à NuGet, qui fait même désormais partie intégrante du nouveau SDK Core .NET.
Si l’on ajoute à ça que, de toute façon, avec l’avènement des conteneurs et des architectures à microservices, la modularité est désormais hissée au niveau du service lui-même (ce qui est le niveau de granularité idéal), on se rend compte qu’Oracle est encore en train d’apporter une solution avec Jigsaw à un problème qui n’en est désormais plus un. L’inconvénient d’avoir une gouvernance qui avance à la vitesse d’un escargot rhumatisant…
Pendant ce temps, du côté .NET, ça avance sur l’asynchronisme à tous les niveaux, les TypeProviders en F#, la compilation native, la structure modulaire non pas des dépendances mais carrément de la runtime, le calcul parallèle, etc. Java garde une tête d’avance pour ce qui est du nombre de projets utilisateurs, mais pour ce qui est de la richesse fonctionnelle, il y a du boulot pour rattraper .NET. Et il ne fait que peu de doute que le second critère est plus important que le premier.
