Quelle est la méthode la plus trompeuse dans l'API Java Base?

Question

J'ai récemment essayer de convertir une chaîne de caractères littérale en boolean, lorsque la méthode boolean Boolean.getBoolean(String name) sauté hors de la fonction de fenêtre. Il y avait aussi une autre méthode (boolean Boolean.parseBoolean(String s)) apparaissant juste après, ce qui m'a conduit à chercher à savoir quelles étaient les différences entre ces deux-là, comme ils semblaient à faire de même.

Il s'avère que ce Boolean.getBoolean(String name) vraiment fait, c'est de vérifier s'il existe un System de la propriété (!) le nom donné et si sa valeur est true. Je pense que c'est très trompeur, car je ne suis certainement pas attendre qu'une méthode de Boolean est en fait de faire un appel à l' System.getProperty, et juste en regardant la signature de la méthode, il semble (au moins pour moi) comme il devrait être utilisée pour analyser un String comme boolean. Bien sûr, la javadoc etats clairement, mais je pense toujours que la méthode a un nom trompeur et il n'est pas à la bonne place. Autre type primitif wrappers, comme Integer ont également une méthode similaire.

Aussi, il ne semble pas être une méthode très utile pour appartenir à l'API de base, je pense que ce n'est pas très commun d'avoir quelque chose qui ressemble -Darg=true. Peut-être que c'est une bonne question pour un Java position interview: "qu'est-Ce que la sortie de l' Boolean.getBoolean("true")?". Je crois qu'un endroit plus approprié pour ces méthodes serait dans l' System classe, par exemple, getPropertyAsBoolean; mais encore une fois, je pense toujours que c'est inutile d'avoir ces méthodes de l'API de base. Il ferait de sens dans quelque chose comme l' Properties classe, où il est très courant de voir ce type de conversions.

Que pensez-vous de tout cela? Aussi, si il y a un autre "maladroite" de la méthode que vous êtes au courant, s'il vous plaît poster.

N. B. je sais que je peux utiliser Boolean.valueOf ou Boolean.parseBoolean pour convertir une chaîne de caractères littérale en boolean, mais je suis juste à la recherche pour discuter de la conception d'API.

Answer 1

L'URL de la méthode equals() compare les adresses IP, utilise une connexion réseau et une opération de blocage!

À partir de la documentation javadoc:

Deux hôtes sont considérés comme équivalents si les deux noms d'hôte peut être résolu dans les mêmes adresses IP; d'autre si le nom d'hôte ne peut pas être résolu, le nom d'hôte doit être égal, sans égard à l'arrêt, ou les deux des noms d'hôte égale à null.

Comme les hôtes de comparaison nécessite la résolution de nom, cette opération est un opération de blocage.

Remarque: Le comportement défini égaux est connu pour d'être incompatible avec l'hébergement virtuel HTTP.

Utiliser l'URI à la place.

Answer 2

Un problème bien connu avec la classe Calendar est que les mois sont numérotés de 0 à 11 au lieu de 1 à 12. Il est très facile de faire une erreur comme celle-ci:

 Calendar cal = Calendar.getInstance();

// Set date to August 18, 2009? WRONG! Sets the date to September 18, 2009!
cal.set(2009, 8, 18);
 

La bonne façon de le faire est d'utiliser des constantes pour les mois:

 cal.set(2009, Calendar.AUGUST, 18);
 

Mais cette méthode rend l'erreur beaucoup trop facile d'utiliser les nombres de mois normaux de 1 à 12.

Je considère cela comme une erreur dans la conception de la classe Calendar.

Answer 3

Je viens d’en avoir un d’ ici , en ce qui concerne les méthodes add et remove de List (lorsque paramétré avec Integer ). Par exemple:

 List<Integer> l = new ArrayList<Integer>();
l.add(20);
l.remove(20); // throws ArrayIndexOutOfBoundsException, because it will try to access index 20
l.remove(new Integer(20)); // this works
 

Answer 4

 String.getBytes()
 

souvent la cause de nombreux problèmes de codage de caractères stupides dans les applications car il utilise le codage de caractères de la plate-forme sous-jacente.

Answer 5

Viens de découvrir sur les méthodes d' isInterrupted et interrupted de la classe Thread. D' javadoc:

static boolean interrupted()
// Tests whether the current thread has been interrupted.
boolean isInterrupted()
// Tests whether this thread has been interrupted.

Le problème est qu' interrupted réellement efface l'état d'interruption en plus de faire le test, en isInterrupted seulement des tests de l'état.