Welcome! Please see the About page for a little more info on how this works.

+1 vote
in Clojure by
closed by

I have recently updated our application from Clojure 1.10.3 to 1.11.0 and we are now facing deserilization issues when reading an object serialized by the former version via Quartz (scheduler).

This is the error we are getting:

....
org.quartz.impl.StdScheduler.getJobDetail StdScheduler.java: 498
org.quartz.core.QuartzScheduler.getJobDetail QuartzScheduler.java: 1518
org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveJob JobStoreSupport.java: 1374
org.quartz.impl.jdbcjobstore.JobStoreSupport.executeWithoutLock JobStoreSupport.java: 3739
org.quartz.impl.jdbcjobstore.JobStoreTX.executeInLock JobStoreTX.java: 93
org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock JobStoreSupport.java: 3803
org.quartz.impl.jdbcjobstore.JobStoreSupport$9.execute JobStoreSupport.java: 1377
org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveJob JobStoreSupport.java: 1385
org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectJobDetail StdJDBCDelegate.java: 860
org.quartz.impl.jdbcjobstore.StdJDBCDelegate.getObjectFromBlob StdJDBCDelegate.java: 3201
java.io.ObjectInputStream.readObject ObjectInputStream.java: 460
...
java.io.ObjectStreamClass.initNonProxy ObjectStreamClass.java: 699
java.io.InvalidClassException: clojure.lang.Keyword; local class incompatible: stream classdesc serialVersionUID = -2105088845257724163, local class serialVersionUID = 2404715664513862299
org.quartz.JobPersistenceException: Couldn't retrieve job because the BLOB couldn't be deserialized: clojure.lang.Keyword; local class incompatible: stream classdesc serialVersionUID = -2105088845257724163, local class serialVersionUID = 2404715664513862299

I'm wondering if the problem is that Keyword.java has changed recently
and because it doesn't declare it's own serialVersionUID it got a new one.
Is there any reason why the Keyword class doesn't declare its own serialVersionUID? Can we get it fixed?

closed with the note: Fixed in 1.11.1

1 Answer

+1 vote
by
selected by
 
Best answer

Yes, that is the cause for the error. And retroactively, I'd say all of those classes should have set a serialVersionUID when they were made serializable a decade ago. That was surely an oversight. I did find an old jira https://clojure.atlassian.net/browse/CLJ-1327 for this, can't say I've ever run across it in the past.

We have never guaranteed Java serialization of Clojure classes to be stable across releases, but it is unfortunate that this change needlessly caused a different serialization version.

We are currently evaluating the scope of this problem and deciding what to do about it.

by
edited by
Thanks Alex for the prompt response and the insights.
In an ideal world, we would love to see serialVersionUID being added in a minor 1.11.x release to make the class compatible but we can find our way around it by implementing a custom serialization mechanism and migrating existing data managed by Quartz.
by
FYI, I think we are going to do a 1.11.1 and pin the serialVersionUIDs for Keyword and ArraySeq back to the 1.10.3 versions. In case that helps decide on a delayed upgrade path.
by
That sounds great. We very much appreciate this and waiting for a new minor release :).
by
Clojure 1.11.1-rc1 is now available - please test and report back!
by
I probably only replied on slack but of course this works as expected. Thanks again for the swift fix!
...