My non-expert view, as a mere user and reader of the Javadoc: Yes,
agree with that, +1.
The Javadoc doesn't make any special case for this, which I tend to
take as meaning the events should be fired. But then the nature and
intention of the events/listeners and their javadoc tends to perhaps
imply the opposite. At any rate it isn't explicit, and the absence of
any mention of it could just as easily be either intentional or simply
an omission. Both behaviours seem at least plausible, with no obvious
or convincing reason to rule either of them out as incorrect and
unintended.
I think this also applies to the HttpSessionAttributeListener
notifications (i.e. just like the HttpSessionBindingListener events,
it's not explicitly stated whether these are fired when an attribute is
set to its existing object).
As developer of a "test double" that implements the HttpSession
"setAttribute" method (in my "ObMimic" library), I've always
interpreted this as something that might differ between containers, and
have had to make it a configuration option.
So even if the spec/javadoc doesn't want to pin this down and it really
is up to the container, I'd still rather see that explicitly stated
(and have it clear that these events might or might not be fired when
setting an attribute to the object it already holds).
On the ordering of valueUnbound and valueBound, I tend to think this is
less critical, as doing them in the wrong order is so clearly wrong
that it can't possibly be acceptable even if not explicitly prohibited.
However, the ordering is a more general problem... whilst the javadoc
is explicit that valueBound is "after this method executes" (?) and any
HttpSessionAttributeListener notifications are after that, it specifies
the valueUnbound call separately and doesn't say anything at all about
its timing. Not even whether it's before or after the new value has
been set. Hence it's unclear whether the valueUnbound processing can
see the new value in the session or only the old value (which it can
already get from the event itself, and in any case is the very object
that's processing the event). I think it makes sense for valueUnbound
to come after the "set", so that the event handling can see the new
value if it needs to (e.g. can detect when valueUnbound is part of a
"no change" update). However, this isn't explicitly mandated, so at the
moment I don't think it can be relied on.
Again, I think it'd be helpful if the spec/javadoc made it clear
whether valueUnbound is before or after the actual "set" - or that this
isn't guaranteed either way. Or ideally spell out the complete ordering
(presumably: set the value, then valueUnbound if necessary, then
valueBound if necessary, then any HttpSessionAttributeListener
notifications?).