• [^] # Re: C'est moi ou c'est idiot ?

    Posté par . En réponse au journal Google forke C++. Évalué à 3.

    Dans ce cas pour moi on ne parle pas de la même chose. Je parle de la rétrocompatibilité des ABI et API uniquement, pas de la plateforme en entier.

    C'est un déplacement du problème pas une correction.

    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.

    On a jamais pu étendre un enum. Si un outil de test se servait d'une bidouille pour forcer quelque chose de normalement impossible (ici : créer une classe de mock qui étends l'enum) et que ça finit par péter, c'est pas de chance, mais pour moi c'est pas un problème de rétrocompatibilité : le comportement n'avait jamais été prévu ni officialisé.

    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).

    Pour moi déprécier sun.** n'est pas « casser la rétrocompatibilité », puisque Sun puis Oracle ont toujours dit que ces packages étaient à usage interne, ne faisaient pas partie de l'API et ne devaient pas être utilisés. D'ailleurs des programmes qui utilisaient ces classes ne fonctionnaient pas sur des JVM non-Sun/Oracle, à commencer par la JVM d'IBM.

    Sun comme Oracle ont très largement profité du fait que les gens avaient ces possibilités. Le succès de la plateforme n'aurait pas du tout était la même sans ça. Je trouve que prendre tous ces gens qui ont largement contribué à la plateforme de haut en leur disant que leurs usages "bof OSEF lol" est un manque de respect total.

    Oui la plateforme a besoin pour évoluer de trancher certains usages, mais ça n'empêche pas de prendre en compte l'état réel de la plateforme et pas ce que ce serait dans un état imaginaire qui ne prendrait en compte que ce qui est spécifié/contractualisé.

    Très basiquement retire toutes les bases de données de java (cassandra, elasticsearch, neo4j,...) ça va nettement impacter la plateforme. Même les membres d'OpenJDK l'ont entendu.

    Le fait que Java n'hésite pas à faire des doublons d'API, mais surtout des montages compliqués, des tonnes de sucre syntaxique qui masquent des pièges et finissent par aboutir à des demi-solutions bancales et peu pratiques.

    swing/awt était une fierté fut un temps (pas si lointain).

    Par exemple et sans réfléchir : tout le système de boxing/unboxing, le type erasure dans les generics, la (non) gestion des checked exceptions dans les lambda – qui en plus n'a pas de solution élégante dans l'API standard.

    Les exceptions checkeds sont gérées d'une manière cohérente dans les lambdas et heureusement. Il y a déjà largement suffisamment de cas particulier lié aux lambdas pour ne pas ajouter ça. Une partie du reste est entrain d'être traités par différents sous projets d'OpenJDK.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll