[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Max Rydahl Andersen commented on HBX-964: ----------------------------------------- I think eclipse's warning is bogus and java.io.Serializable is one of my pet-hates and I guess it's time to document this ;) I disagree with your suggestion for the following reasons: hbm2java puts "implements Serializable" because of two reasons: 1) It is extremely common to serialize entities to have them available in other layers 2) It was always generated that way (e.g. legacy) So why do I not go and add serialVersionUID to the generated entities ? A) by implementing Serializable you just indicate that this object should be able to serialize to a stream, nothing more - nothing less! B) by adding a serialVersionUID you are indicating much more, namely that this class is serializable *across* different versions of it - and note what eclipse generates is as far as I know exactly the same thing that the vm would do anyway, and hence why have that extra line ? C) serialVersionUID=1 is *wrong* since the same class can change over time and the id won't be the same. So what are the options: Either we generate the full serialversionUID based on class signature but that implies B and that is just not true. Or we remove the implements serializable, but what does that statement do besides making eclipse's bogus warnings light up and making all entities non-serializable by default ? Feel very free to convince me of why eclipse's warning is correct and we should all add serialVersionUID even though I'm quite sure very few percent of those people adding the versionuid's doesn't actually do that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Christopher G. Stach II commented on HBX-964: --------------------------------------------- How about adding @SuppressWarnings("serial") for Java 5 output? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Andrew Redhead commented on HBX-964: ------------------------------------ Maybe "implements Serializable" should be removed by default and then when people actually want to implement Serializable they can make their own templates (and choose to add serialVersionUID support if they want, making that support as complicated as they like) ? I've run into some situations where you do not want Serializable on your entities, these include: 1) If your mappings include lazy-loading, serialising an object over to a remote jvm will lead to the dreaded "LIE" unless you've put some thought into making sure the lazy relationships are pre-initialised before serialisation (thought which might not take place if the entities are just generated for you) 2) If your entities AREN'T serializable then you can get the Corba support in the Sun JDK to generate the stubs for your enties - which makes interoperating with .Net apps easy(ier) and avoids messing about with all sorts of type confusion with web-services 3) If you are putting your entities into the JBoss POJO treecache and you want to be sure that you are using the field level replication then not having Serializable on your entities means that if the cache falls back on using java serialisation then the "not serializable" stack trace will let you know about it 4) I guess a contentious suggestion - If you are using shared classloading between your "application tier" and your "presentation tier" and "call by reference" rather than strict jee comliant "call by value" then there is no need for serialisation at all... I don't think that these cases form a compelling argument for removing Serializable support but I really dont think the default templates should make much effort to support it. Cheers, Andy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Dan Lipofsky commented on HBX-964: ---------------------------------- I would also like to see a generated serialVersionUID, but 1L or any constant is wrong, it needs to depend on the class signature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Max Rydahl Andersen commented on HBX-964: ----------------------------------------- If you get one based on signature that does require loading of the entity classes, then sure it should be an option to generate it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Max Rydahl Andersen commented on HBX-964: ----------------------------------------- To jahlborn: "pretty much any change to the class will result in a new serialVersionUID (so the behavior will be correct by default)." ...yes, but do you check if your serial versions id's has changed between builds to make sure they have changed accordingly ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Max Rydahl Andersen commented on HBX-964: ----------------------------------------- @jahlobrn: the difference is that without putting the serialversionuid the code matches the excpected behavior (no guarantee); put serialversionuid and you stop Eclipses stupid warning from happening and you now just have to wait for the seriliazation error to happen in mysterious ways. I know it is not perfect; just stating that I think its wrong ;) With respect to meta attribute then I was more thinking of having a flag like "ejb3" or "java5" as we have today, but since this will add too much configuration I'm fine with enabling generation of serialVersionUID (iif calculated based on signature and iif the class implement serializable) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] Max Rydahl Andersen commented on HBX-964: ----------------------------------------- Agreed - I wanted to remove the Serializable for ages but couldn't because of backward compability. Anyone with a patch for the serialversionuid generation ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-964?page=co... ] jahlborn commented on HBX-964: ------------------------------ one addition to previous algorithm, sort the list of names/types before hashing so the uid is stable even if properties are just re-ordered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira