java - JavaEE 真的可移植吗？

Question

我只是在执行面试时给我的 JavaEE 作业。

我以前有一些 EJB 经验，但与 JMS 和 MDB 没有任何关系。因此，这是我通过众多示例发现的内容:

• 应用服务器将它们的主题和队列绑定(bind)到不同的 JNDI 名称 - 例如 topic/queue, jms
• activationConfig 属性在 JBoss 上是必需的，而在 Sun 教程中则不是。
• 启动我的应用程序后，jboss 警告我我的主题未绑定(bind)(实际上不是 - 我没有绑定(bind)它，但我希望它自动绑定(bind) - 事实上，在 JBoss 4.0 的示例中自动绑定(bind)似乎确实发生了)。建议的解决方案是将其映射到某些 jboss 文件中，甚至使用特定于 jboss 的注释。

这可能只是 JBoss，但由于它被证明可以按照规范实现，因此规范似乎没有指定这些东西。那里所有所谓的可移植性都消失了。

所以我想知道 - 为什么声称 JavaEE 是可移植的，如果这些极其基本的东西看起来根本不可移植，您可以倾听并将其部署到另一个应用程序服务器上并且它神奇地运行。

附言对不起，我的咆哮，但我想我可能做错了/做错了什么，所以请发表你的意见。

Answer 1

Java EE，就像(几乎？)任何标准一样，是实现者努力宣传遵守但极度不想遵守的东西。

考虑这个问题:红帽是如何赚钱的？通过赠送或出售东西？如果您编写的代码可以很容易地转移到另一个 Java EE 应用程序服务器，这将妨碍他们从您那里赚钱。对此的解决方案是古老的“拥抱和扩展”技术，该技术归功于 Microsoft，但实际上自第一个标准发布以来一直是商业软件供应商的首选工具。

如果您严格代码中的 Java EE API，那么 JBoss(或 Geronimo(或 JonAS(或...)))将运行它以及任何其他兼容的应用程序服务器特定于服务器的部署描述符中唯一需要的更改。这是拥抱阶段。

每台服务器——尤其是商业服务器(如 JBoss)! -- 也倾向于向 API 添加额外的东西以“让事情变得更容易”。 (公平地说，这些通常确实使事情变得更容易。)开发人员——尤其是那些不熟悉标准 API 的开发人员——经常陷入依赖这些额外 API 而不以任何方式包装它们的陷阱，从而允许这些扩展淹没如果您想更改平台，他们的代码将很难删除。这是扩展阶段。

从软件历史上的任何时刻命名一个标准，你会发现人们拥抱和扩展(以至于当人们谈论“致命拥抱”时，我不得不强行将我的想法从供应商锁定问题转移到适当的术语)。您还会发现最终用户(开发人员或其他)爱上它。在这方面，Java EE 与任何其他技术没有什么不同。

然后你考虑到大多数规范的措辞有多糟糕......