Un Java One spécial se profile, 2015 étant l'année des 20 ans de Java. Cela fait également 20 ans que j'exerce à titre professionnel l'activité de développement informatique. Pour être précis, en 1995 je travaillais en alternance et l'arrivée de cette nouvelle plate-forme semblait amorcer une révolution. Je vous propose au travers de mon prisme, de revivre ce qui paraissait génial à l'époque, et ce que je pense être les meilleurs atouts de Java en 2015.
Tout d'abord, un peu de contexte
Les piles de développement régulièrement croisées étaient Visual Basic, Borland C++, Visual C++ ou bien entendu du C/C++ sous vi pour le monde UNIX. Internet était à ce moment-là l'Internet des geeks. Des modems poussifs complétaient nos immondes tours beiges. Internet + html + serveur web + navigateur était l'équation qui apporta la démocratisation des échanges d'informations quelle que soit la nature des machines connectées.
Lorsque Java a commencé à être dans les discussions autour des machines à café, ce qui paraissait à ce moment-là révolutionnaire était WORA : write once, run anywhere. Sun n'apportait pas simplement le binaire universel, mais promettait l'extension qui allait permettre au navigateur d'insuffler de la vie dans les pages statiques, qui se limitait en ce temps à des signaux primitifs au travers des GIFs animés, grâce aux applets.
Ça, c'était pour le marketing, mais les développeurs ne seraient pas lésés au passage : c'était la fin des hiérarchies de classes complexes à maîtriser et le code métier allait enfin être débarrassé des instructions bas niveau liées à l'allocation mémoire. Bref, exit les problèmes d'héritage en diamant grâce à des règles simplifiées, exit les malloc et free avec le garbage collector. Mais ce n'était pas tout : fini les crashs intempestifs dus à du code applicatif effectuant des opérations illicites : la JVM encadre l'exécution et lève des exceptions. Ainsi, une division par zéro ne fait plus planter l'application et une écriture dans une zone mémoire interdite n'entraîne plus de comportement inattendu. Cela présente deux atouts majeurs : il est naturellement plus facile de faire gagner les applications en résilience, et la sécurité est renforcée car un débordement de tableau ne permet plus d'accéder à des adresses interdites.
Java apporte également une API simplifiée pour développer des programmes multi threadés, les coûteux forks devenant inutiles. Au passage, il me semble opportun de rappeler que 1995 était l'année de la commercialisation de Windows95 (oui, j'ai fait un travail d’investigation de dingue) et que la plupart des postes étaient encore exploités avec la version 3.11 (non, on ne va pas citer OS2/warp, ni NT encore confidentiel) qui était tout simplement incapable de faire tourner deux dir c:\ /s parallèlement dans deux fenêtres distinctes ! Bref, en plus d'apporter l'IHM universelle, la plate-forme affiche également une ambition non dissimulée côté serveur.
Voilà, je vous vends un rêve qui date de deux décennies. Mais vous connaissez l'histoire, et vous savez que tout n'a pas été si rose.
Oui, mais Java ça rame...
C'était indéniable. Poser une abstraction tant au niveau OS qu'au niveau matériel, interpréter du bytecode au lieu d'exécuter du code natif, tout ça n'était évidemment pas gratuit. De plus, des composants de la bibliothèque se prémunissaient par défaut des accès concurrents en ayant massivement recours à la synchronisation, évidemment les applications multi-threadées souffraient de contentions importantes.
On ne pourra évidemment pas oublier non plus les piètres performances de Swing et AWT, à tel point qu'un autre toolkit base sur des liaisons avec les librairies natives (SWT) a émergé à l'extérieur de la librairie standard.
Mais la plate-forme a appris et grandi : Hotspot a apporté la compilation Just-In-Time à la JVM, Java Foundation Classes est devenu le JDK, Swing a été refondu en pur Java et surclasse les performances de SWT.
Oui, mais Java c'est moche
L'IHM apparaît clairement comme le pari manqué de la plate-forme. Les applications Java n'ont pas submergé nos ordinateurs, pire, combien de fois la réflexion "oh non, c'est du Java" a été prononcée à la suite du téléchargement d’un programme ? Les IHM natives (sur MacOS comme sur Windows) devenant de plus en plus sexy au fil des versions, les applications Java accuseront de plus en plus le coup. Sun et Oracle tenteront bien de le rattraper avec JavaFX 1 et 2, le premier était peu convaincant alors que le deuxième est crédible, mais le train semble définitivement passé et aucun projet d'envergure ne permet de mettre cette technologie en lumière, même les IDE continuent de reposer sur Swing ou SWT. Du côté des navigateurs, les applets se sont fait voler la vedette par Flash qui proposait des outils de développement destinés autant aux créatifs qu'aux développeurs. Pire, les applets ont drainé un nombre important de failles de sécurité. Une publicité dont la plate-forme se serait bien passée, pour un composant désuet de surcroît.
Ce que je retiens au bout de 20 ans
Le plus facile : le garbage collector, c'est top. L'implantation se choisit en fonction de son profil applicatif : Le GC à sélectionner ne sera pas le même pour un batch ou pour un besoin plus typé transactionnel. Mieux, on peut directement lui fixer un objectif de latence au lieu de se noyer dans la galaxie de paramètres disponibles.
Ensuite, Java est un langage qui vit et évolue depuis 20 ans. Sûrement pas au rythme souhaité, mais il a connu plusieurs révolutions : Java5 avec les annotations et génériques, et Java8 avec les lambdas. Ce n'est évidemment pas fini et on attend de voir comment les value objects vont influencer notre code.
La JVM est plutôt extravertie et n'hésite pas à s'exprimer à son sujet si on le lui demande. Vous pouvez extraire le contenu de sa mémoire, lui demander ce qu'elle est en train de faire, combien de fois le GC a été invoqué, et j'en passe bien entendu (je me suis largement épanché sur le sujet dans cet article). J'adore la métrologie et les statistiques d'exécution, donc je suis fan !
J'ai cité tout à l'heure le JIT, et j'aimerais m'étendre un peu sur le travail effectué par la machine virtuelle pour que nos applications délivrent de meilleures performances. Elle observe leurs comportements afin de prendre des décisions adéquates et manipuler au mieux le code. Elle est capable d'inliner des méthodes, changer l'ordre des instructions, en annuler certaines, mixer du code natif et du bytecode dans les piles d'appels, remplacer un appel virtuel au profit d'un appel direct, etc. Bref, une belle pièce d'ingénierie !
Oui, mais ça fait 20 ans que Java rame...
Alors voilà un dogme qui a la peau dure ! Non, Java ne rame pas. Certes, le démarrage est un peu poussif car le chargement et la vérification des classes, l'initialisation des blocs statiques et le fait que la JVM soit "froide" (et sûrement d'autres étapes qui m'échappent) prennent du temps. D’ailleurs, la modularisation promise par JigSaw devrait apporter des améliorations sur ces points-là.
En revanche, un new en Java est plus rapide qu'un malloc, et dans bien des cas, du bytecode dynamiquement optimisé par Hotspot est plus performant que du code statique natif (au dire d'experts, je n'ai pas vérifié personnellement). D'ailleurs, la communauté ne s'y trompe pas car pas moins de 45 langages s'exécutant sur une JVM ont été répertoriés ! Il y a fort à parier que personne n'envisageait un tel effet de bord en 1995 !
Lorsque j'ai couvert de louanges le GC, je vous ai entendu marmonner que l'on a pas le même vécu à ce sujet. Mais les lenteurs de ramassage ne sont que rarement inhérentes à la technologie, et la plupart du temps des symptômes de problèmes de conception. Et c'est un peu en ce sens que La plate-forme est victime de sa réussite, car les abstractions posées sont tellement pratiques et ancrées que le fonctionnement des couches basses est souvent totalement oublié par les équipes de développement, plaçant le GC au centre des inquiétudes alors que c'est l'application qui est souvent en cause...
Un point particulier m'interpelle aujourd'hui : la killer feature de Java était d'avoir un binaire universel. Mais finalement, si cette propriété n'était plus d'actualité, on ne le sentirait quasiment pas. En effet, en même temps que Java gagnait en popularité, les développements natifs "cross platform" évoluaient de leur côté. Ainsi, vous pouvez compiler le Gimp aussi bien sous Linux que sur Mac à partir des mêmes sources. De plus, nous avons été très sensibilisés ces dernières années pour que les processus de build soient agnostiques vis-à-vis de plate-forme, la plupart des projets se compilant aussi bien sous Windows que sur les UNIX. Donc si on perdait cette compatibilité, la plate-forme serait que peu impactée. Et même pire. Si votre application est très ambitieuse en matière de performance, vous ne pouvez pas rester abstrait par rapport au socle matériel. Pour vous en convaincre, je vous invite à lire la façon dont LMAX Disruptor évite les problèmes de false sharing.
Voilà, si vous ne vous rappeliez pas pourquoi la plate-forme Java est cool, j'espère vous avoir rafraîchi la mémoire !
Au Sujet de l'Auteur
Brice Leporini est un développeur sénior qui totalise plus de quinze ans d’expérience sur différentes technologies dont dix focalisées sur l’écosystème Java et les architectures n-tiers. Freelance depuis huit ans, son activité actuelle oscille entre le coaching technique d’équipes de jeunes geeks, les travaux d’amélioration de performance et les études préalables. Retrouvez-le sur Twitter à @blep.