Oh... I see the problem. No, it's actually not worded in the spec that a null transient variable is *guaranteed* to come back as null (which is why this issue is NOT part of the exam), but it's almost inconceivable that it would not be.
In other words, the problem with using 'transient' is NOT about what will happen to a transient null value, it is about what would happen to something marked transient which is NOT null, if in fact the Container is not using Serialization. In that case, the 'transient' variable would not necessarily be respected, and the non-null, non-serializable thing -- despite being marked transient -- will not be reassigned a default value. No, the Container that is not using serialization will simply try to restore it to whatever it was at the time of passivation. And for a non-Serializable runtime thing like a Socket... well, you get the idea. Bad things could happen.
But we believe that a Container will either;
* Respect 'transient' and restore a value to its default for that type
OR
* NOT respect 'transient' and instead attempt to restore ALL values to what they were before they were passivated.
So, we believe that a null value, despite being marked transient, will always restore as null.
The problem is that a NON-null value, marked transient, will NOT necessarily come back as the default of null, if the Container is not using Serialization and ignores 'transient'.
But, I'm using the
word "believe", so I reckon I should back off just a little on the reasons I gave earlier for using it as a safety measure. Since it isn't technically worded that way in the spec, that DOES leave the possibility that a null transient variable would come back as something other than null, however remote that possibility is... it still exists, I guess. And in that case, I'd have to agree that you'd probably STILL want to be even safer and just take care of it in ejbActivate(), as you suggested.
One more time, though, this is NOT on the exam
What IS potentially on the exam is this;
* Non-null, non-Serializable variables marked transient CAN be passivated. You just can't guarantee what you'll get back...
* Non-serializable variables marked null can be passivated.
(and then of course all of the other rules for things which can be passivated... the way it is defined in the spec).
So I guess you asked a good question, and one that I frankly hadn't even thought about for a long time... I just kind of took it for granted since that's the way we always used to do it in my group at Sun (mark it transient AND set it to null). The real question is perhaps why did we bother with transient at all? (since we're already setting these things to their default values, during passivation.) And the answer was really, "just in case the Container IS using Serialization, for passivation or any other scenario" and in that case, using transient we get a *perhaps* slight performance gain from having the variable skipped completely, which it will NOT be, if it is not marked transient.
OK, that's probably all my brain is capable of on this one...
cheers,
Kathy