Un java-iste espère vous faire aimer son langage fétiche…

Bon si vous me lisez depuis un p’tit moment vous n’êtes pas sans savoir que je suis Java-iste. Java, y en a qui aiment, d’autres qui détestent, mais ça ne laisse pas indifférent, comme la Marmite quoi (bon je vous rassure, c’est bien meilleur :p ) ! Enfin bon bref, si vous détestez Java je vous invite à lire ce billet, en espérant que ça vous fasse changer d’avis… un-peu. 🙂

Débloque les + belles offres tech en 10 mins

Dans la suite je vais essayer de vous vendre Java à travers plusieurs caractéristiques, notamment le typage fort, le mode de fonctionnement de la JVM et autres.

Le typage fort

Certains développeurs ne jurent désormais plus que par le typage faible, à savoir que vos variables ne sont pas typées explicitement quand vous écrivez votre code mais que ce type se révèle à l’exécution. Il est vrai que ça a plusieurs avantages, notamment on peut faire comme ça du polymorphisme sans héritage. Si si, essayez avec Javascript ou même avec C avec un void*, ça fonctionne très bien.

Le problème de ça est que lorsque vous écrivez votre code vous n’aurez aucun outil qui vous alertera si vous êtes en train de faire une erreur. Par conséquent, vous aurez un degré de confiance moindre dans celui-ci, notamment lorsque vous livrerez en production. Qui n’a pas vu sur une page web en PHP un message alertant que telle ou telle variable est indéfinie ? Bon d’accord, ça n’arrive que si le serveur web est mal configuré mais quand même, c’est un problème bien plus général. Bref même si on gagne une certaine flexibilité au niveau de l’écriture du code, on perd un sacré filet de sécurité.

Alors bien sûr il est possible de régler en grande partie ces problèmes par un usage intensif des tes automatisés, mais bon on n’est jamais complètement sûr. C’est particulièrement le cas si vous devez concevoir une API, ou au contraire en utiliser une venant de personnes tierces.

Dans la même veine, les IDEs ne sont pas capables d’analyser en profondeur un langage faiblement typé, et donc vous ne pourrez pas bénéficier d’un grand nombre de leurs fonctions, notamment concernant le refactoring si vous n’utilisez pas du typage fort. Un peu dommage sur le long terme non ? 😉

Un dernier point qui montre que le typage fort n’est pas si mal que ça est que certains langages s’y mettent au moins partiellement. C’est notamment le cas de PHP depuis la version 5, et la version 7 du langage va renforcer ce point.

Java est un langage compilé…

Java est en effet un langage compilé, ce qui signifie que quand vous modifiez du code il faut repasser par une phase de compilation pour voir votre modification effectivement prise en compte. L’avantage de la compilation est qu’elle va permettre de détecter un grand nombre d’erreurs… et de warnings. Et oui, un code partant en production ne devrait comporter aucun warning, même si c’est hélas rarement le cas. Il s’agit d’une discipline à adopter, mais là c’est un autre sujet.

Alors certes vous me direz, dans des langages sans étape de compilation vous pouvez gagner du temps. C’est en fait uniquement en partie vrai. En effet sans vous le dire ces langages interprétés convertissent à la volée votre code en langage machine, sauf que… pour des raisons de performance le résultat de cette conversion est fréquemment gardé quelque part en cache. Par exemple Apache conserve en cache du code PHP pré-processé si vous utilisez Smarty ou Symfony 2, et ainsi de suite. Ca peut amener à des bugs assez difficiles à comprendre tant que vous ne connaissez pas le truc concernant le cache, et ensuite il faut savoir comment vider ce dernier et éventuellement redémarrer l’outil pour lequel vous développez, par exemple un serveur Apache ou un navigateur web.

Enfin comme dit précédemment, la compilation a l’avantage de permettre la détection de certaines erreurs au plus tôt. Or plus les problèmes sont détectés tardivement, plus il est coûteux et pénible de les corriger. Bref à défaut d’avoir la compilation pour détecter une partie des problèmes à votre place ce sera à vous de passer par tous les chemins du code pour faire cette détection, ce qui peut parfois devenir très compliqué… surtout si votre langage non compilé permet de faire du multithread.

… mais aussi un langage interprété

En effet Java est un langage hybride. Il est compilé en une sorte d’assembleur pour la JVM – le bytecode – et ensuite cette dernière interprète cet assembleur pour exécuter votre programme. La raison tient à la philosophie de Java, Write once, run anywhere. Ca explique aussi en grande partie les performances déplorables des premières versions de la JVM, même si c’est depuis longtemps du passé.

En fait la JVM interprète à la fois ce bytecode, et en même temps effectue des opérations de compilation dessus. Je m’explique : en fait quand vous exécutez un programme Java, la JVM va surveiller en permanence l’exécution de celui-ci et avec des métriques va déterminer quels sont les segments du code les plus souvent appelés. Ces derniers vont être alors compilés en mémoire en code machine, lequel sera nettement plus rapide. On appelle ça la compilation Just In Time (JIT), et c’est d’ailleurs très répandu maintenant dans les navigateurs Web pour le Javascript.

Tout ceci signifie qu’en fait un programme Java sera plutôt lent au démarrage, même si c’est relatif, et deviendra de plus en plus rapide au fur et à mesure de son exécution, car la JVM compilera en natif de plus en plus de bouts de code. On appelle ce phénomène le warm-up, un peu comme pour les courses automobiles. Ca explique pourquoi au final du code Java peut s’avérer plus rapide qu’un code C équivalent, si ce dernier n’a pas été vraiment optimisé. Un autre avantage de la compilation JIT sur les programmes compilés statiquement est que le compilateur JIT peut s’adapter dynamiquement à l’hôte. Ainsi si votre processeur supporte les instructions AVX un programme en Java pourra les exploiter sans recompilation, alors que le même programme C aurait besoin d’être recompilé pour les exploiter… et ne fonctionnerait plus sur les processeurs ne possédant pas ces instructions.

Le garbage collector

Si vous connaissez un peu le monde Java, vous n’êtes pas sans savoir que cette dernière utilise un ramasse-miettes appelé aussi garbage collector (GC), dont nous expliquons dans les grandes lignes le fonctionnement ici. Pour faire simple celui-ci permet de supprimer de la mémoire les objets qui ne sont plus référencés.

Dans les premières versions de Java celui-ci était un vrai boulet car il causait de vrais problèmes de performance. Ainsi régulièrement une application Java se retrouvait figée, le temps que le GC s’exécute. Mais bon depuis du chemin a été fait, et les algorithmes du GC ont été fortement optimisés. Ca explique qu’avec un GC de type Concurrent Mark and Sweep l’impact du GC sur les performances soit fréquemment imperceptible, pour peu que votre programme ne soit pas trop mal écrit.

Alors forcément si vous êtes un fan du C et de la gestion manuelle de la mémoire ça ne va pas vous plaire. J’avoue que ne pas gérer à la main mes pointeurs me manque des fois mais quand même. Ca évite aussi pas mal de fuites mémoire, même si ce n’est pas le cas pour toute. Ainsi en Java vous pouvez parfaitement créer une fuite mémoire en remplissant une Map sans jamais la vider, ou encore mettre vos programmes en échec en ne fermant pas vos descripteurs de fichiers. Comme quoi le GC simplifie bien des choses mais pas tout.

Les applications graphiques

Soyons honnêtes : les applications graphiques se font de plus en plus par l’intermédiaire de navigateurs Web, même si je ne suis franchement pas fan de cette tendance. Mais bon, toujours est-il que vous pouvez faire des applications de bureau.

Au commencement en Java dans ce domaine était AWT, un machin qui prétendait reprendre les composants natifs du système mais qui s’est avéré lent et moche. Ensuite ils ont sorti Swing, moins lent mais toujours moche, quoique depuis Java 5 ça se soit nettement amélioré. Swing fonctionnait à base d’images qui matérialisaient les widgets, et en fonction de là où l’utilisateur saisissait quelque chose à la souris ou au clavier, le signal capturé était envoyé au widget correspondant à l’image. Maintenant le vrai toolkit graphique pour Java est JavaFX 2, qui repose sur les mêmes concepts que XAML pour les gens du monde .Net.

Bref même si Java n’est pas la meilleure techno qui soit pour faire des applications graphiques, notamment en raison du mécanisme de warm-up évoqué plus haut, il est possible toutefois d’obtenir un résultat sympa rapidement. Pour les aficionados de la planification le logiciel Sciforma est notamment réalisé en Swing.

La communauté Java

La communauté Java est très importante par le monde. Ce point offre l’avantage que quand vous rencontrerez un problème vous obtiendrez très rapidement la réponse. Dans d’autres technos telles que Javascript c’est nettement plus compliqué, d’autant que les soucis interviennent souvent suite à une combinaison de facteurs tels que le navigateur utilisé et sa version, le layout de la page et autres, qui font qu’il est difficile d’obtenir de l’aide.

Par ailleurs ceci permet d’avoir de nombreux frameworks et bibliothèques de fonctions, dont Spring. Le point négatif de tout ça est que les gens derrière ne savent plus coder car ils se contentent d’assembler des briques qu’ils ne maîtrisent pas, par contre ça peut permettre des fois de gagner un temps précieux et d’éviter d’avoir à réinventer la roue.

Enfin comme il y a de très nombreux développeurs Java de par le monde, c’est d’ailleurs la techno qui recrute le plus à l’heure actuelle, vous trouverez probablement de l’aide en posant votre question sur un forum ou encore sur Stack Overflow. Et ça c’est vraiment confortable, mes cheveux arrachés pourront en témoigner. 😉

En bref

Java est principalement un langage orienté utilisation serveur… mais qui est quand même assez ouvert pour faire à peu près tout, y compris des jeux vidéo dont le célèbre Minecraft (bon OK pour ce domaine il y a bien mieux comme techno). Pour la petite histoire, le système d’exploitation a même été créé en utilisant ce langage.

Il n’est certes pas parfait, mais le typage fort apporte une certaine rigueur à la manière d’écrire le code, et d’autre part il est bien plus portable que d’autres langages comme le C. Mais d’un autre côté il lui manque des trucs bien sympa qu’on trouve dans d’autres technos telles que pouvoir passer des fonctions en paramètres d’autres fonctions.

Par ailleurs la JVM forme un écosystème puissant qui permet de faire fonctionner des programmes qui sont écrits dans des langages autres que Java, dont Groovy, Scala ou encore Jython, un interpréteur Python. Et pour ce dernier point la JVM a très peu de concurrents, hormis .Net qui pendant longtemps n’a pas été officiellement multiplateforme.

Et pour la petite histoire si votre IDE n’est pas Visual Studio ou Code::Blocks il y a de fortes chances qu’il soit écrit en Java, comme quoi… En espérant que tout ceci vous ait au moins convaincu de jeter un oeil à Java. 🙂

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• De la nécessité d’utiliser des structures de données thread-safe en environnement multithread
• Le fonctionnement du garbage collector
• Quelques principes d’architecture d’applis Java/JEE

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn