Java 17 est arrivé, mais les banques préfèrent d’autres langages de programmation
C’est fait, Java 17 est sorti. Lancé le mois dernier, il compte de nombreuses évolutions et est décrit comme « l’aboutissement de nombreuses améliorations du langage et de la plateforme, introduites au fil du temps avec chaque nouvelle version depuis Java 11. »
De là à croire que les banques vont commencer à l’utiliser, il y a une marge, et elle est de taille.
Comme en témoigne leur lenteur à adopter Python 3, la plupart des banques ne font pas vraiment partie des précurseurs pour la mise en œuvre de nouvelles versions des langages de programmation les plus utilisés. Java 17 n’est peut-être pas l’itération la plus à jour de Java, mais les banques en sont encore, pour la majorité, à la version lancée en 2014. « La grande majorité des équipes en banque sont toujours sur Java 8 ou Java 11, » indique un codeur senior chez JPMorgan. Et elles sont loin d’être les seules : une récente étude sur l’écosystème Java a démontré que la plupart des utilisateurs restaient fidèles à Java dans ses versions 8 et 11, et que le taux d’adoption des versions plus récentes est resté très faible.
Pourtant, Java 17 est censé être différent. Après la multiplication des nouvelles versions au cours des cinq dernières années, elle est destinée à aider Java à refaire son retard sur ses concurrents tels que Kotlin et Scala, et à améliorer le pattern matching, pour naviguer entre les expressions et la création de classes de données immuables. Plus important encore, Java 17 porte la promesse d’un support durable. « Les équipes utilisant Java 11 [la première version suivie à long terme] sont maintenant susceptibles de passer en Java 17, » commente un développeur senior.
A court terme pourtant, la migration sera difficile. Avec des plateformes sous Java 8, les banques se sont tournées vers Kotlin et Scala partout où c’était possible, et c’est ce qui rend une adoption à grande échelle de Java 17 inutile et peu envisageable. « Nous sommes en Java 8 et nous n’avons pas vraiment de raisons de passer sur la mise à jour puisque nous utilisons essentiellement Scala et Kotlin, » précise le codeur de JPMorgan. « Java 17 propose bien quelques fonctionnalités de langage intéressantes, mais Kotlin est toujours considéré par beaucoup de gens comme un meilleur langage que Java. »
« Java n’est plus utilisé par les banques pour ce qui touche à la pointe de la technologie, » ajoute un autre développeur senior. « Tout se passe en Python, Scala et Kotlin, sans compter que C++ opère un retour en force. »
Java est devenu le langage des applications simples, héritées, et de back office, précise-t-il. Et il est peu probable que le lancement de Java 17 y change grand-chose.
Sans compter que les développeurs migrant vers Java 17 vont devoir se familiariser avec tous les changements intervenus depuis Java 8, et que certains de ces changements pourraient générer des problèmes avec les systèmes existants. « Il y a quelques évolutions de taille dans Java 17, » souligne un autre développeur senior. « La mise à jour des applications existantes peut avoir des effets non négligeables. »
C’est pourquoi Java 17 ne sera sans doute pas la version qui réhabilitera Java dans les écosystèmes de codage des banques, même si elle améliore considérablement les fonctionnalités. Elle finira peut-être par être adoptée, mais pas tout de suite. « Je suppose que la plupart des équipes adopteront la mise à jour lorsque Java 8 arrivera en fin de vie et ne proposera plus de mises à jour de sécurité, à savoir en 2025, » conclut le développeur de JPMorgan.
Crédit photo : Louis Tsai sur Unsplash
Contact: sbutcher@efinancialcareers.com in the first instance. Whatsapp/Signal/Telegram also available (Telegram: @SarahButcher)
Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)
