Logically - makes sense. Make 'em final. Realistically - the finality of String and friends is an immense pain and led us to ugly Utils classes and lots of non-OO style code.
I wonder if we can contain your BigDecimal logic in some way. My initial thoughts though end up much like the Cloneable marker interface. An Immutable marker interface and an ObjectUtils.toImmutable(Immutable) method. Then using reflection to pick up the toImmutable(Pair) method on Pair. That method would be final and users would be educated to follow the pattern of conversion. The implementation in ObjectUtils would hardcode support for the JVM immutable-but-not classes like BigDecimal, and possibly could handle returning the same object if it's of the type in which the toImmutable final method is declared. I wave my hands around a lot, admitting it's a sketchy solution at best and wonder what better minds can think of. :) Hen On Wed, May 18, 2011 at 9:47 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
