社论: 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 "──是说确实还活着,但不是十分的活跃──最终将会变成真的.