> Of course, caches are a problem, but I don't fully understand the terms. > I mean: in the end, what matters is the externally visible state, not > the internal one. What's the problem of portions of the state being > computed lazily, if the computing is thread-safe? I mean: what's the > impact on design, I realize it's a headache for people writing tools to > check immutability. I think they are two different concerns, even though > related.
Sorry, went a bit OT from your original question. I was looking from the perspective of a tool writer, you're correct that it does not make a difference for the design, caches/benign data races or not, it's the externally visible state that matters. Since you've now given me the go-ahead in your own thread I'll talk a little about the tool I was mentioning. It's called Mutability Detector, and does static bytecode analysis (much like FindBugs) to tell if a class is immutable or not. It has a command line interface, but what I've been working on most recently, and what I think has the most potential is the ability to unit test for immutability with a call like: "MutabilityAssert.isImmutable(MyClass.class);" Homepage: http://code.google.com/p/mutability-detector/ Blog: http://mutability-detector.blogspot.com/ A point that Reinier raised around passing subclass-able types around, and not being able to guarantee immutability of the runtime instance is a part where automatic checking can break down. This is also the case for abstract/interface types, which can be a bit of a nuisance for having your cake (good design) and eating it too (ensuring/ documenting that interface implementations should be immutable). This pattern appears in JodaTime, where classes take an interface type in the constructor, and store it as a field. The Javadocs have comments such as "This class is immutable, as long as the given implementation of Foo is also immutable." This is something which can be checked automatically by tools, so the developer can say "assertThat(MyClass.class, isImmutable().provided(Foo.class).isAlsoImmutable();"* and that's the only aspect of mutability that's allowed in the class - i.e. if someone adds a setter method, the test will break. Sorry still off-topic from your original question :-/ Cheers, Graham * This assertion is available in the latest code (not release, yet) of Mutability Detector -- 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.
