|
锁定老帖子 主题：社论: Java EE 走上了可怕的歧途
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-04-09
最后修改：2010-07-03
这篇社论是TSS的编辑最近发表的,作者对Java EE的发展方向表示了疑问,并且是自己的亲身体会中总结出来的,有很多跟贴对作者的观点进行了补充或反对,有兴趣的朋友可以看看原文里的跟贴,这样可以深入的了解这些外国人对这个论题的观点.
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 "──是说确实还活着,但不是十分的活跃──最终将会变成真的. 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2007-04-09
先不谈内容，这样的帖子倒是不好评价，有广告嫌疑，又似乎是转贴，投隐藏？或者良好？
确实,Java的规范不可能涵盖到小角落，java规范本身就是利益妥协的产物，java承诺的可移植性因为各厂商的扩展而显的没有想象中的理想。 |
| 返回顶楼 | |
|
发表时间：2007-04-09
无聊的讨论
有市场就行 |
| 返回顶楼 | |
|
发表时间：2007-04-09
Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!)
这里的suck应该是：厌恶令人极不愉快或令人讨厌【俚语】。
|
| 返回顶楼 | |
|
发表时间：2007-04-09
sharajava 写道： Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!)
这里的suck应该是：厌恶令人极不愉快或令人讨厌【俚语】。
你能不能完整的把这句话翻译一下!? |
| 返回顶楼 | |
|
发表时间：2007-04-09
只要我们保持清醒，不误入歧途就好
btw:这个帖子发错版面了，嘿嘿 |
| 返回顶楼 | |
|
发表时间：2007-04-09
opensdp 写道： sharajava 写道： Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!)
这里的suck应该是：厌恶令人极不愉快或令人讨厌【俚语】。
你能不能完整的把这句话翻译一下!? java不是非常糟糕，但实际上，在某些处理方式（本不应该那样处理）上，java确实让人很不爽。 基本理解就这个意思吧，呵呵！翻译确实很难，明白意思就行了。 |
| 返回顶楼 | |
|
发表时间：2007-04-09
dennis_zane 写道 Java的规范不可能涵盖到小角落，java规范本身就是利益妥协的产物，java承诺的可移植性因为各厂商的扩展而显的没有想象中的理想。
各个厂商针对J2EE的不同实现，它里面会有一些厂家自身的利益问题，很难做到真正意义上面的可移植，记得针对sun提出的“一次编译，到处运行”，有些朋友提出了“一次编译，到处调试”的说法，单从SUN的规范来说，移植性可能不错，但，对于不同的厂商实现，则大不一样了。是否是岐路，对于我们程序员来说，无所谓，我们所关心是，只是是否还能用JAVA来混口饭吃～～～ |
| 返回顶楼 | |
|
发表时间：2007-04-09
sharajava 写道： opensdp 写道： sharajava 写道： Java EE doesn't suck - not really - but let's be real, it DOES suck in ways it shouldn't.(这句话中的suck不知道是什么意思!)
这里的suck应该是：厌恶令人极不愉快或令人讨厌【俚语】。
你能不能完整的把这句话翻译一下!? java不是非常糟糕，但实际上，在某些处理方式（本不应该那样处理）上，java确实让人很不爽。 基本理解就这个意思吧，呵呵！翻译确实很难，明白意思就行了。 非常感谢! |
| 返回顶楼 | |
|
发表时间：2007-04-09
这种帖子。。。
|
| 返回顶楼 | |
