Java : dépassé ou pertinent en 2024 ?
- 25 juin 2024
- Envoyé par : LeanaE
- Catégories: Général, Technologie
Obsolète ! Inefficace ! Interface utilisateur d’un autre âge ! C’est par ces plaintes récurrentes que l’idée d’une refonte applicative a germé dans l’entreprise.
La technologie évolue à une vitesse vertigineuse, comme Java depuis 30 ans ! Les entreprises doivent se réinventer et se moderniser pour rester compétitives.
Aujourd’hui, je vous emmène dans les coulisses d’un projet ambitieux : la refonte totale d’un outil de gestion. Après des années de discussions, la direction a enfin donné son feu vert pour une modernisation tant attendue. Les débats sont animés dans une équipe projet où chaque voix compte et où l’innovation est au centre des préoccupations.
Après une rapide introduction de la refonte, la question de la pile technique se pose.
Déborah, la cheffe de projet prend la parole.
- Pour ce projet, l’orientation stratégique est de s’orienter vers des langages intégrant une gestion sécurisée de la mémoire et ne dépendant pas d’un éditeur en particulier. Le C++ et le C# sont donc écartés. Que pensez-vous de Java ?
Raphaël, le nouveau développeur, lance une question pleine de malice :
- Java ? C’est encore utilisé en 2024 ? Il n’évolue plus trop non ?
Jean-Michel, passionné de Java, réagit :
- Mais non, on utilise déjà Java sur d’autres applicatifs et tout se passe bien !
Déborah recadre la discussion :
- Et si vous nous expliquiez chacun ce que vous proposez qu’on puisse en parler tous ensemble ?
Jean-Michel, réfléchis et répond calmement :
- Tu as raison, ces langages sont plus modernes, mais en entreprise les critères importants sont la maturité, la fiabilité, les performances, la maintenabilité, la productivité et les compétences de nos équipes ou de nos prestataires.
Raphaël rétorque :
- Si je t’écoutais, on serait toujours en Cobol sur les nouveaux projets !
Jean-Michel rigole :
- Je te comprends, mais, dans notre contexte, Rust ne sera pas aussi productif. Nous n’avons personne qui connaît Go et Node.js n’a pas un écosystème aussi mature et robuste que Java par exemple, sur la sécurité avec Spring Security.
Il prend une pose et ajoute :
- Nous ne sommes pas une startup et notre outil doit encore fonctionner dans 10 ans. Et puis, la maturité de Java a pu être éprouvée depuis 30 ans.
Raphaël répond, sarcastique :
- Ah, oui, tu as raison comme avec Java 9 qui a tout cassé ? Résultat, les entreprises sont restées en Java 8.
Jean-Michel soupire :
- Tu marques un point, mais à l’époque, il fallait sécuriser et alléger Java. Tu ne peux pas dire que Java n’évolue pas et te plaindre quand il le fait ! Et puis, il existe des solutions pour cette transition. Maintenant, les mises à jour sont plus régulières et prévisibles.
Avec un sourire en direction de Fabien, il ajoute :
- Tu sais, pour les migrations, c’est plutôt l’exploitation qu’il faut convaincre. Ils sont … conservateurs.
Fabien, le responsable exploitation et infrastructure répond taquin :
- Nous sommes conservateurs pour une bonne raison ! Ça évite que nos charmants développeurs ne cassent tout avec leurs nouveaux jouets sur lesquels on n’a pas assez de recul.
Déborah sort un bloc note et reprend :
- Vous avez tous soulevé des points intéressants ! Je vous propose de les synthétiser. Si on n’est pas d’accord, on pourra toujours demander à Nat System, ils ont toujours été de bons conseils. Est-ce que vous avez d’autres éléments à évoquer ?
Performances
Raphaël soulève un nouveau point :
- Rust nous permettrait d’être plus performant, d’avoir des plus petits serveurs qui consomment moins de mémoire et d’avoir des applications qui démarrent très rapidement !
Fabien renchérit :
- C’est ça qu’il nous faut, pour éviter de racheter des serveurs !
Jean-Michel, demande alors :
- Fabien, est-ce que nos serveurs redémarrent souvent ?
- Non, c’est assez rare.
- Aurons-nous réellement besoin de nombreux serveurs pour cet outil ?
- Non, tu as raison, on n’est pas Google, on ne devrait pas dépasser le millier d’utilisateurs.
Jean-Michel se tourne vers Arthur, le DSI :
- Arthur, qu’est ce qui coûte le plus cher actuellement, les serveurs, ou les salaires ?
- Les salaires, évidemment !
- Alors, un langage de haut niveau nous permettra d’ajouter des fonctionnalités rapidement. On pourra créer un micro service en Rust ou utiliser la compilation native pour des besoins spécifiques, mais c’est rare en informatique de gestion.
Arthur s’interroge :
- Les outils, l’écosystème et les environnements sont aussi importants. Que proposez-vous à ce sujet ? Devons-nous utiliser des langages différents pour la back et le front ?
Ecosystème et environnement
Raphaël s’exprime le premier :
- Tous les grands noms de la tech font du web et du javascript depuis des années, on pourrait utiliser un framework javascript et profiter de tous les outils et les optimisations mises en place par les géants du web.
Jean-Michel répond :
- Ta remarque est pertinente Raphaël ! Pour la couche de présentation, on utilisait des JSP mais React et Angular offrent une meilleure expérience utilisateur. Pour le back-end cependant, je pense que Node.Js n’a pas encore la maturité de Java.
Arthur insiste,
- Est-ce que les écosystèmes Java sont encore bien vivants ?
Jean-Michel affirme :
- Oh oui ! Tu sais Arthur, Java est utilisé par Oracle, Red Hat, IBM, Amazon, Google, Microsoft et bien d’autres. Leurs services de cloud en dépendent, ils ont donc tout intérêt à contribuer participer à son développement. Il y aussi des fondations comme Eclipse et Apache.
Son écosystème est très riche quel que soit l’outil recherché :
- IDE : IntelliJ, Eclipse, Netbeans
- Build : Maven, Gradle
- Serveurs applicatifs : Tomcat, Wildfly, Jetty
- Framework : Spring, Hibernate, Quarkus, Spring boot, Quartz
- Tests : Junit, Mockito
- Et bien d’autres : SonarQube, Nexus, Artifactory,…
Arthur le coupe avec le sourire :
- Merci Jean-Michel, on a compris, tu sembles bien renseigné ! Et concernant le matériel et les systèmes d’exploitation pris en charge ?
Jean-Michel triomphe :
- Java est multiplateforme et fonctionne sans recompilation grâce la JVM et …
Raphaël éclate de rire :
- Et dans notre contexte, ça ne sert pas à grand-chose puisqu’on exécute tout sur docker ! Tu te souviens, on fait de l’informatique de gestion pour un nombre limité d’utilisateurs !
Tout le monde éclate de rire. Déborah recentre le débat :
- Tu as parlé tout à l’heure de la maturité, tu peux nous parler des évolutions ? La direction a été très claire, ils ne souhaitent pas recommencer dans 5 ans !
Java et l’innovation
Fabien prend la parole :
- J’insiste, notre besoin est d’assurer la stabilité et une maintenance simple ! Pas besoin d’utiliser les dernières nouveautés non ? Qu’est-ce que ça nous apporte ?
Jean-Michel acquiesce avec le sourire :
- Il faut trouver un compromis entre le bonheur des devs et de l’exploitation. On a déjà du mal à recruter, ça serait encore pire avec des vieilles versions. Java 22 est disponible tu sais ? Rassure-toi, ces évolutions sont bénéfiques à tout le monde.
Elles visent à :
– Simplifier, raccourcir le code et augmenter la productivité
– Améliorer les performances et la sécurité
– Supprimer les fonctionnalités inutiles
Ces améliorations sont groupées en projets comme :
– Amber : amélioration de productivité en faisant évoluer la syntaxe
– Panama : améliorer l’interopérabilité Java/natif
– Leyden : compilation à l’avance pour optimiser les performances
– Valhalla : value types pour améliorer les performances
– Loom : threads légers et d’autres
Déborah se tourne vers Arthur :
- Je pense que nous en resterons là pour cette réunion, je récapitule
Pour résumer
Contexte
L’entreprise a décidé de moderniser un outil de gestion vieillissant et a donné son feu vert à une refonte totale.
Critères de choix
- Productivité
- Maturité
- Maintenabilité
- Écosystème et outils
- Performance
- Coûts
Conclusion
Le coût des salaires est supérieur au coût des serveurs dans notre contexte ce qui oriente le choix vers un langage de haut niveau.
Java est privilégié pour sa maturité, sa productivité, son écosystème complet et l’expérience des équipes.
Rust et Go offrent des performances supérieures qui peuvent être adaptés dans certains modules.
Rédacteur :
