我继承了 15 年以上的 JEE 应用程序，该应用程序使用了一个长期不受支持的持久层，称为 Kodo by Solarmetric (v4)。随后，Solarmetrics 被 BEA 收购，然后被甲骨文收购。对这个持久层的支持早就停止了，我依靠 15 年以上的技术来为整个 应用。
我希望更改持久性实现。据我所知，Kodo 是基于 JDO 规范（但不完全确定是哪个版本）。
用 Hibernate 或纯 JPA 解决方案替换该技术将是一场噩梦 - 应用程序中的太多逻辑依赖于 JDO 实体 ID。
相反，我正在寻找是否可以更轻松地升级/替换为更新的 JDO 实现，例如 DataNucleus。
有没有人有任何将这种旧技术升级到最新技术的经验/成功案例。 DataNucleus 是否向后兼容像 Kodo 这样古老且不受支持的东西？自 2005 年以来，JDO 规范是否发生了足够大的变化，以至于基于 2005 年的实现需要大量重写以支持 2018 年的实现？
【问题讨论】：
标签： jdo datanucleus
DataNucleus 是 JDO 的独立（开源）实现（就此而言，JPA 也是如此）。它以 TJDO 开始，然后成为 JPOX（并成为 JDO 2.0 的参考实现），然后在 2008 年更名为 DataNucleus。它仍然是 JDO 的参考实现（JDO2.0、2.1、2.2、3.0、3.1、和 3.2)。
它目前实现了 JDO 3.2，它比 Kodo 曾经支持的任何东西都要先进得多（在甲骨文通过放弃它来淘汰任何使用它的人之前，他们实现了 JDO 2.0）。人们已成功升级 JDO 应用程序以使用来自其他 JDO 提供商的 DataNucleus，但该问题的答案取决于您是否使用过 Kodo 的供应商扩展。当然，DataNucleus 也是开源的（与 Kodo 不同），因此您不会被公司勒索赎金，并且可以在遇到问题时提供修复。
自 JDO 2.0（您使用什么）以来，JDO 得到了显着扩展，添加了注释、类型安全查询、更多查询方法以及其他功能。据我所知，JDO 的所有版本都旨在向后兼容。去看看Apache JDO website 和DataNucleus docs 看看JDO 发生了什么变化。
【讨论】：
我没有使用 Kodo，但使用了 JDO 和 DataNucleus 的其他实现。我只能说，我认为可以将代码移植到 DataNucleus。通常它应该是向后兼容的，改变的主要是配置而不是代码。我强烈建议不要尝试将其移至其他标准，因为 JDO 比 JPA 或 Hibernate 更广泛和灵活——因此它不仅更容易移植，而且更容易进一步开发。
【讨论】：