Écrire une fois courir partout - Mais combien de temps?

Question

Java est venu avec "écrire une fois courir partout".

Comment faire le tour avec tous les cadres à long terme?

J'ai écrit une application avec JSF et richfaces il y a quelques années. Les navigateurs ont évolué et introduit de nouvelles fonctionnalités et bien sûr de nouveaux bugs. Maintenant l'application fonctionne toujours, et parfois il montre des erreurs de javascript des bibliothèques sous-jacentes.

Faut-il vraiment réimplémenter une application complète (pas de cas d'utilisation à ajouter) en raison d'améliorations techniques?

EDIT: L'application que j'ai mentionnée n'était qu'un exemple. Les mêmes choses se produisent facilement si les fournisseurs changent de licence. (Oracle pourrait facturer un vm et open vm n'est pas compatible avec votre pile d'application, etc.)

Answer 1

Même si nous croyons «écrire une fois, courir n'importe où», ce n'est pas tout à fait la même chose qu'une éternelle compatibilité descendante. Pragmatiquement, vous devez vous attendre à ce que les futures versions des frameworks changent certaines choses. Parfois ce sera la suppression de ce qui était un comportement garanti (le pire type de changement), d'autres fois des bogues dans votre code passeront inaperçus jusqu'à ce qu'une future version de la bibliothèque révèle que vous utilisiez un détail d'implémentation qui n'était pas garanti. Plus rarement, votre ancien code révélera un nouveau bug dans la dernière version. Dans un monde idéal, nous écririons du code qui repose uniquement sur un comportement garanti, et les garanties ne seraient jamais supprimées, et par conséquent le code valide continuerait à fonctionner pour toujours. Par contre, il est difficile de prouver que votre programme est totalement correct, et les développeurs de langage/framework/bibliothèque décident s'ils peuvent ajouter les améliorations qu'ils souhaitent, tout en conservant une parfaite compatibilité.

Pour la compatibilité, l'API d'origine doit être suffisamment puissante et stable pour survivre sans modifications perturbatrices. Si ce n'est pas le cas, des modifications non compatibles seront effectuées, sinon l'API sera complètement abandonnée. De toute façon, votre programme ne fonctionnera plus à moins que vous ayez une ancienne version cachée quelque part pour l'exécuter. Vous demandez comment faire l'affaire - il faut d'abord une conception d'interface vraiment bonne et quelque peu chanceuse pour permettre toutes les extensions que vous arrivez plus tard, ou bien un engagement ferme et une «analyse de rentabilisation» (ou motif non-commercial) pour soutenir l'ancienne version indéfiniment. Par exemple, Python 3 n'est pas compatible avec Python 2, mais Python 2 est toujours activement supporté par les mises à jour, donc le vieux code Python s'exécute toujours. C99 supprime seulement quelques fonctionnalités de C89, et si tout le reste échoue, les compilateurs C89 sont toujours maintenus activement. Les navigateurs prennent en charge mille et une versions anciennes et les bizarreries non standard du HTML. Je ne sais pas comment JSF et richfaces se comparent à ceux-ci, ou combien ils sortent des pages qui s'appuient sur le support du comportement "ancien" (ou original) HTML/CSS/Javascript du client.

Cela peut donc arriver, au moins pour un moment. Mais il existe des fonctionnalités IE6 qui ne sont plus disponibles dans les navigateurs sécurisés sur le Web (je suppose que vous pouvez utiliser IE6 dans une machine virtuelle en sandbox ou sur une machine qui ne vous intéresse pas), c'est donc une question de de quoi tu dépendais en premier lieu.Aurait-il pu être prédit que les extensions de navigateur propriétaires seraient abandonnées comme une pierre dans les futures versions? Probablement, mais ces auteurs d'IE6 ont-ils atteint ce qu'ils voulaient en utilisant les normes appropriées disponibles à l'époque? Pas toujours. Même pour ceux qui ne se sont pas impliqués avec IE6, si votre application tombe dans un piège similaire, vous n'avez pas de chance.

Answer 2

Il semble que vous ne parliez pas d'application mais d'applet (parce que vous avez mentionné le script java). De plus, il s'agit d'une applet qui appelle javascript depuis la page où elle est déployée. Dans ce cas, ce n'est pas exactement Java pur. Cela ressemble à appeler la ligne de commande dépendant de la plate-forme en utilisant Runtime.exec(), puis modifier le système d'exploitation et se plaindre que l'application ne fonctionne pas. Ou probablement que je n'ai pas bien compris votre cas d'utilisation?

Answer 3

Les langages de programmation et les technologies évoluent. De manière générale, si une application Web est assez basique, elle peut être capable de prendre des mises à jour sans nécessiter de nombreux changements.

Les langages Java semblent se mettre à jour moins fréquemment que les langages de la pile Microsoft. Cependant, JSF 2 comporte de gros changements par rapport aux versions précédentes, et les applications Richfaces 3.x nécessiteront une migration si vous souhaitez utiliser Richfaces 4.x.

Pour contourner le problème, vous ne devez pas toujours mettre à niveau; il y a beaucoup de sites écrits dans des langues plus anciennes (ASP classique pour un), déployés et fonctionnant encore avec bonheur.

Answer 4

Je ne pense pas que quiconque puisse sérieusement promettre "courir n'importe où, pour toujours". Tôt ou tard, Linux et Windows et MacOS seront tous obsolètes, de nouveaux systèmes d'exploitation sortiront, et personne ne prendra la peine d'écrire des JVM pour eux, donc aucune de vos applications Java ne fonctionnera plus. (J'ai un vieux jeu MS DOS que je trouvais cool mais qui ne fonctionne pas sous Windows DOS.) La compagnie a sorti une version Windows mais ils ont sérieusement redessiné le jeu et, à mon humble avis, détruit tout ce qui En même temps, la compatibilité ascendante des nouvelles versions est une bonne chose, mais de temps en temps, les fournisseurs décident que c'est trop de problèmes.