JavaEE真的可移植吗？ [英] Is JavaEE really portable?

问题描述

我正在实施一项JavaEE任务，我在接受采访时给出了这个任务。

I'm just implementing a JavaEE assignment I was given on an interview.

我之前有过一些EJB经验，但与JMS和MDB无关。所以这是我通过众多例子找到的：

I have some prior experience with EJB, but nothing related to JMS and MDBs. So here's what I find through the numerous examples:

• 应用服务器将其主题和队列绑定到不同的JNDI名称 - 例如主题 / 队列， jms


• JBoss需要 activationConfig 属性，而在Sun教程中则不是。


• 启动我的应用程序后，jboss警告我我的主题没有绑定（实际上并没有 - 我没有约束它，但我希望它能自动绑定 - 事实上，在一个JBoss 4.0自动绑定的例子中似乎确实发生了）。建议的解决方案是将其映射到某些jboss文件中，甚至使用特定于jboss的注释。

• application servers bind their topics and queues to different JNDI names - for example topic/queue, jms
• the activationConfig property is required on JBoss, while in the Sun tutorial it is not.
• after starting my application, jboss warns me that my topic isn't bound (it isn't actually - I haven't bound it, but I expect it to be bound automatically - in fact, in an example for JBoss 4.0 automatic binding does seem to happen). A suggested solution is to map it in some jboss files or even use jboss-specific annotations.

这可能只是JBoss，但由于它经过认证可以实现规范，看来规范没有指明这些东西。所有涉嫌可移植性都消失了。

This might be just JBoss, but since it is certified to implement to spec, it appears the spec doesn't specify these these things. And there all the alleged portability vanishes.

所以我想知道 - 为什么声称JavaEE是可移植的，你可以把它放在另一个应用服务器上如果这些非常基本的东西看起来根本不便携，那就神奇地运行了。

So I wonder - how come it is claimed that JavaEE is portable and you can take an ear and deploy it on another application server and it magically runs, if such extremely basic things don't appear to be portable at all.

PS抱歉咆哮，但我想我可能会做错/做错了，所以说出你的意见。

P.S. sorry for the rant, but I'm assume I might be doing/getting something wrong, so state your opinions.

推荐答案

Java EE，像（差不多？）任何标准，是实施者努力宣传坚持但绝望不想坚持的东西。

Java EE, like (almost?) any standard, is something that implementers strive to advertise adherence to but desperately don't want to adhere to.

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

Consider this question: how does Red hat make money? By giving things away or by selling them? If the code you wrote could be easily transferred to another Java EE application server, this would interfere with them making money from you. The solution to this is the venerable "embrace and extend" technique that has been attributed to Microsoft but in reality has been the tool of choice for commercial software vendors since the first standard was published.

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

If you stick strictly to the Java EE APIs in your code then JBoss (or Geronimo (or JonAS (or ...))) will run it as well as any other compliant application server with the only changes being required in the server-specific deployment descriptors. This is the embrace stage.

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

Each server -- the commercial ones (like JBoss) in particular! -- also tends to add extra stuff to the API to "make things easier". (To be fair these often do make things easier.) Developers -- especially those not intimately familiar with the standard APIs -- frequently fall into the trap of relying on these extra APIs without wrapping them in any way, thus allowing these extensions to inundate their code to the point that they're difficult to remove should you wish to change platforms. This is the extend stage.

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

Name a standard from any point in software history and you'll find people embracing and extending (to the point that when people talk about "deadly embrace" I have to forcibly move my thoughts away from vendor lock-in problems to the proper terminology). You'll also find end-users (developer or otherwise) falling for it. Java EE is no different than any other technology in this regard.

然后你考虑到大多数规范的措辞和措辞......

Then you factor in just how badly-worded most specifications are and ...

这篇关于JavaEE真的可移植吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！