This week we’ve been tracking feedback from the 1.11 release and starting to scope out 1.12 work.

One thing that has bitten a couple people is that the Java serialization of Keyword changed in 1.11.0. This was an unintended effect and we expect to be rolling out a 1.11.1 shortly that addresses that (also fixes ArraySeq serialization which changed inadvertently as well). To explain more, Java serialization writes objects to a stream based on a class identifier (the serialVersionUID) and its private fields. By default, the class identifier is computed based on the public signatures and fields of a class and its parents. Due to internal changes in some bug fixes on Keyword, that signature changed in 1.11. Java has a feature that allows you to "pin" the serialVersionUID so that it is no longer computed - this is a good and recommended thing to do when classes are stable as it makes the serialization of these classes binary compatible even if the class changes in ways that don’t affect serialization. Going way back, Clojure classes were made serializable with helpful patches in the very early days of Clojure, but unfortunately the serialVersionUIDs were never pinned. I reviewed all of the old versions and Clojure has changed these ids frequently for many classes in many releases. We intend in Clojure 1.12 to pin all of these and at least minimize the unintended drift of these ids in the future.

Additionally, we’ve seen a couple reports from using AOT-compiled code from a prior release with a newer runtime where the compiled code used a function that is new (in particular abs in 1.11, but could be any new function that overlaps earlier compiled code). This is not an issue when source is loaded (you’ll get a warning and you can use refer-clojure :exclude to address that warning), but only on previously compiled code. Our intent here is that new functions added to clojure.core (which is auto-referred by default) should never break existing code, so this is definitely something we intend to fix in 1.12 as well. Recompiling with 1.11 (and using refer-clojure :exclude) is sufficient to address the problem.

Interestingly, neither of these are "new" problems with 1.11 (they have both existed for most of Clojure’s life) yet this is the first time we’ve seen them reported to my memory. Various changes in 1.11 made us more likely to see each of them and I’m thankful that people have been rapidly adopting the new release and giving us this feedback in problem reports. So thanks!