2010-03-03 2 views

Répondre

16

Son seul Etat est un

private final String separator; 

Alors oui il est threadsafe.

+2

@Pangea - Il est maintenant threadsafe. Si ce n'est pas documenté en tant que threadsafe, cela peut changer dans le futur. – Robin

+1

En outre, puisque c'est un objet si peu cher à créer, pourquoi ne pas le créer localement en cas de besoin? Évitez de le partager entre les threads pour commencer. – daveb

+7

@Robin, c'est un conseil prudent. Bien que documenté ou pas, il serait terriblement sociopathique de n'importe quel mainteneur de bibliothèque de changer une classe de threadsafe pour pas threadsafe après qu'il ait été libéré! Nous ne ferons pas cela pour vous. –

28

Oui! Nous ne sommes pas sur le point de répéter les erreurs de SimpleDateFormat. :-)

Joiner a besoin de recevoir une mise à jour de la documentation similaire à ce que sa classe soeur Splitter a, qui dit:

* <p><b>Warning: splitter instances are always immutable</b>; a configuration 
* method such as {@code omitEmptyStrings} has no effect on the instance it 
* is invoked on! You must store and use the new splitter instance returned by 
* the method. This makes splitters thread-safe, and safe to store as {@code 
* static final} constants . . . 
+8

Le document Joiner a été corrigé maintenant. http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Joiner.html –