Java n'est pas plus fais pour durer qu'un autre, il est régulièrement incompatible ce qui fais que quand tu reprends un projet tu dois réécrire une partie.
C'est factuellement faux. Au niveau langage la comptabilité source et binaire sur les 15+ dernières années est limite irréprochable. Tu prends un JAR compilé il y a 15 ans en Java 1.3 ou 1.4, il tourne toujours avec un JRE 15. Tu recompiles, il compile et tourne. Et au passage il tourne plus vite grâce aux amélioration du JIT.
Il existe quelque cas marginaux qui posent des problèmes (coucou bridge method, changement de comportement de substring & cie) et quelques rares nettoyages qui ont été fait en Java 9 sur des API peu utilisées, coûteuses à maintenir ou dangereuses. Ce sont de rares exceptions. Ce sont de rares exceptions. Beaucoup d'évolutions niveau JVM ont été coûteuses pour préserver cet attribut.
Si tu as des problèmes, c'est que les libs que tu utilises elles ne sont pas aussi disciplinées et que les nouvelles versions que tu choisies d'utiliser ont cassées la compatibilité source ou binaire. Ou que tu as choisi de changer de libs car tes besoins ont changés. C'est autre chose que la question d'origine car tu peux toujours utiliser les JAR d'avant, ça tournera.
Donc oui maintenir un projet dans le temps demande de l'effort de maintenance. Il est juste grandement facilité par le fait qu'un binaire qui tourne continuera à tourner. Ça permet de ne pas avoir d'écosystème qui éclate à cause de chaîne de dépendance brisé (ie. pas besoin de recompiler la veille lib stable dont tout le monde dépend sans le savoir et qui n'a pas eu de release depuis 8 ans). Ca permet de continuer à faire tourner le binaire d'un projet arrêté il y 6 ans sans avoir à géler le hard & soft d'un serveur etc. D'autres langages n'ont pas cette culture et le coût à terme n'est vraiment pas le même. Dans la vraie vie, c'est plutôt pratique.
[^] # Re: le meilleur langage pour les projets d'entreprise
Posté par ckyl . En réponse au journal Toileharicot 12 est dehors. Évalué à 3.
C'est factuellement faux. Au niveau langage la comptabilité source et binaire sur les 15+ dernières années est limite irréprochable. Tu prends un JAR compilé il y a 15 ans en Java 1.3 ou 1.4, il tourne toujours avec un JRE 15. Tu recompiles, il compile et tourne. Et au passage il tourne plus vite grâce aux amélioration du JIT.
Il existe quelque cas marginaux qui posent des problèmes (coucou bridge method, changement de comportement de substring & cie) et quelques rares nettoyages qui ont été fait en Java 9 sur des API peu utilisées, coûteuses à maintenir ou dangereuses. Ce sont de rares exceptions. Ce sont de rares exceptions. Beaucoup d'évolutions niveau JVM ont été coûteuses pour préserver cet attribut.
Si tu as des problèmes, c'est que les libs que tu utilises elles ne sont pas aussi disciplinées et que les nouvelles versions que tu choisies d'utiliser ont cassées la compatibilité source ou binaire. Ou que tu as choisi de changer de libs car tes besoins ont changés. C'est autre chose que la question d'origine car tu peux toujours utiliser les JAR d'avant, ça tournera.
Donc oui maintenir un projet dans le temps demande de l'effort de maintenance. Il est juste grandement facilité par le fait qu'un binaire qui tourne continuera à tourner. Ça permet de ne pas avoir d'écosystème qui éclate à cause de chaîne de dépendance brisé (ie. pas besoin de recompiler la veille lib stable dont tout le monde dépend sans le savoir et qui n'a pas eu de release depuis 8 ans). Ca permet de continuer à faire tourner le binaire d'un projet arrêté il y 6 ans sans avoir à géler le hard & soft d'un serveur etc. D'autres langages n'ont pas cette culture et le coût à terme n'est vraiment pas le même. Dans la vraie vie, c'est plutôt pratique.