JavaEE真的可移植吗？

Question

我正在实施一项JavaEE任务,我在接受采访时给出了这项任务.

我有一些关于EJB的经验,但没有任何与JMS和MDB相关的经验.所以这是我通过众多例子找到的:

• 应用程序服务器将其主题和队列绑定到不同的JNDI名称 - 例如topic/ queue,jms
• activationConfigJBoss需要该属性,而在Sun教程中则不然.
• 在开始我的应用程序之后,jboss警告我,我的主题没有绑定(实际上并不是 - 我没有绑定它,但我希望它自动绑定 - 事实上,在一个JBoss 4.0自动绑定的例子中似乎发生了).建议的解决方案是将其映射到一些jboss文件中,甚至使用特定于jboss的注释.

这可能只是JBoss,但由于它经过认证可以实现规范,因此规范似乎并未指定这些内容.所有涉嫌携带的东西都消失了.

所以我想知道 - 为什么声称JavaEE是可移植的,你可以把它放在另一个应用程序服务器上然后神奇地运行,如果这些非常基本的东西看起来根本不可移植的话.

PS对不起咆哮,但我想我可能会做错/做错,所以陈述你的意见.

Answer 1

Java EE就像(几乎？)任何标准一样,是实施者努力宣传坚持但绝望不想坚持的东西.

考虑一下这个问题:红帽如何赚钱？通过放弃或出售它们？如果您编写的代码可以轻松地转移到另一个Java EE应用程序服务器,这将干扰他们从您那里赚钱.对此的解决方案是古老的"拥抱和扩展"技术,该技术归功于微软,但实际上自第一个标准出版以来一直是商业软件供应商的首选工具.

如果您严格遵守代码中的Java EE API,那么JBoss(或Geronimo(或JonAS(或...)))将运行它以及任何其他兼容的应用程序服务器,并且在服务器特定的情况下只需要进行更改部署描述符.这是拥抱阶段.

每个服务器 - 特别是商业服务器(如JBoss)! - 也倾向于在API中添加额外的东西以"简化".(公平地说,这些通常会使事情变得更容易.)开发人员 - 特别是那些不熟悉标准API的人 - 经常陷入依赖这些额外API的陷阱而不以任何方式包装它们,从而允许这些扩展淹没他们的代码,如果你想改变平台,他们很难删除.这是延伸阶段.

从软件历史中的任何一点命名标准,你会发现人们拥抱和扩展(当人们谈论"致命的拥抱"时,我必须强行将我的想法从供应商锁定问题转移到适当的术语) .您还会发现最终用户(开发人员或其他人)不满意.在这方面,Java EE与任何其他技术没有什么不同.

然后你考虑到大多数规格的措辞是多么糟糕......