[ https://issues.jboss.org/browse/JBIDE-8586?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8586: -------------------------------------------- This is deliberate - see previous discussions in hibernate tools on this subject. http://opensource.atlassian.com/projects/hibernate/browse/HBX-444 is one of them. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8586?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8586: -------------------------------------------- just to be clear - it does not *has* to be generated; nothing breaks by this except when you communicate between two different JVM's and if you do that it has to be something else than just a single constant which users then ignore to create and thus breaks the serialization contract that way. Eclipse has an annoying default warning for this which makes people think they *must* set it and thus set it but don't realize they then actually stated they will guarantee the serializability of the class...thus we don't create it since we can't make that promise. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8586?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8586: -------------------------------------------- Adding a @SuppressWarning just because Eclipse warns about it and make users think its not important to consider serialVersionUID ? netbeans, javac, intellij etc. does not complain about these afaik. Only real solution is to find a way to reliably generate the serialversionUID ...anything else in between is bad. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira