有了Annotation后,web技术开始退化

Annotation 就像一个分界点， 不少技术都在融入这项技术 ，所以造成技术往回发展，部署麻烦，开发复杂等

用Beehive做例子来说，它也是一种新的页面流 ，网上不少人都在夸它，谈论如何如何用它做开发， 但是甚至没有一个人能说出它比struts好在哪里， 今天简单的看了一下这个技术 ， 没有看出来他在任何方面比struts强， 倒是看出了一个足以不能使用的缺点， 简单地说，它就是把struts的配置文件中的可配置信息统统写到代码里！

好好想想开始为什麽用struts，而不用简单的原始开发，重要的一点就是struts是可配置的，返回，条转的路径都是活的，可以在部署时候任意配置，修改，但现在居然都放到了代码里！

以前因为代码在运行期不够灵活，技术中出现了配置文件，使得许多内容是可配置的，从而减小了工作量，而现在又要减少配置文件的数量，又把配置文件中的内容写回到代码中?!

下面是jakarta beehive例子中的一段代码：

[code:1]
public class Controller
extends PageFlowController {

...

@Jpf.Action(
forwards={
@Jpf.Forward( name="success", path="index.jsp" )
}
)
protected Forward begin()
throws Exception {
Forward f = new Forward("success");
f.addActionOutput("helloMessage", _helloControl.hello());
f.addActionOutput("helloParamMessage", _helloControl.helloParam("World"));
return f;
}

...

}

[/code:1]

都看到了，index.jsp被写死在代码里，让你修改一个路径要重新编译整个工程代码！ 我大概看了spring的webflow，没有用过，但是肯定的是他是有配置文件的，而不是把路径都写死在代码里，单就这一点就很好！值得继续往下研究
说以后 struts和webwork合并后，要把beehive纳入工程中，就没有道理了，这样 struts和ww以后也要完蛋了？
如果说Sun为了推它jdk1.5中annotation这个新东西是为了商业目的有情可原，但是jakarta难道被sun收购了不成？也在把技术往回发展？？
推出新技术是好事，但是一定要注意学的技术一定不能倒退~

Annotation 和web没啥必然联系吧?

不过以后Annotation变成另外一种语言的可能性很大...

什么太复杂了都不好,所以我不看好Annotation,尤其是非常复杂的. 简单一点的,轻量级的还可以考虑


嘿嘿


还是要自己平衡利弊

我没说annotation和web有必然联系，我是说 web技术融入了 annotation后，开始退化！实际上Annotation技术早就有了，就是利用的xdoclet原理，而xdoclet利用的又是 javadoc原理，javadoc模仿的是微软的 COM技术，靠MetaData注释来控制代码，但是越模仿越烂

我觉得差不多，反正不管改配置文件还是改代码，改完以后都要build all然后run all tests，对我来说没区别。

记得去年一个讨论AOP的贴子里，gigix的观点是Annotation只是把元数据从配置文件挪到了源代码，没有实现其他的东西，我本人很赞同。
对于元数据，可以存放到 java代码、脚本、配置文件中，其区别大致是书写方便性、IDE友好性（编译时检查、code assist、设置向导）、布署便捷性。

对Annotation的质疑很大程度上是 在变更时布署上带来的麻烦，那么细究下来，产品什么时候布署新版本？ 公司产品的版本计划和新版本布署方案是什么样的？ 大概不会太频繁吧，都会build all吧。
那么对于开发过程呢？我想只要支持热布署，和以前的开发过程一样，不须我重启应用服务器就OK了。
没用过jdk5.0，希望各位指正。最好讲讲您是怎么用Annotation的，与传统方式在编码和开发布署流程下有什么需要注意的的吗？

唯一用到的annotation，就是@Depracted

我们的开发中，大量用到了annotation。没觉得有什么不方便。正像gigix所说，反正都一样要build all和run all tests

用annotation我就必须每个需要声明的类和方法前面都写一遍声明，如果是XML，我就可以使用通配的办法，只需要在XML里面声明一次，就统配所有的类和方法。

你可以对比一下
http://forum.javaeye.com/viewtopic.php?t=17518
这个帖子中的annotation声明事务和XML声明事务。一个大型的应用，至少有上千个方法需要声明事务，那么annotation你就需要在代码里面写@transaction(strategy="required") 至少上千次。而如果用XML，只需要在XML统配一次。这就是XML的优势。

XML除了这个优势，还有模块化的优势。 分散总归失去统一的视角来看配置的优势。
至于很多人指责的需要编译的问题，其实这个问题不算问题。 说什么可以随时修改XML 配置的优势，我觉得这些优势只是自我夸耀罢了，没有任何的实用，因为如果要你在客户方生产环境修改XML配置，你也不敢不经过测试就随便来改动配置吧。 既然要经过测试环节才能改动配置，那么又何来无需编译的优势之分呢？

所以说，这个优势在真正的开发中最多不过是自我夸耀罢了。

robbin，你要是体会到就者源代码写配置的方便，估计你会对Annotation又爱又恨 的，我个人估计，在source中写annotation 进行系统配置，相对于XML中配置来说，效率要高得多，而且定位和修改配置速度的也要高得多。 另外XML一多，看这也会有点头痛的。
把配置当作源代码的一部分，这需要一段时间来适应。