社论: Java EE 走上了可怕的歧途

      这篇社论是TSS的编辑最近发表的,作者对Java EE的发展方向表示了疑问,并且是自己的亲身体会中总结出来的,有很多跟贴对作者的观点进行了补充或反对,有兴趣的朋友可以看看原文里的跟贴,这样可以深入的了解这些外国人对这个论题的观点.

本文是由  外刊IT评论    组织翻译

 

Editorial: Where Java EE goes horribly wrong

确实,Java EE囊括了一切,除了这些小角落.........但是为什么,为什么有这么多的小角落?!

Java EE在动摇,确实是这样的. 我使用它通常是很愉快的. 但是它却在一直打击着我---当它处理了几乎所有的东西,可偏偏忘了一些角落,这些角落它本该覆盖到的,而且能使他更强大,可它却没有. 这成了Java的  Achilles' heel .

例如, 看看我 最近的一次辛苦 ──为了给我的 EIS component 配置一个JMS消息目的地。考虑到我已经有了一个内在的EIS组件──它将与一个JNDI资源交互──这本应该不是一个大问题.

当时的事情是这样的:我写了一个收取mail的EIS组件. 它需要去伪造email地址(例如:所有的地址都是动态生成的),我的意图是当email发过来时,要把每个email送到JMS队列里. 一个message-driven bean监听这个JMS队列来判断是否该忽略这个email还是不能忽略.

我之所以在EIS组件里做这些,是因为这种方式不需要我记住应该把所有的应用组件都启动起来，否者我必需要启动我的数据库和应用程序服务器,把它们全都做好。

这样一来,我的EIS组件启动时需要一个已经准备好的JMS,不然的话它将会绑定一个端口,也就无法运行了. 这样我的"问题"就来了.

证明显示在 Glassfish  里, JNDI 只有在sever完全启动后才会被组装 . 这样,我的EIS组件初始化后,却不可能得到有效的JNDI资源来运行. 这在设计上的,明显的,如果我没搞错,是一种缺陷,我已经将它提交给Glassfish了. ( Bug #1950 , 正巧那一年我还没出生.)

我现在需要一个  Glassfish Lifecycle module ,用它来检查server是否已经准备好了, 这样我就可以从 lifecycle process中得倒 JNDI context了. 我可以启动一些线程(直到我把它们关掉),让它们去做我想要的. 在某方面这算是一个较为清洁的方案,比起将 SubEthaSMTP  拆解,我可以在生命周期模块里只启动 SubEthaSMTP,这样就可以了.

但是...如果我想把它转移到,比如,JBoss,将会发生什么事情? Or OC4J? Or WebLogic? Or WebSphere? Geronimo? JONAS? RESIN? 我现在使用的是Glassfish,用它来开发---主要是因为它是JEE5规格说明书的一种参考实现.并不是因为任何它作为一个应用服务器有着绝对的性能保证的特征. 如果我一直停留在Glassfish上,写一个生命循环事件是不错的事,但是我不想和任何一个特定的server绑的太紧. 这个生命周期只是针对Glassfish的,──其他的server好像并不会跟随着它的带领.

JavaEE ,在这个案例中,让我失败了. 这并不是个大的问题,除非你会在Java EE里的这个角落里一遍一遍又一遍运行这种类型的程序.

你也许想知道为什么人们在有了Messiah又要去关注 Spring ? 你也许想知道为什么  TheServerSide.com 总是对 OSGi and grids and Ruby and AJAX and 之类的喋喋不休?这就是为什么. 它们提供了覆盖那些小角落的方案. 不是一直要这样--我在期待着一个处理application server 的 OSGi or Spring 模板(例如,"向这个bean里注入一个app server,启动它")但是这样我们需要把这些小角落的问题当成它们的本身---角落,而不是一直要斗争下去的障碍.

Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!) JEE规格说明书应该提供一种指示去说明这些小角落,提供一些东西让开发者们可以去依赖. 我知道我对此有保留,我只是对那些它们中的一些没有价值的东西不满意.

有些争论认为,为这种问题提供反射注入点会增加复杂度-- witness people complaining about all the phaselistener things in JSF 2.0 .Hey, I get that. 但是让我们现实点:如果你不需要它们,你就不必使用这种能力. 就是这样,如果你需要它,现在,那就不要漂泊了,你被规格说明书的作者规范在这里了,这个作者会认为通用性能的重要性大于通用需求.

这里必须要改变,否则就像 Bruce Tate 说的 Java is " dead like COBOL "──是说确实还活着,但不是十分的活跃──最终将会变成真的.

评论

10 楼 junxiang 2007-04-09  

Java EE在大型项目里的应用，相对轻量级解决方案还是颇具优势的。

9 楼 junxiang 2007-04-09  

这种帖子。。。

8 楼 opensdp 2007-04-09  

<br/>
<strong>sharajava 写道：</strong><br/>
<div class='quote_div'><br/>
<strong>opensdp 写道：</strong><br/>
<div class='quote_div'><br/>
<strong>sharajava 写道：</strong><br/>
<div class='quote_div'><br/>
<div class='itemsummary'><font size='4'>Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!) </font></div>
<div class='itemsummary'> </div>
<div class='itemsummary'> </div>
<div class='itemsummary'> </div>
<div class='itemsummary'>这里的suck应该是：<font>厌恶令人极不愉快或令人讨厌<font>【俚语】</font>。</font></div>
<br/>
<br/>
<br/>
<br/>
</div>
<br/>
<br/>
你能不能完整的把这句话翻译一下!?<br/>
<br/>
<br/>
</div>
<p>java不是非常糟糕，但实际上，在某些处理方式（本不应该那样处理）上，java确实让人很不爽。</p>
<p>基本理解就这个意思吧，呵呵！翻译确实很难，明白意思就行了。<br/>
<br/>
<br/>
<br/>
</p>
</div>
<br/>
<br/>
<br/>
非常感谢!<br/>
<br/>
<br/>
<br/>

7 楼 rainlife 2007-04-09  

dennis_zane 写道

Java的规范不可能涵盖到小角落，java规范本身就是利益妥协的产物，java承诺的可移植性因为各厂商的扩展而显的没有想象中的理想。

各个厂商针对J2EE的不同实现，它里面会有一些厂家自身的利益问题，很难做到真正意义上面的可移植，记得针对sun提出的“一次编译，到处运行”，有些朋友提出了“一次编译，到处调试”的说法，单从SUN的规范来说，移植性可能不错，但，对于不同的厂商实现，则大不一样了。是否是岐路，对于我们程序员来说，无所谓，我们所关心是，只是是否还能用JAVA来混口饭吃～～～

6 楼 sharajava 2007-04-09  

<br/>
<strong>opensdp 写道：</strong><br/>
<div class='quote_div'><br/>
<strong>sharajava 写道：</strong><br/>
<div class='quote_div'><br/>
<div class='itemsummary'><font size='4'>Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!) </font></div>
<div class='itemsummary'> </div>
<div class='itemsummary'> </div>
<div class='itemsummary'> </div>
<div class='itemsummary'>这里的suck应该是：<font>厌恶令人极不愉快或令人讨厌<font>【俚语】</font>。</font></div>
<br/>
<br/>
<br/>
<br/>
</div>
<br/>
<br/>
你能不能完整的把这句话翻译一下!?<br/>
<br/>
<br/>
</div>
<p>java不是非常糟糕，但实际上，在某些处理方式（本不应该那样处理）上，java确实让人很不爽。</p>
<p>基本理解就这个意思吧，呵呵！翻译确实很难，明白意思就行了。<br/>
<br/>
<br/>
<br/>
</p>

5 楼 zrweng 2007-04-09  

只要我们保持清醒，不误入歧途就好

btw:这个帖子发错版面了，嘿嘿

4 楼 opensdp 2007-04-09  

<br/>
<strong>sharajava 写道：</strong><br/>
<div class='quote_div'><br/>
<div class='itemsummary'><font size='4'>Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!) </font></div>
<div class='itemsummary'> </div>
<div class='itemsummary'> </div>
<div class='itemsummary'> </div>
<div class='itemsummary'>这里的suck应该是：<font>厌恶令人极不愉快或令人讨厌<font>【俚语】</font>。</font></div>
<br/>
<br/>
<br/>
<br/>
</div>
<br/>
<br/>
你能不能完整的把这句话翻译一下!?<br/>
<br/>
<br/>

3 楼 sharajava 2007-04-09  

<br/>
<div class='itemsummary'><font size='4'>Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!) </font></div>
<div class='itemsummary'/>
<div class='itemsummary'/>
<div class='itemsummary'/>
<div class='itemsummary'>这里的suck应该是：<font>厌恶令人极不愉快或令人讨厌<font>【俚语】</font>。</font></div>
<br/>
<br/>
<br/>
<br/>

2 楼 spinach 2007-04-09  

无聊的讨论
有市场就行

1 楼 dennis_zane 2007-04-09  

先不谈内容，这样的帖子倒是不好评价，有广告嫌疑，又似乎是转贴，投隐藏？或者良好？

确实,Java的规范不可能涵盖到小角落，java规范本身就是利益妥协的产物，java承诺的可移植性因为各厂商的扩展而显的没有想象中的理想。