Ed Burns wrote:
>>>>>> On Tue, 28 Aug 2007 09:42:08 -0700, Ryan Lubke <Ryan.Lubke_at_Sun.COM> said:
>>>>>>
>
> RL> +
> RL> + /**
> RL> + * <p>Holds the base client ID that will be used to generate per-row
> RL> + * client IDs (this will be null if this UIData is nested within another).</p>
> RL> + */
> RL> + private String baseClientId;
>
> EB> If this is not a part of the saved state, mark it transient using the
> EB> "transient" java keyword.
>
> RL> Why? UIData isn't serializable.
>
> I like using transient to indicate that this ivar is clearly not a part
> of the saved and restored state.
Can you provide examples on where we do this elsewhere in the API?
> Also, just because UIData isn't
> serializable, doesn't mean someone somewhere will try to serialize an
> instance. I think we used to do that in our state saving implementation
> somewhere along the line anyway.
>
If someone tries to serialize it, these ivars being transient or not
will be the least
of their problems.
> EB> Also, I would like to have you explicitly
> EB> initialize this to "null" since you are counting on that being the
> EB> initial value in your new getClientId() method.
>
> RL> Why, Object members will be automatically initialized to null when
> RL> instantiated.
>
> Yes, this is true in Sun's implementation of the JLS, but perhaps it
> might not be true in another vendor's?
>
This is a very basic requirement of the JLS, and while I don't have
access to the JCK,
I would think this would be enforced for compatibility purposes.
> I'm just carrying over some philosophies from Effective C++ to Java and
> I think they still apply.
>
I'll go ahead and change it, though I'm still not sold on transient.
> Ed
>
>