In the book Java Concurrency In Practice it explains the advantages of “effectively immutable” objects versus mutable objects concurrency-wise. But it does not explain what advantage “effectively immutables” objects would offer over really immutable objects.
And I don’t get it: can’t you always build a really immutable object at the moment you’d decide to publish safely an “effectively immutable” object? (instead of doing your “safe publication” you’d build a really immutable object and that’s it)
When I’m designing classes I fail to see cases where I couldn’t always build a truly immutable object (using delegation if needed etc. to build other wrapped objects, themselves truly immmutable of course) at the moment I’d decide to “safely publish”.
So are “effectively immutable” object and their “safe publication” just a case of bad design or poor APIs?
Where would you be forced to use an effectively immutable object and be forced to safely publish it where you couldn’t build a much superior really immutable object?
Yes, they make sense in some cases. An easy example is when you want some property to be generated lazily and cached so you can avoid the overhead of generating it if it’s never accessed.
Stringis an example of an effectively immutable class that does this (with its hashcode).