regards,
Martin
On 7/25/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
Hi Martin,This would make a difference in development. If the UID is the same then you won't get the incompatible message on de-serialization.Wow an actual use case :-)TTFN,-bd-On Jul 24, 2005, at 4:08 AM, Martin Marinschek wrote:Well, I do have that during development. I change a class, and of course the client side serialized version of it is not compatible anymore.
Does it help anything having this UID in there with this usecase? I mean the compiler would still not be able to do anything about instantiating the correct class, cause it is not on the classpath anymore, right?
I don't have anything against adding the UID.
regards,
MartinOn 7/22/05, Bill Dudney < [EMAIL PROTECTED]> wrote:Hi Sean,
yeah I guess 'poor form' is a bit over stated.
I honestly can't think of a situation where it would actually be
important to have it (user requests a page, the admin upgrades to a
new version of myfaces, the user clicks a button and the serialized
page state now has a binary incompatibility seems very far
fetched :-) but I'm tired of the warning messages from Eclipse
(similar to the 'unused import' warning) so I'll fix it as I go along.
Have a great weekend.
TTFN,
-bd-
On Jul 22, 2005, at 2:19 PM, Sean Schofield wrote:
> I know what it does. We used it in an application when serializing
> between client and server and where the two had different VM's, etc.
> I was just curious as to how Eclipse fits into all of this.
>
> No problem adding it. I would disagree that its poor form not having
> it for classes used in a webapp but if you have a preference to add
> it, no big deal.
>
> sean
>
