Les anti-modèles de l'API centrale de Java. Qu'est-ce qui ne va pas ?

Question

Bien que le travail des gars de SUN sur l'API de base de Java soit impressionnant, ce sont des humains et ils ne sont pas infaillibles. J'ai lu dans plusieurs livres des critiques sur certaines erreurs énormes qui (à mon avis) sont toujours là pour la rétrocompatibilité et le code hérité. Ma question est la suivante : quelles sont celles que vous connaissez ?

À titre d'exemple :

• Observable est une classe. Devrait être une interface afin de permettre l'héritage.
• Cloneable : Ce ne devrait pas être une interface de marqueur. (Devrait avoir le clone() au lieu d'être dans Object classe).

Answer 1

Voici une petite liste que j'ai établie Échec de la convention Java

L'un de mes préférés est le nom plutôt long de la classe com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

Un non-haiku que j'ai écrit en son honneur ;)

Internal frame
internal frame,
title pane
internal frame.

title pane
maximize button,
window not focused state

Answer 2

• Properties s'étend à Hashtable. Aargh.
• Tous les objets sont disponibles pour le verrouillage au lieu d'objets de verrouillage spécifiques(.NET a le même problème)
• Chaque objet a une égalité/un code de hachage - encore une fois .NET a le même problème, mais au moins ils ont IEqualityComparer<T> ainsi que IComparer<T> . C'est ainsi que toutes les cartes, etc. devraient être établies, car les concepts d'égalité sont multiples selon les circonstances.
• L'API date/heure (nouvelle version dans Java 7, j'espère)
• Le modèle asynchrone de NIO est plus difficile à appréhender que le modèle asynchrone de .NET.
• Il n'existe pas d'interface universelle d'élimination - en partie à cause des exceptions vérifiées - ce qui rend un équivalent de l'instruction "using" plus difficile à gérer (l'instruction déclaration d'essai avec les ressources en Java 7 est l'équivalent de using et en général)
• Mauvaise prise en charge de l'encodage de texte (utilisation trop fréquente des noms en tant que chaînes de caractères)
• Pas de type d'octet non signé

Answer 3

 Boolean.getBoolean("true");
 Integer.getInteger("2");

.....

Answer 4

Stack hérite de Vector plutôt que de simplement en conserver un, ce qui donne aux piles des méthodes vectorielles et permet aux clients de briser trivialement l'abstraction. Un exemple classique de héritage utilisé lorsque composition aurait dû être.

Answer 5

java.awt.BorderLayout utilise NORTH , SOUTH , EAST , WEST au lieu de TOP , BOTTOM , LEFT , RIGHT . J'aime aussi la façon dont ils doivent clarifier les choses dans les commentaires pour ces contants :

/**
 * The north layout constraint (top of container).
 */
public static final String NORTH  = "North";