The post that kicked Fabrizio's brain into high gear is here: https://groups.google.com/d/msg/project-lombok/TMMwmqkuLQ8/wGCtSSZDOfEJ
My own thoughts: As nice as it would be, we just can't introduce this, practically, into java, except as a very light hint. Immutability must imply side effect free or its useless: I could make a seemingly immutable class (both final and containing only final fields), which nevertheless quaks, walks, and looks like a duck^H^H^H^Hmutable, using a private static IdentityHashMap. If I can do that, then @Immutable as a reliable construct is meaningless. Thus, @Immutable is useless unless it also implies that all methods in this immutable class are side effect free. However, this is impossible; all objects have wait, notify, and notifyAll, and these aren't side effect free. So here we already have to cheat and declare these 3 as not relevant for SEFness/Immutabilityness. At least we do solve the file dilemma here; File's methods clearly aren't SEF, and thus File isn't "Immutable" either. A second major problem is that java classes aren't final by default, and java has no notion of sealed types (sealed = a scala construct whereby a type is public, but only other types in the same package as it are allowed to implement/extend it). Thus, a non-final type cannot usefully be treated as immutable/SEF, as anyone could make a subclass that trivially breaks these constraints. Some mechanic to ensure that subtypes do NOT break their parent's @Immutable annotation would have to be in place. This would mean that lots of useful seemingly immutable classes that exist today can not be marked with @Immutable as that would break backwards compatibility. I conclude that @Immutable is still handy but only as a purely documentary / compiler warning entity. The compiler could help you a bit by telling you about attempting to defensively copy an @Immutable, and it could _maybe_ hint that you appear to be causing side effects or mutating fields in a class which is @Immutable, or has a supertype which is @Immutable. This would be a slight update to simply documenting that a type is Immutable. The JVM will definitely not use @Immutable to change its behaviour; i.e. it will NOT memoize method calls, and it will NOT ignore synchronize locks when dealing with such objects. This also neatly sidesteps the issue of caching results, which makes a class look mutable whilst it should be treated as immutable (even java.lang.String does this for hash codes, so quite relevant)! -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
