]
Manuel Dominguez Sarmiento commented on HHH-2586:
-------------------------------------------------
One more thing:
"However most people don't have a clue what is and what is not a
serialization-incompatible-change to a class." - I completely agree with this
statement. However I assume that Hibernate committers are not "most people" and
would take care of version compatibility.
In any case, what would be the proposed solution to solve cross-version serialization,
when any changes are in fact compatible? We managed to produce a workaround (quite ugly
but it works), but declaring serialVersionUID would make this so much cleaner.
Hibernate Serializable classes do not declare serialVersionUID
--------------------------------------------------------------
Key: HHH-2586
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2586
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.0 alpha, 3.0 beta 1, 3.0 beta 2, 3.0 beta 3, 3.0 beta 4, 3.0 rc 1,
3.0 final, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, 3.1 beta 1, 3.1 beta 2, 3.1 rc 1, 3.1 rc2,
3.1 rc3, 3.1, 3.1.1, 3.1.2, 3.2.0.alpha1, 3.2.0.alpha2, 3.1.3, 3.2.0 cr1, 3.2.0.cr2,
3.2.0.cr3, 3.2.0.cr4, 3.2.0.cr5, 3.2.0.ga, 3.2.1, 3.2.2, 3.2.3
Environment: Not specific to any database, platform or Hibernate version.
Reporter: Manuel Dominguez Sarmiento
Original Estimate: 2 hours
Remaining Estimate: 2 hours
None of the Serializable classes in Hibernate declare serialVersionUID (see
http://www.hibernate.org/hib_docs/v3/api/serialized-form.html#org.hiberna...).
This is recommended practice for ALL classes that implement the Serializable interface
(see Joshua Bloch's Effective Java - Item #54). Adding these fields is trivial and
takes little effort, but is a great enhancement if you are serializing Hibernate classes.
For instance, we upgraded from Hibernate 3.2.2 to 3.2.3 in our production servers. We
serialize process state (which sometimes includes references to Hibernate-managed
entities) every 30 seconds or so and on shutdown, so in the event of failures or
re-deployment, the processes can continue where they left off. We had a huge surprise when
deserialization failed completely because AbstractPersistentCollection had slightly
changed between the 3.2.2 and 3.2.3 releases, and this caused the automatically-generated
default serialVersionUID to change, even though the changes in the serialized form are
compatible as far as we can tell.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: