我认为EJB3.0比EJB2.0除了在使用性上方便以外，原理和机制都没有变化太大，我对EJB 3.0印象认为是下面公式：
EJB 3.0 = EJB 2.0 + xDoclet
本文作者疑问：Java是否在走入一个不归路？怪不得已经有不少人对其失望，追捧Rubby了，以后Jdon要开下去，得改名是“解道”，而不是J道，呵呵，开玩笑。
http://www.theserverside.com/news/thread.tss?thread_id=36110
http://www.softwarereality.com/programming/annotations.jsp
这篇文章写得很有意思，把SUN公司狠狠骂了一通，也确实是这样。
SUN认为annotations是元数据，作者认为其实reflection API才是真正的MetaData，它定义了类的元定义。
annotations只是提供了软件如何被编译、部署和执行的附加数据，这不是metadata, 它是附加数据，it’s decorative data.
作者认为annotations是一种硬编码(hard code)的配置，作者认为编程者使用annotations容易导入一些硬编码，如数据表结构名称，如@Table(name="CUST", schema="RECORDS") 等。这些好像是EJB3的所谓新功能。
annotations被期望替代XML，但是并没有。
annotations容易被滥用，这是最严重的。
当然作者观点无疑是偏激的，其实任何技术一旦被误用，就会非常糟糕，由本文可看出，java 5中的annotations新功能是一把双刃剑，需要小心。
注意3(来自 Javaworld.com.tw)
Metadata Annotation vs Deployment Descriptor XML 的部分
@方面, 你可以x衿渲幸环N碓O定你的 EJB 相P配置c Resources ,
不一定完全需要使用 @Annotation !
如果你之前大量裼 XDoclet , 你就容^容易接受 @Annotation 的^念
resources 槭颤N要裼 XML ?! @是大多倒こ的思考行楸恢暗Framework 框架住了. f真的, _始的r候我也有c排斥, ^ saijone 的指c解f, 我X得 annotation is better
只是, 你楹我懦饽
下面是我的解
1. Compiling-Time Check
You can find the wrong setting in metadata annotations in compling-time, and u can't find it when u set each resource in the deployment descriptor, ( it will display error when u deploy it ).
2. Developing Simplification
Yap, use annotation, u just need one main BeanClass + BusinessInterface without any deployment descriptor (XML), when u wanna modify or setting some other resources in xml editing , u need another powerful tool like "XMLspy" or etc..
3. IDE integration
When u use the annotation with IDE ( new version which supported to JDK1.5 or Java EE 5.0 ) , u can ez to insert or modify ur annotation in the java files, Don't feel sucker, I think it is a great design in Java EE 5.0
You can view some opensources for IDE , ex, NetBeans or Eclipse!
4. You won't modify any resources in ur XML
Yap, XML is a great design for dynamic deploy for every great design.
if u need to change once and once, please use xml, *HOWEVER*, can u tell me , when u deploy one system to production mode , how many times u ever modified the deployment descriptors ?
so that , u alos can read the JSRs for getting more knowledge in annotation
JSR 175
JSR 181
JSR 220
JSR 250
and etc..
注意4(来自 Javaworld.com.tw)
我想, Bill Burke (JBoss EJB team)
http://www.theserverside.com/news/thread.tss?thread_id=33525
他了@Nr when to use Annotation vs whe to use XML
http://jboss.org/jbossBlog/blog/bburke/?permalink=When_to_use_annotations.txt
他的意思主要是, 你在O或修改的r候都绊到你的 Metadata ( 原本可能是在 XML 之中 ) 那N, 你就使用 Annotation 是比^好的x, 因 annotation U容易去淼. 你 "可y性 (portable)" 或 "{整性(Configurable)" 放在比^先的考量, 那N就使用 XML 去O定你的 Resource !
K且在一些 comment 的研x上 ( source codes are the best document ! )
例如 @OneToMany(mappedBy="item") 就可以清楚地定xPS, 比起
/** comments */ K且 XML 看, 菀自S多.
1. 的_, 你要O定每 Method 的r候, 程式@得臃[
但是如果 IDE @Annotation 可以O定槟撤N特殊的色彩甚至[藏,
也S可以解Q你的@}.
2. Interceptors 定x在各 class 之中, 相Φ那r, 你也O定在各 xml 中, 回到 Bill Bruke's Role, 如果你有C薷s不影到原有程式, 那N就裼 deployment descriptors 去O定 AOP !
for examples :
其我F在的, 2004 年在 TheServerSide 就已 JSR-175 Metadata 有一番口舌之
http://www.theserverside.com/news/thread.tss?thread_id=25465
到底是不是 ugly syntax ?! 看你自己吧
理解为修饰数据是否更合适了！我查了下字典。
Annotation如果是想在code和XML之间做些什么的话，那么可以肯定这种尝试，目前我们确实普遍存在这样情况下：代码修改了，忘记去修改配置文件，结果等到运行时才知道出错，大量调试时间被这种低级错误困扰。
而Annotation试图将XML定义联系到代码中，这样，修改代码时，可一起修改配置文件，Annotation就是起这个目的。
但是，XML配置中可能有很多hard code的东西，比如数据表名称等，这些不灵活的元素可能顺着Annotation这个导管爬进代码，让代码变得很臭，这是作者提出抗议的问题所在。
这个问题出现过以前EJB实体Bean设计上，编程者在大量查询也使用CMP，结果实体bean被骂得一塌糊涂，其实这不是实体Bean的错误啊。
Annotation和xDoclet还有本质区别，xDoclet是一个附加包，一般编程者达到使用xDoclet，java水平已经不是初级，对各方面都有掌控和认识能力，所以他们会喜欢xDoclet。
但是，SUN把它导入java语言核心，则变成初学者可能会误用的危险功能，这个好事之作有点象中国古代那句成语，叫什么来着，我忘记了。
这是不对的，看看EJB3 这张slide，告诉你EJB 3是什么：
http://media.techtarget.com/tss/BeJUG/EJB3/index.html
我知道你看到了一些误导的言论，所幸你来Jdon，告诉你真相：
EJB3不是Hibernate已经有定论：
http://www.theserverside.com/news/thread.tss?thread_id=33450
EJB 3.0还是分布式组件模型，这是其基本体系结构，学习EJB困难之处是：我们必须以一个分布式场景来设计或编程EJB，这些都没变。
如果说EJB本身在发展，吸取一些其他框架如Hibernate/Toplink等简化设计，就断定"EJB3.0实际上是完全推翻了EJB2.X"是不熟悉2.X的人说的胡话。
Annotation只是xDoclet的一种替代和升级；但是在其中会设计一些硬编码，而SDO则使用名-值对的数据来处理这个问题，与那些带有注解的javaBeans相比，SDO不是强类型的。
看来，未来JEE注意不是J2EE的前途未知，IBM/BEA在EJB3迟迟未推出服务器可见我在SOA文章中谈到一样，这些巨头主力已经开始转移。
质疑JDK 5.0的文章：
Better, faster, stupider Java
更好 更快 更适合笨人使用的java
http://www.eclipsezone.com/eclipse/forums/t54318.html
文章中写到：
最近很多在谈到java语言相对C#的"提高""improving" ， J2SE5引入了generics, foreach, autoboxing, 和 varargs 等其他特性，使得在编程方面更“易于”编程。特别是元数据Annotations被认为比doclet 更加“干净”和“强大”. 现在，对应C#确实有更多改变了，但是今天的Java程序员还能够读懂明天的代码吗？
作者大声呼吁：
This has got to stop这必须停止了！
我和其他人一样喜欢新的失误，但是Java不是c#
Java来自不同的提供商，而C#来自一个提供商，如果C#改变，那么只要这个提供商发布一个新的.NET框架版本即可，但是Java却不是那么轻松的，我们还有很多程序跑在1.4版本上......还有一年时间其他供应商才能赶上，开源领域的代码也才能赶上。
New language features make Java less great
新的语言特性使Java反而不怎么伟大。
Java伟大之处在于其巨大的第三方软件供应。（注意不是靠SUN公司，我注），今天这个世界上，大多数开源软件都是使用Java完成，但是java需要更稳定，否则我们会失去优势，注意是稳定，而不是死亡。
现在有很多关于新版本的抱怨，很多Eclipse plug-ins 得重新工作（我前面大骂JRE5.0对Eclipse影响可见一证）
搞语言的人总是以自我为中心，喜欢向里面填塞什么就填塞什么，但是考虑过用户感受吗....
作者给出自己的建议：
Hold the line at the JSE 1.4 level or earlier
坚持在J2SE 1.4或以前版本上。
Accept its maturity as a good thing, as a strength that can be built upon, not as a weakness that needs to be corrected.
当一个好东西成熟时再接受它....
这篇文章发表于：
At 10:14 AM on Nov 16, 2005
老外更多讨论：
http://www.javagaming.org/forums/index.php?PHPSESSID=9783192d9858e024a3071bd7bcc315da&topic=11517.msg91149#msg91149
引文：http://dev.csdn.net/article/72/72644.shtm
引文：http://dev.csdn.net/article/72/72644.shtm
对此，你有什么看法
对于未来的看法，谁的看法都没有错，这就象股票走向一样，但是事实是不是准确地按照某种看法那样走呢？大部分未必。
你说：
我认为EJB3.0比EJB2.0除了在使用性上方便以外，原理和机制都没有变化太大，我对EJB 3.0印象认为是下面公式：
EJB 3.0 = EJB 2.0 + xDoclet
而袁红岗说：
EJB 2.x和EJB 3.0没有什么太大关系，从体系结构上来看EJB 3.0实际上是全盘推翻了现在的EJB 2.x
EJB 3.0 = EJB 2.0 + xDoclet + Ioc + AOP
我是专门搞Ioc/AOP框架的（Jdon框架），所以我不觉得引入Ioc/AOP到容器中并不是什么惊人革命变化，惊人革命变化是构件的彻底可分离可配置，不但包括应用系统，也包括框架或者容器本身，所以JBoss 5.0才应需求2006年推出，这是一个彻底可分离的构件系统，JBoss 5.0也没有看到宣布推出。
所以到现在2006年2月止，EJB 3.0看不出革命性变化，我不同意:
"EJB 2.x和EJB 3.0没有什么太大关系，从体系结构上来看EJB 3.0实际上是全盘推翻了现在的EJB 2.x "
在我看来，这是偏激的言论，我前面和Jakarta99争论到最后，有几个能看懂我的意思？包括你，还在问这样的问题，持怀疑的人就只能等事实来说明，而且风险少。