Of course if a container makes guarantees, that's very nice, and as it should be; anything that simplifies a developer's task is Good. The point (on which I don't think we're disagreeing), is that not every injection-based system does the right thing *and* documents it clearly and explicitly. Therein lies the rub.
Regarding 'final', I agree that it's regrettable that Java has no keyword for making an entire object immutable. However, if all fields are 'final' then the goal is achieved, albeit verbosely. The troubleseome flaw in injection systems is that they preclude defining such immutable objects; the best that can be done is to add a *claim* (via comment or annotation) that the object is *effectively* immutable. That undermines a valuable language keyword, especially with a highly suggestive 'private' declaration, which isn’t private at all , a sort of x-ray vision under the clothing if you will.
There are code-generation approaches that can fix the "can't use final" flaw in injection systems; fields can be declared final and a class can be derived with appropriate constructors. That is the right way to do it, but it's annoying since the original class is not actually compiled.
[Message sent by forum member 'llc' (llc)]
http://forums.java.net/jive/thread.jspa?messageID=245883