The distinction between mutability and immutability is typicaly made to distinguish between types that should be used locally and/or in method parameters/return types. This is usually a "more correct" design (inadvertantly following Design By Contract). i.e. passing/returning mutable types is an implicit violation of requirement (providing excessive contract).
Therefore, if you were to formalise your approach further, you'd find that you would follow other certain rules (to avoid violation of requirement):
- mutability/immutability is specified on the interface (not the concrete type)
- all contracts (public methods) are specified on an interface.
(there are many more, but I'll omit them for brevity - the biggest single controversial one is that non-final classes imply a violation of requirement)
Unfortunately, the core API violates many of these fundamentals, and by using
Java, you typically use the core API, but as it evolves, it moves more and more toward them (will someone in Sun wake up?). For example, the String class now has some of its public methods specified on an interface (java.lang.CharSequence), which specifies immutability (by definition of its API specification). In any case, even if the core API were completely rewritten properly, the language itself is tied to some of these flawed concepts.
Acknowledging the numerous flaws assists in making informed decisions.
Hope this helps.