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).

All, Adding the serial version from within Forge like Eclipse does is possible but you need the compiled version of your class to have it. (as mentioned above, the JVM computed one) I have created the feature for the deltaspike forge plugin (experimental phase), see (1) The references that I used to create the feature can be found in(2), (3) and (4). Regards Rudy (1) https://github.com/rdebusscher/forge-plugin-deltaspike (2) http://www.javadocexamples.com/java/io/ObjectStreamClass/getSerialVersion... (3) http://www.koders.com/java/fid9C000A36992600FE1843A5AED6FE613BF68B8B1E.as... (4) http://www.javablogging.com/dynamic-in-memory-compilation/ -- Rudy De Busscher :) Offering my free time to OpenSource :) On 6 March 2012 19:31, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: On Tue, Mar 6, 2012 at 04:30, Pete Muir <pmuir(a)redhat.com&gt; 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-sup... 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 _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

> That Eclipse default enable this warning is one of the worst thing Eclipse have done IMO. Yes, but they needed it for the 'Anally Retentive' achievement: http://blog.kennardconsulting.com/2008/12/new-features-in-eclipse-35.html Regards, Richard. On 7/03/2012 10:52 AM, Max Rydahl Andersen wrote: > For reference, same issue was discussed several times over the years of hibernate tools with some suggested implementations but they all basically sucks ;) > > see https://hibernate.onjira.com/browse/HBX-964 > > and yes, generated classes should not set serialversionUID since it implies you actually know how your serialization works AND that you update the uid > when your class changes. > > That Eclipse default enable this warning is one of the worst thing Eclipse have done IMO. > > /max > > > On Mar 6, 2012, at 9:17 PM, Rudy De Busscher wrote: > >> All, >> >> Adding the serial version from within Forge like Eclipse does is possible but you need the compiled version of your class to have it. (as mentioned above, the JVM computed one) >> >> I have created the feature for the deltaspike forge plugin (experimental phase), see (1) >> >> The references that I used to create the feature can be found in(2), (3) and (4). >> >> Regards >> Rudy >> >> (1) https://github.com/rdebusscher/forge-plugin-deltaspike >> (2) http://www.javadocexamples.com/java/io/ObjectStreamClass/getSerialVersion... >> (3) http://www.koders.com/java/fid9C000A36992600FE1843A5AED6FE613BF68B8B1E.as... >> (4) http://www.javablogging.com/dynamic-in-memory-compilation/ >> >> -- >> Rudy De Busscher >> :) Offering my free time to OpenSource :) >> >> >> On 6 March 2012 19:31, Dan Allen&lt;dan.j.allen(a)gmail.com&gt; wrote: >> On Tue, Mar 6, 2012 at 04:30, Pete Muir&lt;pmuir(a)redhat.com&gt; 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-sup... >> >> 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 >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev