clojure 1.11.0之后，clj-uuid/v5 uuid不一致

Question

您好，我在升级到Clojure 1.11.0时遇到了以下问题。在我们的应用程序中，我们创建V5（基于名称，SHA1散列）uuids的地方使用了danlentz/clj-uuid库。在升级后，v5 uuids产生的变化不一致。例如

(def ^:const +namespace+ #uuid "50d94d91-a1cf-422d-9586-4ddacf6df176")

(clj-uuid/v5 +namespace+ :some-keyword) 

;; Clojure 1.10.3
=> #uuid "d30e9c3c-ced2-534e-a6b8-ecf784fb0785"

;; Clojure 1.11.0
=> #uuid "a16f6719-952a-55b9-b71b-b15dd263665b"

经过一些实验和错误尝试，似乎是由于本地区域参数，即：:some-keyword引起的差异，因为在clj-uuid/v5函数中，它将关键字对象转换为字节数组，现在看起来是不同的。（如果我用字符串而不是关键字作为本地区域参数，则生成的uuid在Clojure升级前后是一致的。）
这些uuids用于下游系统，而且要他们处理这些变化是很困难的。有没有什么方法可以达到与之前相同的uuids？

Answer 1

你好。谢谢你的报告。只为了澄清——测试之间使用的Java版本是相同的，对吗？

Comments

是的，相同的Java版本（openjdk版本"17.0.2"）。

Answer 2

在这里重新整理之前的对话记录——看起来使用关键词作为名字局部部分将会导致clj-uuid使用Java序列化将对象序列化为字节。

Clojure 1.11在关键词（为了改善arity异常报告）上做了一些向后兼容的增量更改，因此1.10和1.11之间的关键词的二进制序列化发生了变化。

我们并不保证Clojure对象在发布版本之间的二进制可序列化性，因此这里的预期这些将会是相同的这种说法是不正确的。在clj-uuid中可以通过多种方式解决这个问题，例如：通过为Keyword特别提供自定义序列化（在UUIDNameBytes协议中）的特定实现（

我们也许可以“修复”这个特定情况，通过将clojure.lang.Keyword的serialversionUID设置为它在1.10中的值（因为这些对象可能是二进制兼容的），我们将会进一步考虑这个问题。但即使我们这么做，我也建议使用更稳定的字符串来作为clj-uuid局部名称部分。

Comments

感谢Alex，这很有道理。我将在clj-uuid上提交一个议题，并看看是否有前进的道路。

---

您可能可以通过创建与关键字类似的和符号类似的Java类（相同的非瞬态字段）并在这两个类中设置serialVersionUID为1.10的serialvers来修复您特定的iss-ue。我相信您那时候可以（稳定地）复制序列化的字节。然后您可以在clj-uuid中重写协议来使用这些pseudo类进行关键字序列化。您将永久依赖于这个修改，但这可能至少为您提供一个迁移的途径。或者，如果您只有少数关键字命名空间，您甚至可以硬编码关键字到字节的映射。

---

谢谢Alex，我会试一试的。顺便问一下，为什么需要在1.11.0之后创建一个符号类，即使它没有修改过？

---

关键字类有一个包含符号的字段，因此序列化将包括这两个类。

---

明白了，谢谢。

---

大家好。是的，我确实希望能有一个专门针对稳定字节数组转换的通用范围更广的对象，特别是关键字对象。

为了更好地理解“伪关键字/符号”类的想法，这些类是否可以以相同的方式序列化而不共享相同的（冲突的）类名？即使我们以相同的方式进行序列化（.writeObject），我对ObjectOutputStream的理解（请参阅https://docs.oracle.com/javase/7/docs/api/java/io/ObjectOutputStream.html）看起来有些失望——它序列化“对象的类、类签名以及所有非瞬态字段的值”。我们可能也需要一个专门的ObjectOutputStream吗？

我一直在查看各种命名空间关键字的字节数组序列化。可能会有可能重建这个，但至少从表面上看，它不像直接传入关键字名称和命名空间的字节数那么清晰。

---

是的，我认为它需要相同的类名。可以在类加载器中加载不同的类（即使是动态类加载器），但这可能是一个相当复杂的解决方案。

---

我让代码工作起来，但不得不复制clojure.lang.Keyword类（正如你所说，它确实需要具有完全相同的类名），并添加了一个serialVersionUID（其值等同于在1.10.0版本中自动生成的类的值）。

我开始寻找有不同类名的方法，然后在序列化逻辑中将它覆写为“clojure.lang.Keyword”，以便自定义类仅用于uuid生成/不冲突，但没有太多运气。例如，这个https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/share/classes/java/io/ObjectStreamClass.java#L708 是ObjectStreamClass中写入名称的位置
- ObjectOutputStream还有一个.writeObjectOverride方法...但是重新实现默认的writeObject并不吸引人

---

我在这里报告了类似的问题：https://ask.clojure.org/index.php/11699/deserializing-upgrading-clojure-invalidclassexception

---

顺便提一下，我认为我们将要做1.11.1版本，并将Keyword和ArraySeq的serialVersionUIDs回滚到1.10.3版本，以便于决定延迟升级路径。

---

关于uuid的延迟升级路径，大家对怎样处理这个问题有什么看法？ 强制使用一个可选的（但稳定的）不兼容序列化？ 默认吗？

---

我认为除了在库上放置兼容性说明外，没有很好的方法来处理这个问题。你可以使用版本条件来处理某些事情，但这些选项都非常糟糕，并且会影响性能。

---

Clojure 1.11.1-rc1现已发布 - 请测试并反馈！

---

非常感谢，看起来很好！