我们正在开发一个应用程序，我们正在考虑支持两种不同的 JPA 实现。
目前我们正在使用 openjpa 并且有经过良好测试的代码。
我换了toplink，跑了测试，发现一堆失败。
你会认为因为 JPA 是一个标准，所以不应该有任何差异！
支持两个 JPA 实现的理由是我们可以在多个应用服务器上运行。
首先，实现和服务器之间是否存在一对一的映射。例如，我可以在 WAS 上使用 toplink，在 Glassfish 上使用 openjpa 吗？
在我进一步调查各种故障之前的第二个问题是，JPA 规范是否如此广泛以至于无法支持两种实现？我是否应该费心尝试让代码同时使用两者？
【问题讨论】：
标签： jpa
通常，JPA 实现是规范的超集。如果您小心地尽量减少对供应商特定功能的依赖，则应用程序应该是可移植的。
但在实践中，实现之间可能存在细微差别，这使得应用程序很难真正跨 JPA。
在我看来，最好尽可能地遵守标准，以便移植到其他 JPA 实现时只需进行最少的更改。如果您正在为特定公司在特定环境中开发应用程序，则针对多个 JPA 实现对其进行测试没有多大意义，反之亦然。
【讨论】：
不，这不是真的 - 应用程序服务器不强制执行任何 JPA 实现，您应该能够将 OpenJPA 与各种应用程序服务器一起使用。就像您可以在任何可以使用任何其他 JPA 实现的地方使用 Hibernate 一样。是的，在事情变得正确之前，您可能需要完成一些 jar 冲突和故障排除......
不，让您的代码适用于两个或多个 JPA 实现并非不切实际。但是这种没有具体需要的练习的目的是相当不切实际的。一般来说，您最好选择最能满足您的要求的 JPA 实现......但是，我可以再次想象，当交替使用不同的 JPA 实现时可能成为必要的情况：客户要求、许可限制、不同的数据库支持、不同的平台支持（例如移动、嵌入式等）。
【讨论】：
当我们使用 TopLink Essentials 并迁移到 EclipseLink 时，我们注意到了同样的事情。尽管 EclipseLink 基于相同的代码库，但我们的代码在很多地方都出错了！
我们发现大多数情况是由于 TopLink Essentials 没有完全遵守 JPA 规范（例如本机查询返回向量列表等）。我希望 EclipseLink 和 Hibernate 之间的可移植性会更好，但可能并不完美。
在某些时候，您可能想要使用一些供应商特定的扩展，例如缓存。出于这个原因，我建议选择 JPA 提供程序并首先仅使用 JPA 规范中指定的功能。如果一段时间后您仍然对特定提供商感到满意，请坚持下去并开始利用供应商特定的功能。
我认为您选择的应用程序服务器不会限制您的 JPA 选项，反之亦然。至少我不知道有任何限制。
【讨论】：