Même question que ci-dessus : est-ce que tu as des exemples ?
Je vois bien des problèmes de rétrocompatibilité (dans le sens : une vieille classe ne tourne plus sur une JVM récente) avec le passage de Java EE à Jakarta et le retrait de Nashorn.
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. Il y a bien des cas où tu es obligé d'ajouter des dépendances de modules d'API standard pour utiliser de vieilles classes dans un code récent qui utilise les modules, mais pour moi c'est un problème de compatibilité et pas de rétrocompatibilité, dans le sens où la vieille classe elle-même fonctionnera sans modification. Je n'ai pas non plus trouvé d'exemples après une recherche rapide ni n'en ait subi, donc si tu en as je prends.
Enfin et surtout, « sainte » ≠ « absolue » hein. Il y a des ruptures de compatibilité – il suffit d'aller sur les releases notes pour les voir, changez le numéro de version dans l'URL pour voir les autres, à partir de Java 10. Mais ça n'est que des changements dans les outils et options externes. Les rares changements d'API sont soit sur des API internes – je ne vais pas plaindre les gens dont le code a pété parce qu'ils utilisaient sun.misc.BASE64Decoder soit des trucs fondamentalement pétés depuis longtemps, soit des problèmes de sécurité, comme les récentes protections sur la réflexion, qui a bien mis le bazar dans les codes qui fonctionnaient précisément à cause de ce manque de protection, comme au hasard certains mods Minecraft.
Et surtout, je n'ai vu aucun changement d'ABI, ce qui est quand même le sujet d'origine.
Un truc qui me gonfle avec la gestion de la compatibilité de Java, c'est qu'il semble y avoir une horreur à déprécier officiellement des trucs malgré la présence de remplacements depuis des décennies. 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. Que ces antiquités soient conservées pour la compatibilité, OK, mais elles n'ont plus rien à faire dans un code actuel.
C'est peut-être ça qui manque à un langage qui veut garder autant de rétrocompatibilité que possible : un moyen de marquer une sorte de soft deprecated, qui indique que la fonctionnalité va être conservée pour compatibilité mais ne devrait plus être utilisée dans du code moderne – avec un indicateur la nouvelle méthode. Je pense que ça aiderait pas mal à améliorer la qualité de code, en particulier de tous les projets faits dans des usines à code où les développeurs n'en ont pas grand-chose à faire de suivre les nouveautés du langage.
[^] # Re: C'est moi ou c'est idiot ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Google forke C++. Évalué à 4.
Même question que ci-dessus : est-ce que tu as des exemples ?
Je vois bien des problèmes de rétrocompatibilité (dans le sens : une vieille classe ne tourne plus sur une JVM récente) avec le passage de Java EE à Jakarta et le retrait de Nashorn.
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. Il y a bien des cas où tu es obligé d'ajouter des dépendances de modules d'API standard pour utiliser de vieilles classes dans un code récent qui utilise les modules, mais pour moi c'est un problème de compatibilité et pas de rétrocompatibilité, dans le sens où la vieille classe elle-même fonctionnera sans modification. Je n'ai pas non plus trouvé d'exemples après une recherche rapide ni n'en ait subi, donc si tu en as je prends.
Enfin et surtout, « sainte » ≠ « absolue » hein. Il y a des ruptures de compatibilité – il suffit d'aller sur les releases notes pour les voir, changez le numéro de version dans l'URL pour voir les autres, à partir de Java 10. Mais ça n'est que des changements dans les outils et options externes. Les rares changements d'API sont soit sur des API internes – je ne vais pas plaindre les gens dont le code a pété parce qu'ils utilisaient
sun.misc.BASE64Decodersoit des trucs fondamentalement pétés depuis longtemps, soit des problèmes de sécurité, comme les récentes protections sur la réflexion, qui a bien mis le bazar dans les codes qui fonctionnaient précisément à cause de ce manque de protection, comme au hasard certains mods Minecraft.Et surtout, je n'ai vu aucun changement d'ABI, ce qui est quand même le sujet d'origine.
Un truc qui me gonfle avec la gestion de la compatibilité de Java, c'est qu'il semble y avoir une horreur à déprécier officiellement des trucs malgré la présence de remplacements depuis des décennies. Aujourd'hui, mi-2022, tu peux écrire du code complet à base de
Vector,HashMap,Dateet autres objets qui ont des remplacements bien plus pratiques sans que le langage ne te sorte le moindre avertissement. Que ces antiquités soient conservées pour la compatibilité, OK, mais elles n'ont plus rien à faire dans un code actuel.C'est peut-être ça qui manque à un langage qui veut garder autant de rétrocompatibilité que possible : un moyen de marquer une sorte de soft deprecated, qui indique que la fonctionnalité va être conservée pour compatibilité mais ne devrait plus être utilisée dans du code moderne – avec un indicateur la nouvelle méthode. Je pense que ça aiderait pas mal à améliorer la qualité de code, en particulier de tous les projets faits dans des usines à code où les développeurs n'en ont pas grand-chose à faire de suivre les nouveautés du langage.
La connaissance libre : https://zestedesavoir.com