Quand tu maintiens une compat sur 15+ ans sur un langage et une API aussi vaste il y a toujours quelques ratés (qui sont relou on est d'accord). Mais Sun s'en sort plutôt bien à ce jeux.
Pour le point précis dont tu parles c'est toujours un problème pour les mainteneurs. Le code existant autorisait des conditions plus souples que ce que disait la spécification. C'est à dire que du code pourri était accepté. Du coup c'est le bordel quand tu veux mettre à jour:
- Tu te dis que l'ancien comportement doit être gravé dans la pierre même si la spec dit que le code n'aurait jamais du marcher. C'est le mieux pour la compat mais au bout de 10 ans tu peux plus rien faire bouger (note que la spec n'a pas changé)
- Tu te dis que la spec est bonne et reste intacte. Tant pis pour les mauvais utilisateurs ils fixeront leur code.
- Tu te dis les deux et tu permets aux mauvais utilisateurs d'avoir une solution temporaire au cas où (solution retenue)
- Tu introduis une nouvelle API. Il faudra migrer le code de toutes les applis pour tirer parti des optimisations et l'ancienne API doublon restera ad vitam eternam.
Faire le choix entre ces solutions n'est pas évident et celle retenu n'est pas stupide. C'est exactement comme un compilo C qui était plus souple que la norme et un jour devient plus strict. Tu gardes la spec, la nouvelle implémentation a un bon comportement et tu permets aux mauvais élèves de continuer à compiler pendant quelques temps.
Ca n’empêche pas qu'il y a quelques vrais problèmes ;)
[^] # Re: Les vrais ajouts
Posté par ckyl . En réponse au journal Java 7 est dispo !. Évalué à 8.
Quand tu maintiens une compat sur 15+ ans sur un langage et une API aussi vaste il y a toujours quelques ratés (qui sont relou on est d'accord). Mais Sun s'en sort plutôt bien à ce jeux.
Pour le point précis dont tu parles c'est toujours un problème pour les mainteneurs. Le code existant autorisait des conditions plus souples que ce que disait la spécification. C'est à dire que du code pourri était accepté. Du coup c'est le bordel quand tu veux mettre à jour:
- Tu te dis que l'ancien comportement doit être gravé dans la pierre même si la spec dit que le code n'aurait jamais du marcher. C'est le mieux pour la compat mais au bout de 10 ans tu peux plus rien faire bouger (note que la spec n'a pas changé)
- Tu te dis que la spec est bonne et reste intacte. Tant pis pour les mauvais utilisateurs ils fixeront leur code.
- Tu te dis les deux et tu permets aux mauvais utilisateurs d'avoir une solution temporaire au cas où (solution retenue)
- Tu introduis une nouvelle API. Il faudra migrer le code de toutes les applis pour tirer parti des optimisations et l'ancienne API doublon restera ad vitam eternam.
Faire le choix entre ces solutions n'est pas évident et celle retenu n'est pas stupide. C'est exactement comme un compilo C qui était plus souple que la norme et un jour devient plus strict. Tu gardes la spec, la nouvelle implémentation a un bon comportement et tu permets aux mauvais élèves de continuer à compiler pendant quelques temps.
Ca n’empêche pas qu'il y a quelques vrais problèmes ;)