[forge-dev] Create serialVersionUID field on mapped @Entity classes, yes / no?

Dan Allen dan.j.allen at gmail.com
Tue Mar 6 13:31:34 EST 2012


On Tue, Mar 6, 2012 at 04:30, Pete Muir <pmuir at redhat.com> wrote:

> Maybe I said it. It's not good practice to put serialVersionUID=1L, as
> it's broken in reality (all versions are now the same version). If you omit
> it entirely, then the JVM will compute the serialVersionUID for you on the
> fly, from the class file. This is much better for development. Once your
> app has stabilised, you can then go through and generate the ids needed.
> Instead of adding the serialVersionUID, I would suggest adding the relevant
> @SuppressWarnings("serial") (IIRC, that is the one).
>

+1 That's the best approach I've seen yet. It says "I know I need to take
care of that, but it doesn't make sense to get into that level of detail
until the app matures / hatches" Better to have a TODO than a hack.

http://stackoverflow.com/questions/146715/use-the-serialversionuid-or-suppress-warnings

The other thing to do is to try to educate users about it. The goal of
Forge here isn't to push them in one direction or another, but to help them
along the path to success.

I do think it would be nice if Forge could do what Eclipse does and
generate a serialVersionUID for a class. You could either have this as an
option flag when generating an entity or you can do it after the fact
(after the fact probably better).

$forge> add-serial-version-uids

-Dan

-- 
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120306/896fe411/attachment.html 


More information about the forge-dev mailing list