> 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.
But I think we can agree that a conforming EJB container does offer this guarantee, correct? Other IoC systems may not, but I think the query was specific to annotations within the EJB environment.
> 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.
Well, that's an interesting question. Through reflection you can set final fields. If you follow the other contracts regarding final fields (i.e. don't change when they're not supposed be change, basically what we've been discussing here), then we can effectively have final fields within our classes, but have them circumvented for mechanisms such as injection.
So, obviously, deep down, "final" is merely a suggestion if we can in fact route around it, but it's an enforced within the language, and I guess within the JVM (not clear about that). A injection framework can flag the field as accessible, inject it, and then reset the flag.
Dunno what this does to the internal compilers though....
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=245893