This issue about what immutable means wrt "final" on the class has bounced around a few threads.
In my view, immutable has a specific meaning, whereby the object is unequivically safe to use and share between threads. To do so, there are certain rules. One that is disputed is whether the class must be final. eg. http://www.javapractices.com/topic/TopicAction.do?Id=29 Josh Bloch in Effective Java recommends using final on the class where possible, but offers the alternative of a private or package scoped constructor with a public static factory. He does not recommend a public constructor (even when accompanied by defining all the methods as final). The issue arises with a method that takes an ImmutableFoo as an argument where ImmutableFoo is supposed to be "immutable". public void doStuff(ImmutableFoo foo) {...} This author of this method might pass the object to another thread for processing following the expectation that the class is immutable (from the class name and/or Javadoc). But, someone could pass in the following class to that method: public EvilFoo extends ImmutableFoo { public StringBuilder buf; public EvilFoo(StringBuilder buf) { this.buf = buf; } } The user can now access EvilFoo in multiple threads at the same time. This problem afflicts BigDecimal and BigInteger. The only way to safely use those classes (wrt threading) is to write the following: public void processNumber(BigDecimal bd) { if (bd.getClass() != BigDecimal.class) { bd = new BigDecimal(bd.toString()); // or some other conversion technique } .... } Most users do not do this, so their usage of BigDecimal is not actually thread-safe (or safe against a clever hack). Given all the above, we in Commons and [lang] should take the lead, and only declare something as "immutable" if it really is - which generally means final fields and final class. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
