I'm not 100% clear on this (I'm sure someone else on our team could answer this better). That said, a couple thoughts:
- I don't think we claim anywhere that this is (guaranteed to be) thread-safe. Non-thread-safe collections such as
HashMultiset
extendAbstractMultiset
. That said,ConcurrentHashMultiset
also extendsAbstractMultiset
and uses its implementation ofelementSet()
, so presumably it must in fact be possible for it to be thread-safe. - I believe the thread safety of this method is dependent on the implementation of
createElementSet()
. From what I can tell, if theSet
created bycreateElementSet()
is immutable (in that the fields that are assigned when it is constructed arefinal
), it should be thread-safe. This appears to be true in the case ofConcurrentHashMultiset
at least.
Edit: I asked Jeremy Manson about this, and he said: "Your take on it seems fine to me. It isn't thread safe. If the object being constructed has all of the final fields in the right places, you should be fine, but I wouldn't rely on that by accident (note that many implementations are effectively immutable instead genuinely immutable)."
Note: For thread-safe collections like ConcurrentHashMultiset
which use this pattern, objects created are intentionally and genuinely immutable (though if AbstractSet
were to change, that could change, as Chris noted in the comments).