Hibernate Serializable classes do not declare serialVersionUID

Description

None of the Serializable classes in Hibernate declare serialVersionUID (see http://www.hibernate.org/hib_docs/v3/api/serialized-form.html#org.hibernate.collection.AbstractPersistentCollection).

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.

Environment

Not specific to any database, platform or Hibernate version.

Activity

Show:
Manuel Dominguez Sarmiento
August 14, 2008, 10:07 PM

This might be relevant:

http://c2.com/cgi/wiki?AlwaysDeclareSerialVersionUid

One last fun thing about SerialVersionUIDs - they differ by compiler. The UIDs calculated by JikesCompiler differ from those calculated by javac. Apparently, there's no clear specification for how to calculate the UID implicitly, another argument for declaring your own. – NelsonMinar

(If I recall correctly, the algorithm for computing SerialVersionUIDs looks like it's specified precisely--except that it's actually specified in terms of things (compiler-added initialization methods) that are not specified similarly precisely. – DanielBarclay?)

As I recall, it's worse than that - different JVM's (or maybe it's class libraries) can result in incompatible serializations as well. The moral the FreeNet project took away from this observation (Kaffe was their compiler in question) was to abandon serialization for hand-written serialization based on the Data{Input,Output}Stream classes. Not only do you get reliable storage independent of the JVM and compiler, but then you don't have to muck around with the version ID's... and you don't have to worry about "transient" declarations.

Manuel Dominguez Sarmiento
August 14, 2008, 10:10 PM

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.

Dag Solvoll
September 9, 2008, 3:04 PM

Tried to run the serialver on class org.hibernate.exception.NestableDelegate (hibernate 3.2.5) on different plattforms:

Windows
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20071007 (JIT enabled)
static final long serialVersionUID = -6787310117729693199L;

WIndows
SUN Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode)
static final long serialVersionUID = -6787310117729693199L;

Solaris
SUN Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode)
static final long serialVersionUID = 1009500911220254726L;

I also see that this particular class has an origin from apache, common-lang, where the serialVersionUID was introduced in version 2.2
(see https://issues.apache.org/jira/browse/LANG-286).

Brett Meyer
April 7, 2014, 5:47 PM

In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.

If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.

Thank you!

Brett Meyer
July 8, 2014, 3:10 PM

Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!

Assignee

Unassigned

Reporter

Manuel Dominguez Sarmiento

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Priority

Major
Configure