终于有人开始反感Java 1.5的Annotation了

我不是反感,只是觉得这破坏Java的美感,如果我需要Annotation,我会使用xDoclet,我觉得在Eclipse下使用xDoclet开发EJB还是不错,非常手工化和可控性。

我认为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新功能是一把双刃剑,需要小心。

annotations 并不是要完全的替代 xml config !



注意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 :
<interceptor-class>com.softleader.interceptors.CustomerAudit</interceptor-class>
<around-invoke-method>makeSomeAuditing</around-invoke-method>

其我F在的, 2004 年在 TheServerSide 就已 JSR-175 Metadata 有一番口舌之
http://www.theserverside.com/news/thread.tss?thread_id=25465

到底是不是 ugly syntax ?! 看你自己吧

it’s decorative data

理解为修饰数据是否更合适了!我查了下字典。

繁体字看了难过。

Annotation如果是想在code和XML之间做些什么的话,那么可以肯定这种尝试,目前我们确实普遍存在这样情况下:代码修改了,忘记去修改配置文件,结果等到运行时才知道出错,大量调试时间被这种低级错误困扰。

而Annotation试图将XML定义联系到代码中,这样,修改代码时,可一起修改配置文件,Annotation就是起这个目的。

但是,XML配置中可能有很多hard code的东西,比如数据表名称等,这些不灵活的元素可能顺着Annotation这个导管爬进代码,让代码变得很臭,这是作者提出抗议的问题所在。

这个问题出现过以前EJB实体Bean设计上,编程者在大量查询也使用CMP,结果实体bean被骂得一塌糊涂,其实这不是实体Bean的错误啊。

Annotation和xDoclet还有本质区别,xDoclet是一个附加包,一般编程者达到使用xDoclet,java水平已经不是初级,对各方面都有掌控和认识能力,所以他们会喜欢xDoclet。

但是,SUN把它导入java语言核心,则变成初学者可能会误用的危险功能,这个好事之作有点象中国古代那句成语,叫什么来着,我忘记了。

banq大哥,这你就说错了,EJB3.0和EJB2.X没有太大的关系,从体系结构上看,EJB3.0实际上是完全推翻了EJB2.X

体系架构?你指的是那个层次的体系架构?仅仅是原来的ejb换成pojo?

>EJB3.0和EJB2.X没有太大的关系,从体系结构上看,EJB3.0实际上是完全推翻了EJB2.X

这是不对的,看看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的人说的胡话。

IBM和SUN以及Oracle(没有SUN)搞了一个SOA领域的SGA/SDO概念,其中SDO实际可能是对Annotation一个竞争方案。

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.msg91149msg91149

你好,banq,看了你的这段话,我有点怀疑,下面是金蝶中间件公司的J2EE专家袁红岗对EJB3.0的看法,你两谁说的对呀?
引文:http://dev.csdn.net/article/72/72644.shtm
  

你好,banq,看了你的这段话,我有点怀疑,下面是金蝶中间件公司的J2EE专家袁红岗对EJB3.0的看法:
引文:http://dev.csdn.net/article/72/72644.shtm
对此,你有什么看法

我不知你怀疑什么?我前面言论只是表达一种现状,大家对EJB3.0看法有些分歧,EJB 3.0规范即将进入正式版,但是这么长时间了,你看到IBM或BEA宣布EJB 3.0服务器了吗?

对于未来的看法,谁的看法都没有错,这就象股票走向一样,但是事实是不是准确地按照某种看法那样走呢?大部分未必。

你好,banq,我的怀疑是:
你说:
我认为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

是啊,Annotation只是xDoclet替代,老外也这么说啊。这个问题我好像已经和jakarta99激烈讨论过了,另外你写得公式也不太完整,我记得我是这样写得:
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争论到最后,有几个能看懂我的意思?包括你,还在问这样的问题,持怀疑的人就只能等事实来说明,而且风险少。

JBoss 5迎来中间件彻底的可配置时代