struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: Should we add serialVersionUID fields for example applications?
Date Thu, 06 Sep 2007 17:38:01 GMT
On 9/6/07, James Mitchell <jmitchtx@gmail.com> wrote:
>
> If you didn't know, you can turn off warnings for just that
> particular item under preferences.


This would be my choice. Think about when instances of these classes are
ever going to be serialised anyway - pretty much only when a session is
being temporarily persisted during session migration in a distributed web
app. I can't imagine that we're going to end up with situations in which the
class definitions have changed in the middle of that.

--
Martin Cooper


--
> James Mitchell
>
>
>
> On Sep 6, 2007, at 9:42 AM, Ted Husted wrote:
>
> > So, for complicated reasons, I'm trying to use Eclipse more these
> > days.
> >
> > Something it likes to do is nag that "The serializable class
> > $classname does not declare a static final serialVersionUID field of
> > type long".
> >
> > Since the Actions are serializable, we get this alot :)
> >
> > A seemingly good explanation of the message is here:
> >
> >  * http://forum.java.sun.com/thread.jspa?
> > threadID=581654&messageID=3501336
> >
> > Do we want to go ahead and add the field and silence the nag? Or just
> > turn it off in our Eclipse IDEs? Or add the "@SupressWarnings"
> > annotations? Otherwise, it's hard to tell if we've addressed any other
> > warnings.
> >
> > If we were to add it and use the "quick fix", should we "add a default
> > serial ID" or  "add generated serial ID"?
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message