Même question que ci-dessus : est-ce que tu as des exemples ?
Pour les modules et les sealed, je vois bien les problèmes de compatibilité mais je n'ai pas entendu parler de problèmes de _rétro_compatiblité au sens ci-dessus.
Ah non je n'ai pas dis que c'était en particulier des problèmes d'ABI.
Pour les modules, à partir de java11, tu dois déclarer tes modules à ouvrir à ouvrir tout puis à partir de java17 tu ne peux plus tout ouvrir il faut lister tous les modules au quel tu souhaite accéder. Pour moi si tu faisais :
java -jar appli.jar
avec java8 et qu'en mettant à jour java la commande tel quelle ne fonctionne plus c'est un problème de rétrocompatibilité. Que tu ajoute cette liste de modules dans le module info dans le jar ou via la ligne de commande ne change rien.
Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17. Moi j'en ai aucun usage, mais je serais pas vraiment surpris qu'un outil s'en serve pour une raison ou une autre (même un spoke par exemple).
Je retrouve plus la référence mais en ajoutant une méthode sur une interface des collections ils ont cassé la compatibilité d'eclipse-collections. Je présume que ça n'est pas le seul cas où c'est arrivé (pour eclipse ou autre).
Enfin et surtout, « sainte » ≠ « absolue » hein.
Mais du coup tu entends quoi par « sainte » ? Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier sun.misc.Unsafe). Probablement pas autant que tu le souhaiterais, mais du coup je ne vois pas ce que tu entends par « sainte compatibilité ».
Aujourd'hui, mi-2022, tu peux écrire du code complet à base de Vector, HashMap, Date et autres objets qui ont des remplacements bien plus pratiques sans que le langage ne te sorte le moindre avertissement.
Quel est le remplacement de HashMap ? Je viens de vérifier je ne vois pas dans le standard ce qui ces dernières versions auraient donné de quoi le déprécier.
[^] # Re: C'est moi ou c'est idiot ?
Posté par barmic 🦦 . En réponse au journal Google forke C++. Évalué à 3.
Ah non je n'ai pas dis que c'était en particulier des problèmes d'ABI.
Pour les modules, à partir de java11, tu dois déclarer tes modules à ouvrir à ouvrir tout puis à partir de java17 tu ne peux plus tout ouvrir il faut lister tous les modules au quel tu souhaite accéder. Pour moi si tu faisais :
avec java8 et qu'en mettant à jour java la commande tel quelle ne fonctionne plus c'est un problème de rétrocompatibilité. Que tu ajoute cette liste de modules dans le module info dans le jar ou via la ligne de commande ne change rien.
Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17. Moi j'en ai aucun usage, mais je serais pas vraiment surpris qu'un outil s'en serve pour une raison ou une autre (même un spoke par exemple).
Je retrouve plus la référence mais en ajoutant une méthode sur une interface des collections ils ont cassé la compatibilité d'eclipse-collections. Je présume que ça n'est pas le seul cas où c'est arrivé (pour eclipse ou autre).
Mais du coup tu entends quoi par « sainte » ? Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier
sun.misc.Unsafe). Probablement pas autant que tu le souhaiterais, mais du coup je ne vois pas ce que tu entends par « sainte compatibilité ».Quel est le remplacement de HashMap ? Je viens de vérifier je ne vois pas dans le standard ce qui ces dernières versions auraient donné de quoi le déprécier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll