我的项目原来的开发环境是Struts+Spring1.2.8+Hibernate3.1.2，现在要把页面的jsp+jstl，和Struts的Action转换成yui-ext的Ajax页面，简单实现数据列表、翻页和添加、修改、删除等功能。

1. 数据交换，要从Struts环境的Action通过request对象传递数据给jsp页面，如果用Ajax，比较常用的是XML转换和Json转换，我选择了Json，因为用json-lib包可以在java端用很方便的把对象转换成Json格式，在页面可以调用脚本eval()转换成javascript的数组对象。

1) json-lib转换java对象(下载json-lib:http://json-lib.sourceforge.net)
Action例子：(example.do)代码中加入：
response.setContentType("text/xml;charset=utf-8");
JSONArray jsonArray = JSONArray.fromObject(list);
response.getWriter().print("{datalist:" + jsonArray + "}");
return null;
简单说明：把action的return mapping改成null,因为现在使用response对象进行数据传递，fromObject(list)中的list包括就是页面需要调用显示的数据，可以是其他java对象，String、bean或Map。

2) JSONDataModel调用Action(example.do)
yui-ext通过JSONDataModel.js把json格式转换成javascript的数组对象
js例子：
var schema = {
root: 'datalist',
id: 'nothing',
fields: ['a','b', 'c', 'd']

dataModel= new YAHOO.ext.grid.JSONDataModel(schema);
dataModel.load('http://xxx/example.do');

说明：schema的root参数要和action传递的json数据头list对应，这里new JSONDataModel后，JSONDataModel会把example.do返回的json数据转换成dataModel的数组，JSONDataModel继承于LoadableDataModel，JSONDataModel只复杂转换json数据，其他由继承的类实现，这是yui-ext的特点，你可以自己写DataModel继承父类，转换自己的数据格式，yui-ext提供了JSONDataModel和XMLDataModel两种数据格式转换。

3) 使用grid显示dataModel数据
js例子：
var grid = new YAHOO.ext.grid.Grid('example-grid', dataModel, colModel);
grid.render();
jsp页面例子：
<div id="example-grid" style="border: 1px solid #cccccc; overflow: hidden; width: 535px; height: 225px;"></div>
说明：colModel的使用看example，grid绑定dataModel后，在页面的<Div>显示grid。

乱世盼英雄

maven的一些常用任务

maven资源库

maven体系结构

WAS是定位在大型企业应用，集群系统。它的cell-->node-->server，profiles架构以及server上的cluster做得还挺强大的。但是，也许99%的用户都用不到，而且它的cell-->node-->server架构在WLS的domain-->server类似，但WLS非常易用。不过对于大型网站的前端http server，IBM自己加工的那个apache，和WAS配合还是挺好的。

在部署方面，WAS比WLS烦琐得多，虽然也支持命令行和自动部署，但比WLS难，因为发布一个app，大概要更新18个xml配置文件，n个步骤，手动更改配置文件几乎不现实，而WLS只需要把package丢过去就ok了，production环境下也只要控制台选择一下就ok了。在WAS下，我碰到一次是，集群同步时出错，下次几个server都启动不起来，手动修改serverindex.xml等相关文件才搞定，幸好那只是测试环境。

我用JProfiler监测WAS和WLS，WAS运行一段时间后，当时我那个环境启动了300多个thread，而WLS只启动50多个，而且WAS启动一般三分钟，而WLS可能半分钟。

另外，一般IBM的WAS运行在AIX、小型机环境下，而小型机的内存可能有个8G，这时候，最好是把WAS做成纵向分布式，也就是说，一个AIX上安装两个WAS。这个我当初也不明白，现在有体会了，因为这样比较好利用内存，因为JVM的heap设置过大并不好，很影响GC性能。还有，可能你的实际的应用怎么都不可能超过2G的heap。

给大家推荐几本WAS部分用到的IBM红皮书吧，他对我摆平我们这个大项目的WAS问题非常有帮助，我只推荐我仔细读过的、认为最值得看的，它们都可以在ibm红皮书网站下载：
《WebSphere Application Server V6 System Management & Configuration.pdf》：WAS教材
《WebSphere Application Server V6 Planning and Design WebSphere Handbook Series.pdf》：WAS教材高级版本，怎么去规划WAS。
《WebSphere Version 6 Web Services Handbook Development and Deployment.pdf》：Web Services教材，对Web Services本身讲解也很深入浅出。
《WebSphere Application Server V6 Security Handbook.pdf》：WAS安全必备书籍
《WebSphere Application Server V6 Problem Determination for Distributed Platforms.pdf》：WAS出问题了，看它吧。不过，这本书太初级，恐怕出了问题，它70％都不能帮你解决，还是去找IBM技术支持吧。

建议：WAS出问题了，一定要耐心研读红皮书，了解WAS的原理，盲目尝试往往都得不偿失，因为你做点改动，启动重启一次都要5分钟，重启20多次，一般一天时间就过去了，也就是说你只能知道有20个不行的尝试，但也许还有100个不行的尝试等着你，呵呵。总之，尝试你永远都不知道真正为什么会出错。

忘了，一定深入了解WAS里面的Classloader原理，这对你部署过程中出问题非常有帮助，譬如xml找不到，log打印不出来呀，我曾经也是饱受折磨。用好它，必须有深厚的理论基础，它不是给普通开发人员用的，反正我认为他的易用性是很失败的。

总是，每次问题发生的现象和理论上的总是不一致，导致我们不知道从何入手，也无从检测自己的优化参数。咨询过多次IBM技术支持，只解决了某些局部问题。
虽然问题依然存在，但我想，解决问题的思路、特别是理论基础，还是有一些规律和原则。

对于WAS这块，我近段时间的主要时间集中在以下几个方面(时间顺序)：
1、Java性能监测工具：Jprofiler，也用到Jprobe。后来发现Jprofiler在AIX下几乎不可用。
2、IBM Java虚拟机和WAS技术细节，特别是IBM JVM的GC原理，我发现它和sun、bea的差别很大。
3、IBM的heap分析器Heap Analyzer、GCCollector。这两个事后监测工具非常实用，特别是我们的产品运行环境，非测试环境。
4、某些Application的怀疑和诊断。
5、AIX诊断，我几乎没有这个能力，只能常规监测一下，需另请高人。

我打算将本文分成以下几个部分总结：
JVM原理、IBM JVM的GC策略和调优。
Jprofiler和IBM工具的实际体会
WAS的诊断体会和AIX调优

下面开始主题吧，可能比较零碎，另外，开始的理论篇基本上看书都可以，我只是总结一下，再添加一些自己的理解。

以下是我参考的最重要的两本电子书和一些网站：
《Inside Java Vrtual Machine》:半部分有约四章我认为非常棒，其它章节可能意义不大。
《The Java Virtual Machine Specification, 2nd》：前半部分有两三章很不错，不过可以对照上一本书看。
sun的hotspot虚拟机技术：http://java.sun.com/javase/technologies/hotspot/
BEA的JRockit虚拟机技术：http://edocs.bea.com/jrockit/geninfo/genintro/index.html JVM技术文档入口，虚拟机理论，内存泄漏诊断等的索引页。
IBM诊断资料：http://www-128.ibm.com/developerworks/java/jdk/diagnosis/ 上面有一个500多页的pdf文档，对IBM JVM技术和诊断讲解很深入。

我不得不提的是，在查资料这块，BEA和Sun都有很好的官方文档和论坛支持，并且官方文档导航非常好。虽然IBM的诊断资料也不少，但需要搜索，其搜索是很痛苦的。而且，IBM官方论坛很差。如果用IBM的产品出问题，切记：找IBM技术支持，千万不要蒙着头搞！反正它们的产品很少免费。说实话，它们的技术支持还是挺负责的，一般会为你推荐很多support资料，而该资料往往都在developerworks网站上，属于support那个频道，但你就是搜不着。

Java虚拟机规范概要
研究Java虚拟机，首先要了解Sun的Java虚拟机规范。现在，该实现版本很多，如比较有名的Sun、IBM、BEA、Apple、HP、MS、Apache Harmony。它们都实现了JVM规范，但有各自扩展。譬如，针对IBM虚拟机的堆碎片导致OutOfMemory（OOM），在Sun的虚拟机上就不会发生。Sun的JVM有maxPermSize的概念，IBM就没有，如果你设置这个参数，虚拟机根本就启动不了。
比较有意思的是，学Java，就一定要了解各种规范，这和MS的风格很不一样。Sun总是在定义一些规范，实现都留给各厂商。我们除了理解规范本身外，一定要理解规范和实现之间的关系，譬如JDBC规范和JDBC驱动的关系，它们是怎么组合到一起的。要是你用过php的xml解析库，或db函数，就会体会深刻，它们可没有什么规范可言，所以每个数据库厂商的db函数用法都不一样。我推荐大家研读一下HSQLDB的jdbc和Tomcat的servlet相关实现，因为我认为它们还是比较好懂的。
JVM规范只是定义一个虚拟机该做什么，但它并没有要求你该怎么做。例如我们最常见的Servlet规范，在该规范中，有HttpServletRequest、HttpServletResponse，HttpSession等接口，但它们的实现都留给了各个容器厂商。遗憾的是，规范留下的空白，会把我们这些开发人员给整惨了：容器间移植有时候就是恶梦。譬如J2EE并没有SSO规范，但它很重要，我以前专门针对它做过WebSphere AppServer和Weblogic AppServer的SSO项目，差别还是不小，不过还是有点共通，那就是都遵循JAAS规范。

JVM的结构
从功能上分，Java虚拟机主要由六个部分组成，可以分成三类：
第一类：JVM API：就是我们最常用的Java API，它是开发人员和Java交互的入口，它主要是JAVA_HOME/jre/lib下的运行时类库rt.jar和编译相关的tools.jar

第二类：JVM内部组件
类装载器(ClassLoader)：将Byte Array的 .class文件装载、链接和初始化。
内存管理(Memory Managent)：为对象分配内存，以及释放内存。后者就是垃圾回收Garbage Collector（GC）。由于JVM最复杂的、最影响性能的就是GC，所以内存管理一般就指垃圾回收。
诊断接口(Diagostics Interface)：这主要体现在JVMTI(jdk1.4下的JVMPI和JVMDI)，它主要用来诊断程序的问题和性能，一般提供给工具厂商实现。如eclispe IDE下的debug功能，Jprofiler性能调优工具。
类解释器(Interpreter)：解释装载进虚拟机的class对象，包括JIT等特性相关。

第三类：平台相关接口(Platform Interface)：主要为了跨操作系统平台重用JVM代码，不过，它和我们开发人员关系不大。

在以上六个组件中，我们开发人员最关心的是ClassLoader和GC，用Java做系统框架、容器和它们密切相关。做业务系统时一些基础代码也和它们打交道，譬如最常用的Class.forName(),Thread.currentThread.getContextClassLoader()。我们仔细想想，为什么是上面两个问题？因为，它和我们class的整个生命周期最为相关：怎么将一个class和相关class加载进来，class实例什么时候创建，什么时候被销毁？
所以，下面的部分我们要专门讨论这些问题。

ClassLoader
JVM主要有三类ClassLoader：Bootstrap、Extention、Application，该三类ClassLoader从上到下是分级(hierarchy)结构，遵循代理模型(Delegation Model)。
Tip：大家可以看看sun.misc.Launcher的源码，Bootstrap和Extention就在该文件里。该src可以在sun的网站上下载该压缩包，约60M(jdk-1_5_0-src-scsl.zip)，它不在jdk自带的那个src.zip里。

Bootstrap ClassLoader：也称为primordial(root) class loader。主要是负责装载jre/lib下的jar文件，当然，你也可以通过-Xbootclasspath参数定义。该ClassLoader不能被Java代码实例化，因为它是JVM本身的一部分。

Extention ClassLoader：该ClassLoader是Bootstrap classLoader的子class loader。它主要负责加载jre/lib/ext/下的所有jar文件。只要jar包放置这个位置，就会被虚拟机加载。一个常见的、类似的问题是，你将mysql的低版本驱动不小心放置在这儿，但你的Web应用程序的lib下有一个新的jdbc驱动，但怎么都报错，譬如不支持JDBC2.0的DataSource，这时你就要当心你的新jdbc可能并没有被加载。这就是ClassLoader的delegate现象。常见的有log4j、common-log、dbcp会出现问题，因为它们很容易被人塞到这个ext目录，或是Tomcat下的common/lib目录。

Application ClassLoader：也称为System ClassLoaer。它负责加载CLASSPATH环境变量下的classes。缺省情况下，它是用户创建的任何ClassLoader的父ClassLoader，我们创建的standalone应用的main class缺省情况下也是由它加载(通过Thread.currentThread().getContextClassLoader()查看)。
我们实际开发中，用ClassLoader更多时候是用其加载classpath下的资源，特别是配置文件，如ClassLoader.getResource()，比FileInputStream直接。

ClassLoader是一种分级(hierarchy)的代理(delegation)模型。
Delegation：其实是Parent Delegation，当需要加载一个class时，当前线程的ClassLoader首先会将请求代理到其父classLoader，递归向上，如果该class已经被父classLoader加载，那么直接拿来用，譬如典型的ArrayList，它最终由Bootstrap ClassLoader加载。并且，每个ClassLoader只有一个父ClassLoader。
Class查找的位置和顺序依次是：Cache、parent、self。
Hierarchy：上面的delegation已经暗示了一种分级结构，同时它也说明：一个ClassLoader只能看到被它自己加载的classes，或是看到其父(parent) ClassLoader或祖先(ancestor) ClassLoader加载的Classes。
在一个单虚拟机环境下，标识一个类有两个因素：class的全路径名、该类的ClassLoader。

我碰到的一个典型的例子是：在做WAS的SSO开发时，由于我们的类是由WAS在启动时加载，该ClassLoader比下面的部署的Applicaton的ClassLoader的级别高。所以，在我们自己的类中没法用到应用程序的连接池，必须自建。
代理模型是Java安全模型的保证。譬如，我们自己写一个String.java，并且编译、package到自己的java.lang包下。按照代理模型，当前线程的ClassLoader会将其代理到父ClassLoader，父ClassLoader(最终会是Bootstrap)会找到rt.jar下的String.class，也就是说我们的String.class不会捣乱。

自定义ClassLoader
我们前面说过，自定义ClassLoader的缺省父ClassLoader是Application ClassLoader。一般的应用开发用不到它，但我们最好理解。因为在内存泄漏查找、应用程序部署出问题时，很多都和它有关。
譬如，内存泄漏是怎么产生的？这就涉及到ClassLoader和Class的生命周期。我曾经碰到这样一个问题：我们的程序用到了Webwork和Spring框架，当部署到Tomcat下时没有任何问题，但部署到WAS下，报告找不到Webwork的xml的DTD文件，而且Spring的日志也总是失效。Why？因为解析xml dtd时，用的是IBM的Xerces，不是我们的。而Spring日志问题是因为应用程序用的是WAS的Common-log.jar，而不是我们的。将应用的ClassLoader从默认的Parent-First，改成Parent-Last就可以解决，不过我们项目中用到其它库，又发生了其它问题。

一般来说，用到自定义ClassLoader有三种情况：
1、应用框架可以自己控制Classes的目录，并且自动部署。
我读过Jive公司的Wildfire(著名的即时通讯服务器)，它自己有一套应用框架，非常灵活，遵循该框架插件规范的的第三方的plug-in放置在指定目录可以自动部署，实现某些扩展功能，如文件传输、语音聊天。
2、区分用户代码
这被广泛应用在Servlet容器和类似容器，譬如EJB Container设计中，大家看到Tomcat下有common、server、share三个目录吧(ClassLoader顺序从左到有)，另外也有用户应用的WEB-INF目录，它是我们自己开发的。
3、允许Classes卸载
如果没有自定义的ClassLoader，那么我们自己应用中的classes永远都不能被卸载，因为这些类被Application ClassLoader加载后cache起来了，我们的classes一直对该ClassLoader有引用，而该系统级的ClassLoader永远都不会被卸载，除非JVM shutdown了。JSP和Servlet的动态部署就用到这个特性。

待续.......

Note: 还有JVM运行时(Runtime)架构，ClassLoader加载class过程没有总结，这两部分我觉得太重要了，但内容太多，写不完啊。
这部分内容，《Inside Java Virtual Machine》讲解非常清楚，BEA的官方网站这部分也非常不错，要理解深刻，我建议结合JProfiler工具，非常直观。

 
一，找到你了！ 
还记得$()这个东西吧？prototype还是DWR都使用了这个函数代替document.getElementById()。没错，jquery也跟风了。为达到document.getElementById()的目的，jquery是这样写的： 


代码

这些都是较常用的方法，get和post用法一样。第一个参数是异步请求的url，第二个为参数，第三个回调方法。 
3，4的方法会在指定的Dom对象上绑定响应ajax执行的事件。当然，jquery的AJAX相关的函数不仅是这些，有兴趣可以去研究再多。
 
七，渐入淡出 

代码

没错，上面两行代码已经分别实现了一个id为Msg的jquery对象的渐入和淡出。做一个像Gmail一样的动态加载通知条，用jquery就那么简单。两个函数接受的参数除了快慢等，还可以接收整型，作为渐入或淡出的完成时间，单位为MS。
 
八，plugin 
这也是一个插件的时代。 
jquery插件给我的感觉清一色的清洁，简单。如Jtip，要使用它的功能，只需要在你的元素的class上加上Jtip,并引入jtip.js及其样式即可以了。其他事情插件全包。我喜欢jquery的一个重要原因是发现她已经有了很多很好，很精彩的插件。 
写得很烂。可能大家看不出jquery的好处。嗯，光听是没用的，试用一下吧。你会发觉很有趣。 
暂时告一段落吧。待有新的发现再来分享。

加一些Jquery的资源： 
http://www.visualjquery.com/index.xml 很好的API查询站点 
http://jquery.com/demo/thickbox/ 知道lightBox吧，看看Jquery是怎样实现相同的东西 
http://www.codylindley.com/blogstuff/js/jtip/ Jtip，实用的提示工具 
http://jquery.com/plugins/ 很多牛的插件。 
http://15daysofjquery.com/jquery 的15天教程

   “有如此多的Linux版本可供下载、安装并完全免费使用的替换方案，为什么普通电脑用户仍然会选择花费几百美金去购买Windows或Mac操作系统呢”？

总的来说，并不是所有人都讨厌Windows的：普通用户每天在使用他们的Windows电脑时并没有遇到很多麻烦。

版本型号过多： 人们在面对Vista时只需考虑是选择家用基本版还是升级版，但普通的用户该如何在36种不同口味的Linux中做出选择呢？人们说“选择一个合适Linux版本的感觉，有点象一个没有经验的人来到了星巴克咖啡馆，你期望能够点一杯普通咖啡---但你会马上意识到生活并不是那么简单，你需要跑出长队并做大量的研究，然后再一次走到柜台前。”

人们需要确定的是硬件和软件都能很好的工作：“所有人在从Windows转到Linux时都需要从头开始考虑应用程序的问题... ...考虑每一个你所用应用程序的替代方案是一件很繁重的工作。”

至于大多数人所关心的，（Linux）命令行又走了恐龙式的复杂路线：它提供的功能更强大了，就象是Windows 的PowerShell（一种脚本技术），但是你确定普通用户也需要如此强大的功能吗？也许这对于系统管理员在维护服务器运行环境时会很有效，但普通用户甚至不需要知道它（命令行）的存在。

 Linux桌面仍然很令人讨厌：但我认为这方面他们正在改进，Ubuntu桌面就比几年前的KDE或Gnome更加友好，再看Bery1桌面... ...确实令人惊讶！！但是我自己并非普通用户，我不认为我的律师朋友在写合同或文件的时候会发现它是实用的。

由于Mac的影响：想要追求与众不同的人会选用Mac，它建立在Unix之上，但是所有的复杂性都隐藏在性感的GUI和围绕它建立的封闭hw Apple背后。

谁来提供免费的技术支持？：大家会知道，周围人中“谁熟悉Windows系统”。在Mac系统下，这个问题更需要谨慎对待。但对于Linux，我真的怀疑象一个普通会计Jane，在她的朋友圈中是否会有人擅长Linux。

冷静下来，这仅仅是一个操作系统！：在Linux社区里充满了新潮的男孩，他们把这个开源操作系统看得太严肃了，这让人觉得充满了攻击性，并且有太多RTFM（指只要查阅文件就可以解决，拿出来提问只是浪费别人时间的问题）问题。这让人们远离了Linux。

　　我热爱Linux，我认为Beryl的桌面很好，强大的命令行功能很好，能够自由选择哪一个应用程序运行也很好，但是，就象我之前说的，我并不是一个普通用户，就象98%阅读我文章的读者（大多为Linux爱好者）一样。　

　　　普通用户可不愿意花费整晚的时间对着电脑研究它们（Linux），仅仅为了让它们能够正常运行。【翻译　付江】

　　请先看下面这段程序：

public class Hello{
public static void main(String[] args){ //(1)
System.out.println("Hello,world!"); //(2)
}
}

　　看过这段程序，对于大多数学过Java 的从来说，都不陌生。即使没有学过Java，而学过其它的高级语言，例如C，那你也应该能看懂这段代码的意思。它只是简单的输出“Hello,world”，一点别的用处都没有，然而，它却展示了static关键字的主要用法。

　　在1处，我们定义了一个静态的方法名为main，这就意味着告诉Java编译器，我这个方法不需要创建一个此类的对象即可使用。你还得你是怎么运行这个程序吗？一般，我们都是在命令行下，打入如下的命令(加下划线为手动输入)：

javac Hello.java
java Hello
Hello,world!

　　这就是你运行的过程，第一行用来编译Hello.java这个文件，执行完后，如果你查看当前，会发现多了一个Hello.class文件，那就是第一行产生的Java二进制字节码。第二行就是执行一个Java程序的最普遍做法。执行结果如你所料。在2中，你可能会想，为什么要这样才能输出。好，我们来分解一下这条语句。（如果没有安装Java文档，请到Sun的官方网站浏览J2SE API）首先，System是位于java.lang包中的一个核心类，如果你查看它的定义，你会发现有这样一行：public static final PrintStream out;接着在进一步，点击PrintStream这个超链接，在METHOD页面，你会看到大量定义的方法，查找println，会有这样一行：

public void println(String x)。

　　好了，现在你应该明白为什么我们要那样调用了，out是System的一个静态变量，所以可以直接使用，而out所属的类有一个println方法。

静态方法

　　通常，在一个类中定义一个方法为static，那就是说，无需本类的对象即可调用此方法。如下所示：

class Simple{
static void go(){
System.out.println("Go...");
}
}
public class Cal{
public static void main(String[] args){
Simple.go();
}
}

　　调用一个静态方法就是“类名.方法名”,静态方法的使用很简单如上所示。一般来说，静态方法常常为应用程序中的其它类提供一些实用工具所用，在Java的类库中大量的静态方法正是出于此目的而定义的。

静态变量

　　静态变量与静态方法类似。所有此类实例共享此静态变量，也就是说在类装载时，只分配一块存储空间，所有此类的对象都可以操控此块存储空间，当然对于final则另当别论了。看下面这段代码：

class Value{
static int c=0;
static void inc(){
c++;
}
}
class Count{
public static void prt(String s){
System.out.println(s);
}
public static void main(String[] args){
Value v1,v2;
v1=new Value();
v2=new Value();
prt("v1.c="+v1.c+" v2.c="+v2.c);
v1.inc();
prt("v1.c="+v1.c+" v2.c="+v2.c);
}
}

　　结果如下：

v1.c=0 v2.c=0
v1.c=1 v2.c=1

　　由此可以证明它们共享一块存储区。static变量有点类似于C中的全局变量的概念。值得探讨的是静态变量的初始化问题。我们修改上面的程序：

class Value{
static int c=0;
Value(){
c=15;
}
Value(int i){
c=i;
}
static void inc(){
c++;
}
}
class Count{
public static void prt(String s){
System.out.println(s);
}
Value v=new Value(10);
static Value v1,v2;
static{
prt("v1.c="+v1.c+" v2.c="+v2.c);
v1=new Value(27);
prt("v1.c="+v1.c+" v2.c="+v2.c);
v2=new Value(15);
prt("v1.c="+v1.c+" v2.c="+v2.c);
}
public static void main(String[] args){
Count ct=new Count();
prt("ct.c="+ct.v.c);
prt("v1.c="+v1.c+" v2.c="+v2.c);
v1.inc();
prt("v1.c="+v1.c+" v2.c="+v2.c);
prt("ct.c="+ct.v.c);
}
}

运行结果如下：

v1.c=0 v2.c=0
v1.c=27 v2.c=27
v1.c=15 v2.c=15
ct.c=10
v1.c=10 v2.c=10
v1.c=11 v2.c=11
ct.c=11

　　这个程序展示了静态初始化的各种特性。如果你初次接触Java，结果可能令你吃惊。可能会对static后加大括号感到困惑。首先要告诉你的是，static定义的变量会优先于任何其它非static变量，不论其出现的顺序如何。正如在程序中所表现的，虽然v出现在v1和v2的前面，但是结果却是v1和v2的初始化在v的前面。在static{后面跟着一段代码，这是用来进行显式的静态变量初始化，这段代码只会初始化一次，且在类被第一次装载时。如果你能读懂并理解这段代码，会帮助你对static关键字的认识。在涉及到继承的时候，会先初始化父类的static变量，然后是子类的，依次类推。非静态变量不是本文的主题，在此不做详细讨论，请参考Think in Java中的讲解。

静态类

　　通常一个普通类不允许声明为静态的，只有一个内部类才可以。这时这个声明为静态的内部类可以直接作为一个普通类来使用，而不需实例一个外部类。如下代码所示：

public class StaticCls{
public static void main(String[] args){
OuterCls.InnerCls oi=new OuterCls.InnerCls();
}
}
class OuterCls{
public static class InnerCls{
InnerCls(){
System.out.println("InnerCls");
}
}
}

　　输出结果会如你所料：

InnerCls

　　和普通类一样。内部类的其它用法请参阅Think in Java中的相关章节，此处不作详解。

二、this & super

　　在上一篇拙作中，我们讨论了static的种种用法，通过用static来定义方法或成员，为我们编程提供了某种便利，从某种程度上可以说它类似于C语言中的全局函数和全局变量。但是，并不是说有了这种便利，你便可以随处使用，如果那样的话，你便需要认真考虑一下自己是否在用面向对象的思想编程，自己的程序是否是面向对象的。好了，现在开始讨论this&super这两个关键字的意义和用法。

　　在Java中，this通常指当前对象，super则指父类的。当你想要引用当前对象的某种东西，比如当前对象的某个方法，或当前对象的某个成员，你便可以利用this来实现这个目的，当然，this的另一个用途是调用当前对象的另一个构造函数，这些马上就要讨论。如果你想引用父类的某种东西，则非super莫属。由于this与super有如此相似的一些特性和与生俱来的某种关系，所以我们在这一块儿来讨论，希望能帮助你区分和掌握它们两个。

在一般方法中

　　最普遍的情况就是，在你的方法中的某个形参名与当前对象的某个成员有相同的名字，这时为了不至于混淆，你便需要明确使用this关键字来指明你要使用某个成员，使用方法是“this.成员名”，而不带this的那个便是形参。另外，还可以用“this.方法名”来引用当前对象的某个方法，但这时this就不是必须的了，你可以直接用方法名来访问那个方法，编译器会知道你要调用的是那一个。下面的代码演示了上面的用法：

public class DemoThis{
private String name;
private int age;
DemoThis(String name,int age){
setName(name); //你可以加上this来调用方法，像这样：this.setName(name);但这并不是必须的
setAge(age);
this.print();
}
public void setName(String name){
this.name=name;//此处必须指明你要引用成员变量
}
public void setAge(int age){
this.age=age;
}
public void print(){
System.out.println("Name="+name+" Age="+age);//在此行中并不需要用this，因为没有会导致混淆的东西
}
public static void main(String[] args){
DemoThis dt=new DemoThis("Kevin","22");
}
}

　　这段代码很简单，不用解释你也应该能看明白。在构造函数中你看到用this.print(),你完全可以用print()来代替它，两者效果一样。下面我们修改这个程序，来演示super的用法。

class Person{
public int c;
private String name;
private int age;
protected void setName(String name){
this.name=name;
}
protected void setAge(int age){
this.age=age;
}
protected void print(){
System.out.println("Name="+name+" Age="+age);
}
}
public class DemoSuper extends Person{
public void print(){
System.out.println("DemoSuper:");
super.print();
}
public static void main(String[] args){
DemoSuper ds=new DemoSuper();
ds.setName("kevin");
ds.setAge(22);
ds.print();
}
}

　　在DemoSuper中，重新定义的print方法覆写了父类的print方法，它首先做一些自己的事情，然后调用父类的那个被覆写了的方法。输出结果说明了这一点：

DemoSuper:
Name=kevin Age=22

　　这样的使用方法是比较常用的。另外如果父类的成员可以被子类访问，那你可以像使用this一样使用它，用“super.父类中的成员名”的方式，但常常你并不是这样来访问父类中的成员名的。

在构造函数中

　　构造函数是一种特殊的方法，在对象初始化的时候自动调用。在构造函数中，this和super也有上面说的种种使用方式，并且它还有特殊的地方，请看下面的例子：

class Person{
public static void prt(String s){
System.out.println(s);
}
Person(){
prt("A Person.");
}
Person(String name){
prt("A person name is:"+name);
}
}
public class Chinese extends Person{
Chinese(){
super(); //调用父类构造函数（1）
prt("A chinese.");//(4)
}
Chinese(String name){
super(name);//调用父类具有相同形参的构造函数（2）
prt("his name is:"+name);
}
Chinese(String name,int age){
this(name);//调用当前具有相同形参的构造函数（3）
prt("his age is:"+age);
}
public static void main(String[] args){
Chinese cn=new Chinese();
cn=new Chinese("kevin");
cn=new Chinese("kevin",22);
}
}

　　在这段程序中，this和super不再是像以前那样用“.”连接一个方法或成员，而是直接在其后跟上适当的参数，因此它的意义也就有了变化。super后加参数的是用来调用父类中具有相同形式的构造函数，如1和2处。this后加参数则调用的是当前具有相同参数的构造函数，如3处。当然，在Chinese的各个重载构造函数中，this和super在一般方法中的各种用法也仍可使用，比如4处，你可以将它替换为“this.prt”(因为它继承了父类中的那个方法）或者是“super.prt”（因为它是父类中的方法且可被子类访问），它照样可以正确运行。但这样似乎就有点画蛇添足的味道了。

　　最后，写了这么多，如果你能对“this通常指代当前对象，super通常指代父类”这句话牢记在心，那么本篇便达到了目的，其它的你自会在以后的编程实践当中慢慢体会、掌握。另外关于本篇中提到的继承，请参阅相关Java教程。

三、final

　　final在Java中并不常用，然而它却为我们提供了诸如在C语言中定义常量的功能，不仅如此，final还可以让你控制你的成员、方法或者是一个类是否可被覆写或继承等功能，这些特点使final在Java中拥有了一个不可或缺的地位，也是学习Java时必须要知道和掌握的关键字之一。

final成员

　　当你在类中定义变量时，在其前面加上final关键字，那便是说，这个变量一旦被初始化便不可改变，这里不可改变的意思对基本类型来说是其值不可变，而对于对象变量来说其引用不可再变。其初始化可以在两个地方，一是其定义处，也就是说在final变量定义时直接给其赋值，二是在构造函数中。这两个地方只能选其一，要么在定义时给值，要么在构造函数中给值，不能同时既在定义时给了值，又在构造函数中给另外的值。下面这段代码演示了这一点：

import java.util.List;
import java.util.ArrayList;
import java.util.LinkedList;
public class Bat{
final PI=3.14; //在定义时便给址值
final int i; //因为要在构造函数中进行初始化，所以此处便不可再给值
final List list; //此变量也与上面的一样
Bat(){
i=100;
list=new LinkedList();
}
Bat(int ii,List l){
i=ii;
list=l;
}
public static void main(String[] args){
Bat b=new Bat();
b.list.add(new Bat());
//b.i=25;
//b.list=new ArrayList();
System.out.println("I="+b.i+" List Type:"+b.list.getClass());
b=new Bat(23,new ArrayList());
b.list.add(new Bat());
System.out.println("I="+b.i+" List Type:"+b.list.getClass());
}
}

　　此程序很简单的演示了final的常规用法。在这里使用在构造函数中进行初始化的方法，这使你有了一点灵活性。如Bat的两个重载构造函数所示，第一个缺省构造函数会为你提供默认的值，重载的那个构造函数会根据你所提供的值或类型为final变量初始化。然而有时你并不需要这种灵活性，你只需要在定义时便给定其值并永不变化，这时就不要再用这种方法。在main方法中有两行语句注释掉了，如果你去掉注释，程序便无法通过编译，这便是说，不论是i的值或是list的类型，一旦初始化，确实无法再更改。然而b可以通过重新初始化来指定i的值或list的类型，输出结果中显示了这一点：

I=100 List Type:class java.util.LinkedList
I=23 List Type:class java.util.ArrayList

　　还有一种用法是定义方法中的参数为final，对于基本类型的变量，这样做并没有什么实际意义，因为基本类型的变量在调用方法时是传值的，也就是说你可以在方法中更改这个参数变量而不会影响到调用语句，然而对于对象变量，却显得很实用，因为对象变量在传递时是传递其引用，这样你在方法中对对象变量的修改也会影响到调用语句中的对象变量，当你在方法中不需要改变作为参数的对象变量时，明确使用final进行声明，会防止你无意的修改而影响到调用方法。
另外方法中的内部类在用到方法中的参变量时，此参变也必须声明为final才可使用，如下代码所示：

public class INClass{
void innerClass(final String str){
class IClass{
IClass(){
System.out.println(str);
}
}
IClass ic=new IClass();
}
public static void main(String[] args){
INClass inc=new INClass();
inc.innerClass("Hello");
}
}

final方法

　　将方法声明为final，那就说明你已经知道这个方法提供的功能已经满足你要求，不需要进行扩展，并且也不允许任何从此类继承的类来覆写这个方法，但是继承仍然可以继承这个方法，也就是说可以直接使用。另外有一种被称为inline的机制，它会使你在调用final方法时，直接将方法主体插入到调用处，而不是进行例行的方法调用，例如保存断点，压栈等，这样可能会使你的程序效率有所提高，然而当你的方法主体非常庞大时，或你在多处调用此方法，那么你的调用主体代码便会迅速膨胀，可能反而会影响效率，所以你要慎用final进行方法定义。

final类

　　当你将final用于类身上时，你就需要仔细考虑，因为一个final类是无法被任何人继承的，那也就意味着此类在一个继承树中是一个叶子类，并且此类的设计已被认为很完美而不需要进行修改或扩展。对于final类中的成员，你可以定义其为final，也可以不是final。而对于方法，由于所属类为final的关系，自然也就成了final型的。你也可以明确的给final类中的方法加上一个final，但这显然没有意义。

　　下面的程序演示了final方法和final类的用法：

final class final{
final String str="final Data";
public String str1="non final data";
final public void print(){
System.out.println("final method.");
}
public void what(){
System.out.println(str+"
"+str1);
}
}
public class FinalDemo { //extends final 无法继承
public static void main(String[] args){
final f=new final();
f.what();
f.print();
}
}

　　从程序中可以看出，final类与普通类的使用几乎没有差别，只是它失去了被继承的特性。final方法与非final方法的区别也很难从程序行看出，只是记住慎用。

final在设计模式中的应用

　　在设计模式中有一种模式叫做不变模式，在Java中通过final关键字可以很容易的实现这个模式，在讲解final成员时用到的程序Bat.java就是一个不变模式的例子。如果你对此感兴趣，可以参考阎宏博士编写的《Java与模式》一书中的讲解。

　　到此为止，this,static,supert和final的使用已经说完了，如果你对这四个关键字已经能够大致说出它们的区别与用法，那便说明你基本已经掌握。然而，世界上的任何东西都不是完美无缺的，Java提供这四个关键字，给程序员的编程带来了很大的便利，但并不是说要让你到处使用，一旦达到滥用的程序，便适得其反，所以在使用时请一定要认真考虑。

　　请先看下面这段程序：

public class Hello{
public static void main(String[] args){ //(1)
System.out.println("Hello,world!"); //(2)
}
}

　　看过这段程序，对于大多数学过Java 的从来说，都不陌生。即使没有学过Java，而学过其它的高级语言，例如C，那你也应该能看懂这段代码的意思。它只是简单的输出“Hello,world”，一点别的用处都没有，然而，它却展示了static关键字的主要用法。

　　在1处，我们定义了一个静态的方法名为main，这就意味着告诉Java编译器，我这个方法不需要创建一个此类的对象即可使用。你还得你是怎么运行这个程序吗？一般，我们都是在命令行下，打入如下的命令(加下划线为手动输入)：

javac Hello.java
java Hello
Hello,world!

　　这就是你运行的过程，第一行用来编译Hello.java这个文件，执行完后，如果你查看当前，会发现多了一个Hello.class文件，那就是第一行产生的Java二进制字节码。第二行就是执行一个Java程序的最普遍做法。执行结果如你所料。在2中，你可能会想，为什么要这样才能输出。好，我们来分解一下这条语句。（如果没有安装Java文档，请到Sun的官方网站浏览J2SE API）首先，System是位于java.lang包中的一个核心类，如果你查看它的定义，你会发现有这样一行：public static final PrintStream out;接着在进一步，点击PrintStream这个超链接，在METHOD页面，你会看到大量定义的方法，查找println，会有这样一行：

public void println(String x)。

　　好了，现在你应该明白为什么我们要那样调用了，out是System的一个静态变量，所以可以直接使用，而out所属的类有一个println方法。

静态方法

　　通常，在一个类中定义一个方法为static，那就是说，无需本类的对象即可调用此方法。如下所示：

class Simple{
static void go(){
System.out.println("Go...");
}
}
public class Cal{
public static void main(String[] args){
Simple.go();
}
}

　　调用一个静态方法就是“类名.方法名”,静态方法的使用很简单如上所示。一般来说，静态方法常常为应用程序中的其它类提供一些实用工具所用，在Java的类库中大量的静态方法正是出于此目的而定义的。

静态变量

　　静态变量与静态方法类似。所有此类实例共享此静态变量，也就是说在类装载时，只分配一块存储空间，所有此类的对象都可以操控此块存储空间，当然对于final则另当别论了。看下面这段代码：

class Value{
static int c=0;
static void inc(){
c++;
}
}
class Count{
public static void prt(String s){
System.out.println(s);
}
public static void main(String[] args){
Value v1,v2;
v1=new Value();
v2=new Value();
prt("v1.c="+v1.c+" v2.c="+v2.c);
v1.inc();
prt("v1.c="+v1.c+" v2.c="+v2.c);
}
}

　　结果如下：

v1.c=0 v2.c=0
v1.c=1 v2.c=1

　　由此可以证明它们共享一块存储区。static变量有点类似于C中的全局变量的概念。值得探讨的是静态变量的初始化问题。我们修改上面的程序：

class Value{
static int c=0;
Value(){
c=15;
}
Value(int i){
c=i;
}
static void inc(){
c++;
}
}
class Count{
public static void prt(String s){
System.out.println(s);
}
Value v=new Value(10);
static Value v1,v2;
static{
prt("v1.c="+v1.c+" v2.c="+v2.c);
v1=new Value(27);
prt("v1.c="+v1.c+" v2.c="+v2.c);
v2=new Value(15);
prt("v1.c="+v1.c+" v2.c="+v2.c);
}
public static void main(String[] args){
Count ct=new Count();
prt("ct.c="+ct.v.c);
prt("v1.c="+v1.c+" v2.c="+v2.c);
v1.inc();
prt("v1.c="+v1.c+" v2.c="+v2.c);
prt("ct.c="+ct.v.c);
}
}

运行结果如下：

v1.c=0 v2.c=0
v1.c=27 v2.c=27
v1.c=15 v2.c=15
ct.c=10
v1.c=10 v2.c=10
v1.c=11 v2.c=11
ct.c=11

　　这个程序展示了静态初始化的各种特性。如果你初次接触Java，结果可能令你吃惊。可能会对static后加大括号感到困惑。首先要告诉你的是，static定义的变量会优先于任何其它非static变量，不论其出现的顺序如何。正如在程序中所表现的，虽然v出现在v1和v2的前面，但是结果却是v1和v2的初始化在v的前面。在static{后面跟着一段代码，这是用来进行显式的静态变量初始化，这段代码只会初始化一次，且在类被第一次装载时。如果你能读懂并理解这段代码，会帮助你对static关键字的认识。在涉及到继承的时候，会先初始化父类的static变量，然后是子类的，依次类推。非静态变量不是本文的主题，在此不做详细讨论，请参考Think in Java中的讲解。

静态类

　　通常一个普通类不允许声明为静态的，只有一个内部类才可以。这时这个声明为静态的内部类可以直接作为一个普通类来使用，而不需实例一个外部类。如下代码所示：

public class StaticCls{
public static void main(String[] args){
OuterCls.InnerCls oi=new OuterCls.InnerCls();
}
}
class OuterCls{
public static class InnerCls{
InnerCls(){
System.out.println("InnerCls");
}
}
}

　　输出结果会如你所料：

InnerCls

　　和普通类一样。内部类的其它用法请参阅Think in Java中的相关章节，此处不作详解。

二、this & super

　　在上一篇拙作中，我们讨论了static的种种用法，通过用static来定义方法或成员，为我们编程提供了某种便利，从某种程度上可以说它类似于C语言中的全局函数和全局变量。但是，并不是说有了这种便利，你便可以随处使用，如果那样的话，你便需要认真考虑一下自己是否在用面向对象的思想编程，自己的程序是否是面向对象的。好了，现在开始讨论this&super这两个关键字的意义和用法。

　　在Java中，this通常指当前对象，super则指父类的。当你想要引用当前对象的某种东西，比如当前对象的某个方法，或当前对象的某个成员，你便可以利用this来实现这个目的，当然，this的另一个用途是调用当前对象的另一个构造函数，这些马上就要讨论。如果你想引用父类的某种东西，则非super莫属。由于this与super有如此相似的一些特性和与生俱来的某种关系，所以我们在这一块儿来讨论，希望能帮助你区分和掌握它们两个。

在一般方法中

　　最普遍的情况就是，在你的方法中的某个形参名与当前对象的某个成员有相同的名字，这时为了不至于混淆，你便需要明确使用this关键字来指明你要使用某个成员，使用方法是“this.成员名”，而不带this的那个便是形参。另外，还可以用“this.方法名”来引用当前对象的某个方法，但这时this就不是必须的了，你可以直接用方法名来访问那个方法，编译器会知道你要调用的是那一个。下面的代码演示了上面的用法：

public class DemoThis{
private String name;
private int age;
DemoThis(String name,int age){
setName(name); //你可以加上this来调用方法，像这样：this.setName(name);但这并不是必须的
setAge(age);
this.print();
}
public void setName(String name){
this.name=name;//此处必须指明你要引用成员变量
}
public void setAge(int age){
this.age=age;
}
public void print(){
System.out.println("Name="+name+" Age="+age);//在此行中并不需要用this，因为没有会导致混淆的东西
}
public static void main(String[] args){
DemoThis dt=new DemoThis("Kevin","22");
}
}

　　这段代码很简单，不用解释你也应该能看明白。在构造函数中你看到用this.print(),你完全可以用print()来代替它，两者效果一样。下面我们修改这个程序，来演示super的用法。

class Person{
public int c;
private String name;
private int age;
protected void setName(String name){
this.name=name;
}
protected void setAge(int age){
this.age=age;
}
protected void print(){
System.out.println("Name="+name+" Age="+age);
}
}
public class DemoSuper extends Person{
public void print(){
System.out.println("DemoSuper:");
super.print();
}
public static void main(String[] args){
DemoSuper ds=new DemoSuper();
ds.setName("kevin");
ds.setAge(22);
ds.print();
}
}

　　在DemoSuper中，重新定义的print方法覆写了父类的print方法，它首先做一些自己的事情，然后调用父类的那个被覆写了的方法。输出结果说明了这一点：

DemoSuper:
Name=kevin Age=22

　　这样的使用方法是比较常用的。另外如果父类的成员可以被子类访问，那你可以像使用this一样使用它，用“super.父类中的成员名”的方式，但常常你并不是这样来访问父类中的成员名的。

在构造函数中

　　构造函数是一种特殊的方法，在对象初始化的时候自动调用。在构造函数中，this和super也有上面说的种种使用方式，并且它还有特殊的地方，请看下面的例子：

class Person{
public static void prt(String s){
System.out.println(s);
}
Person(){
prt("A Person.");
}
Person(String name){
prt("A person name is:"+name);
}
}
public class Chinese extends Person{
Chinese(){
super(); //调用父类构造函数（1）
prt("A chinese.");//(4)
}
Chinese(String name){
super(name);//调用父类具有相同形参的构造函数（2）
prt("his name is:"+name);
}
Chinese(String name,int age){
this(name);//调用当前具有相同形参的构造函数（3）
prt("his age is:"+age);
}
public static void main(String[] args){
Chinese cn=new Chinese();
cn=new Chinese("kevin");
cn=new Chinese("kevin",22);
}
}

　　在这段程序中，this和super不再是像以前那样用“.”连接一个方法或成员，而是直接在其后跟上适当的参数，因此它的意义也就有了变化。super后加参数的是用来调用父类中具有相同形式的构造函数，如1和2处。this后加参数则调用的是当前具有相同参数的构造函数，如3处。当然，在Chinese的各个重载构造函数中，this和super在一般方法中的各种用法也仍可使用，比如4处，你可以将它替换为“this.prt”(因为它继承了父类中的那个方法）或者是“super.prt”（因为它是父类中的方法且可被子类访问），它照样可以正确运行。但这样似乎就有点画蛇添足的味道了。

　　最后，写了这么多，如果你能对“this通常指代当前对象，super通常指代父类”这句话牢记在心，那么本篇便达到了目的，其它的你自会在以后的编程实践当中慢慢体会、掌握。另外关于本篇中提到的继承，请参阅相关Java教程。

三、final

　　final在Java中并不常用，然而它却为我们提供了诸如在C语言中定义常量的功能，不仅如此，final还可以让你控制你的成员、方法或者是一个类是否可被覆写或继承等功能，这些特点使final在Java中拥有了一个不可或缺的地位，也是学习Java时必须要知道和掌握的关键字之一。

final成员

　　当你在类中定义变量时，在其前面加上final关键字，那便是说，这个变量一旦被初始化便不可改变，这里不可改变的意思对基本类型来说是其值不可变，而对于对象变量来说其引用不可再变。其初始化可以在两个地方，一是其定义处，也就是说在final变量定义时直接给其赋值，二是在构造函数中。这两个地方只能选其一，要么在定义时给值，要么在构造函数中给值，不能同时既在定义时给了值，又在构造函数中给另外的值。下面这段代码演示了这一点：

import java.util.List;
import java.util.ArrayList;
import java.util.LinkedList;
public class Bat{
final PI=3.14; //在定义时便给址值
final int i; //因为要在构造函数中进行初始化，所以此处便不可再给值
final List list; //此变量也与上面的一样
Bat(){
i=100;
list=new LinkedList();
}
Bat(int ii,List l){
i=ii;
list=l;
}
public static void main(String[] args){
Bat b=new Bat();
b.list.add(new Bat());
//b.i=25;
//b.list=new ArrayList();
System.out.println("I="+b.i+" List Type:"+b.list.getClass());
b=new Bat(23,new ArrayList());
b.list.add(new Bat());
System.out.println("I="+b.i+" List Type:"+b.list.getClass());
}
}

　　此程序很简单的演示了final的常规用法。在这里使用在构造函数中进行初始化的方法，这使你有了一点灵活性。如Bat的两个重载构造函数所示，第一个缺省构造函数会为你提供默认的值，重载的那个构造函数会根据你所提供的值或类型为final变量初始化。然而有时你并不需要这种灵活性，你只需要在定义时便给定其值并永不变化，这时就不要再用这种方法。在main方法中有两行语句注释掉了，如果你去掉注释，程序便无法通过编译，这便是说，不论是i的值或是list的类型，一旦初始化，确实无法再更改。然而b可以通过重新初始化来指定i的值或list的类型，输出结果中显示了这一点：

I=100 List Type:class java.util.LinkedList
I=23 List Type:class java.util.ArrayList

　　还有一种用法是定义方法中的参数为final，对于基本类型的变量，这样做并没有什么实际意义，因为基本类型的变量在调用方法时是传值的，也就是说你可以在方法中更改这个参数变量而不会影响到调用语句，然而对于对象变量，却显得很实用，因为对象变量在传递时是传递其引用，这样你在方法中对对象变量的修改也会影响到调用语句中的对象变量，当你在方法中不需要改变作为参数的对象变量时，明确使用final进行声明，会防止你无意的修改而影响到调用方法。
另外方法中的内部类在用到方法中的参变量时，此参变也必须声明为final才可使用，如下代码所示：

public class INClass{
void innerClass(final String str){
class IClass{
IClass(){
System.out.println(str);
}
}
IClass ic=new IClass();
}
public static void main(String[] args){
INClass inc=new INClass();
inc.innerClass("Hello");
}
}

final方法

　　将方法声明为final，那就说明你已经知道这个方法提供的功能已经满足你要求，不需要进行扩展，并且也不允许任何从此类继承的类来覆写这个方法，但是继承仍然可以继承这个方法，也就是说可以直接使用。另外有一种被称为inline的机制，它会使你在调用final方法时，直接将方法主体插入到调用处，而不是进行例行的方法调用，例如保存断点，压栈等，这样可能会使你的程序效率有所提高，然而当你的方法主体非常庞大时，或你在多处调用此方法，那么你的调用主体代码便会迅速膨胀，可能反而会影响效率，所以你要慎用final进行方法定义。

final类

　　当你将final用于类身上时，你就需要仔细考虑，因为一个final类是无法被任何人继承的，那也就意味着此类在一个继承树中是一个叶子类，并且此类的设计已被认为很完美而不需要进行修改或扩展。对于final类中的成员，你可以定义其为final，也可以不是final。而对于方法，由于所属类为final的关系，自然也就成了final型的。你也可以明确的给final类中的方法加上一个final，但这显然没有意义。

　　下面的程序演示了final方法和final类的用法：

final class final{
final String str="final Data";
public String str1="non final data";
final public void print(){
System.out.println("final method.");
}
public void what(){
System.out.println(str+"
"+str1);
}
}
public class FinalDemo { //extends final 无法继承
public static void main(String[] args){
final f=new final();
f.what();
f.print();
}
}

　　从程序中可以看出，final类与普通类的使用几乎没有差别，只是它失去了被继承的特性。final方法与非final方法的区别也很难从程序行看出，只是记住慎用。

final在设计模式中的应用

　　在设计模式中有一种模式叫做不变模式，在Java中通过final关键字可以很容易的实现这个模式，在讲解final成员时用到的程序Bat.java就是一个不变模式的例子。如果你对此感兴趣，可以参考阎宏博士编写的《Java与模式》一书中的讲解。

　　到此为止，this,static,supert和final的使用已经说完了，如果你对这四个关键字已经能够大致说出它们的区别与用法，那便说明你基本已经掌握。然而，世界上的任何东西都不是完美无缺的，Java提供这四个关键字，给程序员的编程带来了很大的便利，但并不是说要让你到处使用，一旦达到滥用的程序，便适得其反，所以在使用时请一定要认真考虑。

SVK 是一个基于 Subversion 构造的分布式的版本控制系统。通常的集中式管理系统，如 CVS，Subversion 已经得到广泛应用，但是集中式的管理存在相应的缺陷，例如对唯一的版本库过分依赖：一旦不能正常连接到集中式的版本库，整个系统陷入瘫痪。SVK 最大的能力就在于可以维护分布式的版本库，分散的开发人员可以通过 SVK 建立远程的 CVS，Subversion，P4 协议的版本库镜像，选择工作在自己合适的镜像版本库，这个镜像甚至可以是本地的，整个工作可以离线进行，然后在需要的时候同步镜像版本库到主版本库。

前言

SVK 在大部分的操作与设计思想上都与 Subversion 相似，本文假定读者对 Subversion 有一定的了解，将着重介绍 SVK 新增特性与功能，与 Subversion 重叠的部分就不再赘述。读者可以参考作者的另外一篇 关于 Subversion 的文章。

历史

版本管理工具的历史由来已久，CVS 作为标准的版本管理控制工具已经得到了广泛应用。为改善 CVS 天生的缺陷，CollabNet 开发了 Subversion。Subversion 在目录版本化、原子提交、元数据、分支和标签等方面有了极大的改进，但遗憾的是它仍然是集中式的版本管理工具。不过幸运的是，由于 Subversion 灵活的设计，重用 Subversion 已有组件并扩展其功能成为了现实，SVK 就是这样一个基于 Subversion 的扩展实现。高嘉良先生一年时间的全职工作使 SVK 顺利诞生了。目前 SVK 项目已经被 Bestpractical 收录，读者可以访问其官方主页（请参阅 参考资源）。

License

SVK 是基于 Artistic License 发布的。Artistic License 目前基本被用于标准 Perl，CPAN 组件以及 Parrot 软件上。详细信息请参阅 参考资源。

安装

SVK 由一组基于 SVN 的 Perl 绑定的 Perl5 的模块构成。Subversion 本身是构建于 Apache APR 之上，因此 SVK 可以在任何支持 Apache Http Server 的操作系统上运行，包括 Windows、Linux、Mac OS、Free BSD 以及 Netware。

最简单的安装方式是直接下载对应操作系统的的二进制版本。Windows 版本可以在 这里 找到，Linux 系统上也可以使用 deb 或者 rpm 的安装方式。目前 Cpan 已经提供有 2.0 版本的安装，通过 cpan 的安装方式如下：

首先需要安装 Subversion 的 Perl 绑定，cpan 没有提供这一模块，如果安装 Subversion 的时候没有选择安装 Perl 绑定则需要重新配置及安装 Subversion。

安装 Subversion 的 Perl 绑定需要 swig 的支持，swig 是 C/C++ 软件与其他高级语言的连接器，关于 swig 请参考http://www.swig.org/。

安装 swig

下载 swig1.3.24 以上版本（需要 Perl 5.8.0 以上版本支持），解压后在 SWIG-1.3.xx 目录下运行如下命令，其中 /path/to/correct/perl/binary 应当指向 Perl 的可执行文件：

验证安装 可以用 swig --version 来验证安装是否成功。

./configure --with-perl5=/path/to/correct/perl/binary
make
make install

配置 Subversion

成功安装了 swig 后便可以安装 subverion 的 perl 绑定了，在 Subversion 源代码目录下运行如下命令：

验证安装 如果 Subversion 的 configure 找到了合适的 swig，将会生成名为 libsvn_swig_perl.so 的库文件。

./configure PERL=/path/to/correct/perl/binary

安装 Subversion 的 perl 绑定

make
make swig-pl
make check-swig-pl
make install
make install-swig-pl

通过 cpan 安装 SVK

通过如下命令，cpan 会自动寻找并提示安装所有相关模块。

>cpan
cpan> install SVK

如果全部安装成功。在命令行敲入 svk 便会得到如下的 SVK 帮助信息：

获取帮助 svk help commands 将会列出所有 SVK 支持的子命令。 对于某个特定的命令如 update，svk help update 将会得到关于 update 的说明。 svk help environment 将会列出所有与 SVK 相关的环境变量。

SVK Documentation - Main index:

If this is your first time using SVK, you should start by reading a
brief tutorial. When you're ready, type:

    svk help intro

Once you've done that, more in-depth help is available:

    svk help environment    Environment variables that alter svk's behavior
    svk help commands       A list of all available commands
    svk help view           svk view support
    svk help <command-name> Help for a specific command

For commercial support, contact sales@bestpractical.com. For up to date
information about SVK, visit http://svk.bestpractical.com/.

如果想要体验最新的版本，可以直接从 SVK 的版本库取出最新的源代码进行编译安装：

Perl 绑定安装部分同前述。

svn co http://code.bestpractical.com/svk/trunk/
cd trunk/
perl Makefile.PL
make
make test
make install
svk

新功能

相较于 Subversion 而言，SVK 增加了许多强劲的功能。

Depot

首先介绍一个新概念—— Depot，它是 SVK 进行版本管理的核心。SVK 使用 Subversion 的版本库实现 Depot。对本地 Depot 的引用是使用"//"，由于它完全是 Subversion 兼容的，因此用户也可以很方便的将 Depot 通过 svnserve 或者 http 方式发布到网络上。

Patch

在 Subversion 中，用户可以使用重定向 svn diff 的输出来生成 patch 文件：

svn diff foo > patch.diff

在 SVK 中补丁的功能得到了加强。用户可以通过 commit 以及 smerge 中的 -P(--patch) 选项来创建补丁：

svk commit -m "this is log" --patch patch_name
svk smerge //foo //bar --patch patch_name

创建的补丁将存储在 Depot 同一目录下的 patch 子目录中，用户可以将这一补丁传递给其他用户使用。

同时 SVK 的补丁功能支持对二进制文件的补丁操作，例如：

touch foo
zip foo.zip foo
svk add foo.zip
svk commit -m "this is log" foo.zip --patch patch_name

生成补丁内容如下

==== Patch <patch_name> level 1
Source: [No source]
Target: 9bbf3572-454d-844a-a388-5e5c8078394f:/tony:1
        (http://localhost/repos)
Log:
this is log
=== foo.zip
==================================================================
Cannot display: file marked as a binary type.

Property changes on: foo.zip
___________________________________________________________________
Name: svn:mime-type
 +application/octet-stream


==== BEGIN SVK PATCH BLOCK ====
Version: svk v2.0.0 (MSWin32)

eJxNks1qE1EUx6c1qWIptMFqcaFFpoKLsXM/5iMphqhJKgY10EQUF5ObmZtkZDIzTm6DLVfIaKjF
J9AHENworly57EJbcO8LuPcFxHunFoRh4HDO/3fOPedfT1obFcDLZZ2rQOdbDxulUpMwd7AmItXk
1PNZlKgGD+iYBiriQdRXMQ/JkIosI0mfsnIZCLF9LK5lghMIlowuYVE4UosZzGEJpSrgsIJ4BXLx
FwEQySimoZNEEVMhN6FIOXIgN4hG1JFCWWzKYqjanHie0/MDqlq8F0XXd/1YUhwh1YBACqnxT+r5
CXXFRDuyQPY0ZNbk7oCEfZpBnDiJ4gwMEB+Nw9LQH1KN7cRUhZiTOA58lzA/Ctcjl1GmjcQTyPAY
ZGT5HYfR58yjASOSI+bQkVjHfUVR0uhqenGvmp/W8puFN9XCxL+TLuw9yqWbhWm1MK1deVVP56f1
869rhWbjVO6scvTitjmj7Cpgq0qVr2eU3Iex43odf5F0Onpnolxe7Xl59LiWHoSfnrxs36vfPfz9
/aez8uwIQKDr4Jz+efJ+beUPOkSTg8rT5cl09q02u9Sf7s+n15b3Vy5t3Pz10Vu8BR4sfZtT2q0F
5fSPGwe1ZmNm9sL80qryJRWdc+1WvtnIz80oFfGGdxX8/zWyxct1IciBbVrIw2bPI8TCwKIGMC2I
u7gIDewhOzsuAJwN/NGq+KR9BCiW7nCki8plyFUIj83TyvxUKrVDf0yTEQnWxMWxrB4I6yV0LILt
bd8TflwXnspuqiKTF7vdHjIsqGHRVLMxJhpBtq0Z1HBt3bJREff+AuTM7ls=
==== END SVK PATCH BLOCK ====

因而通常的patch工具不能支持SVK生成的补丁。SVK 提供了一个 patch 命令来应用补丁，patch 命令包含如下一些常用选项：

svk patch --list|--ls
查看当前所有的补丁
svk patch --cat|--view PATCHNAME
查看某一补丁的内容
svk patch --regenerate|--regen PATCHNAME
重新生成补丁
svk patch --apply PATCHNAME [TARGET] [-- MERGEOPTIONS]
应用补丁
svk patch --delete|--rm PATCHNAME
删除补丁

Mirror

SVK 的镜像功能支持如下流行的版本控制工具：

svk mirror [http|svn]://host/path DEPOTPATH
svk mirror cvs::pserver:user@host:/cvsroot:module/... DEPOTPATH
svk mirror p4:user@host:1666://path/... DEPOTPATH

常用的 mirror 选项包括：

--list (-l)
察看本机上的所有 mirror
--detach (-d)
取消一个 mirror
--relocate
将 mirror 的源路经重定向
--unlock
非正常操作导致 mirror 被锁住可以用这个选项解锁

star-merge(smart-merge)

smerge 是 SVK 的亮点之一，SVK 的核心功能都是围绕其展开的。主要操作选项列举如下：

 -I [--incremental]
 渐进式的合并。它可以忠实地记录源版本库的每一次 commit 操作。
 -B [--baseless]
 用最早的版本作为合并的初始点。一般用户新版本库同步的首次合并。
 -b [--base] BASE 
从指定版本开始合并。一般用于合并已有的版本库分支。
 -s [--sync]
 合并前同步 Depot 与源版本库。
 -P [--patch] NAME
 不进行真实的合并，而是将合并内容生成一个补丁。
 -C [--check-only]
 列举合并的内容而不进行真实的操作。

合并过程中难免会遇到冲突的代码，SVK 提供了一些解决冲突的支持。用 perldoc SVK::Resolve 可以列出合并相关的帮助信息：

NAME

    SVK::Resolve - Interactively resolve conflicts

DESCRIPTION

      Accept:
         a   : Accept the merged/edited file.
         y   : Keep only changes to your file.
         t   : Keep only changes to their file.
      Diff:
         d   : Diff your file against merged file.
         dm  : See merged changes.
         dy  : See your changes alone.
         dt  : See their changes alone.
      Edit:
         e   : Edit merged file with an editor.
         m   : Run an external merge tool to edit merged file.
      Misc:
         s   : Skip this file.
         h   : Print this help message.

      Environment variables:
        EDITOR     : Editor to use for 'e'.
        SVKMERGE   : External merge tool to always use for 'm'.
        SVKRESOLVE : The resolve action to take, instead of asking.

在合并的过程中遇到冲突 SVK 会中断操作并提示用户输入：

e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e]

可以选择的操作有编辑当前文件，打印出差异，合并，跳过，保留源端文件以及保留目标端的文件。

选择了 merge 以后 SVK 会自动搜寻可以使用的合并工具：

Multiple merge tools found, choose one:
(to skip this question, set the SVKMERGE environment variable to one of them)
1)GVim, 2)TortoiseMerge, 3)Vim, q)uit?

用户可以使用任何一种合并工具来手动解决冲突。此外 SVK 提供了设定环境变量来定义默认解决冲突的方式，用户可以设定环境变量 SVKRESOLVE 为上述提到的任何一种操作，例如 s(kip)，t(heirs)，y(ours)。

性能

SVK 在大部分方面具有与 Subversion 相当的性能，而在某些可以离线的操作具有更出色的表现。例如 svk status, svk update 以及 svk switch。

CVS，SVK 以及 Subversion 详细的比较数据见 http://svk.bestpractical.com/view/SVKvsSVNvsCVS

完整的例子

这一部分介绍 SVK 的实际使用。

单独使用

假设有一个远程的版本库 http://remote/repos，用户经常需要离线的工作，则可以使用 SVK 在本地计算机上建立一个远程版本库的镜像 Depot：

svk mirror http://remote/repos //mirror/local

为此镜像做一个拷贝，所有本地工作都在这一拷贝上完成

svk cp //mirror/local //local

从本地 Depot 取出 working copy

svk co //local

在能连接到远程版本库的时候，同步远程的版本库到本地

svk sy //mirror/local
svk pull //local

当然，将 Depot 作为 Subversion 版本库发布出来以后用户便可以脱离 SVK，使用 Subversion 的客户端即可访问。这样一来，所有对版本库的工作都可以在没有网络环境的情况下进行，在将来能够连上网络的时候使用如下命令便将所有在本地的更动反映到远程版本库中去：

svk push //local

版本库同步

现今流行的 Open source 开发模式限制了 committer 的数量，并非所有用户都具有 commit 的权限。假设现有一个远程的版本库 http://remote/repos，数个用户希望能够有权限自由的 commmit，自然的，我们可以利用上述的镜像方法获得一个属于自己的版本库，但是这一版本库必须位于某台服务器上而不是某人的个人电脑上，以使得所有用户都能访问到。如果这个版本库是在一台标准的 Subversion 版本服务器上（假设 URL 是 http://myremote/repos），通常用户对此服务器只有访问 Subversion 版本库的权限，也就是说，用户无法直接在这一台服务器上安装 SVK 而做镜像。SVK 很好的解决了这一问题。我们可以使用任何一台和可以很好的连接上这两台服务器的某一台机器作为中间服务器，定时进行同步，下面是主要操作步骤。

在安装有SVK的中间服务器上进行如下操作：

svk mirror http://remote/repos //remote
svk mirror http://myremote/repos //myremote

分别同步两个 depot 的内容

svk sy //remote
svk sy //myremote

定时从 //remote 同步到 //myremote

svk smerge //remote //myremote

同时本文也提供了一个 Perl 脚本 作为示例，读者可以配置它自动运行并生成 Html 格式的 Report。

结束语

SVK 是目前唯一的分布式版本库系统，它成功的对分布式版本库领域进行了有效的探索并获得了成功，它的出现使得以往一些实现起来非常复杂的功能变的十分简单，给一些以往无法完成的操作带来了可能。如 P4，CVS 与 Subversion 版本库的同步与移植，版本库的离线访问，以及远程版本库的镜像和同步等等。期待本文能使更多的读者认识 SVK，并从中获得分布式版本管理的种种便利，使得日常工作更加完美与高效。同时也期待更多的读者与本人交流经验。

下载

	关于下载方法的信息

参考资料

• http://svk.bestpractical.com/ ：SVK 项目的主页。
  
  
• http://svkbook.elixus.org/ ：SVK 文档的在线版本。
  
  
• http://www.swig.org/ ：SWIG 项目的主页。
  
  
• http://code.bestpractical.com/svk/trunk/ARTISTIC ：关于 Artistic License 的基础导言。
  
  
• http://www.opensource.org/licenses/ ：在这里可以找到关于 Open source License 的详细信息。
  
  
• 用 Apache 和 Subversion 搭建安全的版本控制环境 ：本文作者的另一篇关于 Subversion 的介绍文章。

关于作者

		吴玥颢，目前就职于 IBM 中国开发中心 Harmony 开发团队。 除了对 Java 和脚本语言的热爱之外，他的兴趣还包括哲学、神话、历史与篮球。此外他还是个电脑游戏高手。您可以通过wuyuehao

• Trac官方主页
• Trac示例

Trac拥有强大的bug管理功能，并集成了Wiki用于文档管理。它还支持代码管理工具Subversion，这样可以在 bug管理和Wiki中方便地参考程序源代码。

bug管理

在Trac中，项目中出现的问题称为ticket。像bug、功能改进、 TODO等都可以写成一个ticket。

• 可设置ticket的优先级别。
• 可以设置ticket的里程碑，表明这个ticket应在何时完成，并能够通过条形图方式显示里程碑的完成度。
• 可以自定义条件生成bug报告，并可以通过SQL语句自定义报告的格式。

Subversion集成

通过Subversion集成，开发者可在Trac中以Web方式浏览代码库中各个版本的代码和代码的修改历史，并可方便地比较各个版本间的差别。

Wiki

支持常用的Wiki语法。同时增加了许多bug管理的专用标记，可以方便地创建到ticket、代码行甚至修改历史的链接。

Trac使用Python写成，后台使用SQLite或PostgreSQL数据库，因此构筑一个完整的Trac系统需要安装以下软件：

• Apache
• Python
• Subversion
• PostgreSQL(可选)

下回继续介绍Trac的安装方法。

以下假设你的域名为example.com，并假设你要将 blog.example.com 重定向至 www.myblog.com/myname/，如用户访问 http://blog.example.com/archives/sample.html 则会自动转向至 http://www.myblog.com/myname/archives/sample.html。

下面这一段翻译自GoDaddy的帮助。我的免费空间正在使用，因此没法一步步抓图了。

1. 首先登录GoDaddy，然后选择菜单Hosting & Server->My Hosting Account。
2. 你会看到页面上有Free Hosting Credits的字样，单击旁边的Use Credit建立虚拟主机。
3. 选择你要关联的域名 example.com，然后选择主机类型为 Linux，然后Continue。
4. 单击 Set Up Account。
5. 在 Hosting Manager 中单击 Accept 接受最终用户协议。
6. 输入用户名和密码。
7. 单击 Continue。
8. 确认之后单击 Submit。

之后进入Hosting Manager就可以管理你的免费虚拟主机了。控制面板功能很简单，我就不多罗嗦了。下面就开始做域名重定向。

首先打开Domain Management，单击example.com下的Add Sub Domain，添加子域名blog，路径随意，这里选择< same as sub domain >。

大约半小时之后状态会变成 Setup。马上通过FTP登录虚拟主机，可以看到主目录下出现了blog子目录。在 /blog 下建立一个 .htaccess 文件，内容如下。

 <IfModule mod_rewrite.c>
     RewriteEngine On
     RewriteRule ^/(.*) http://www.myblog.com/myname/$1 [R,L]
 </IfModule>

GoDaddy服务器会缓存.htaccess文件状态，新建或删除.htaccess文件一般要等待10-30分钟之后才会生效（修改则会立即生效）。因此建议虚拟主机建好之后马上建立空的.htaccess文件以节约时间。

这样所有访问 http://blog.example.com/ 的请求都会被转向至 http://www.myblog.com/myname/ ，而且你可以通过修改 RewriteRule 来定义更为复杂的转向规则。

　　最近，Spring很热闹，因为实现IoC模式和AOP（见本站专栏），然后又成立公司，吸取上次JBoss的教训，文档不敢收费，结果迎来了一片祝贺声。

　　Spring真正的精华是它的Ioc模式实现的BeanFactory和AOP，它自己在这个基础上延伸的功能有些画蛇添足。

　　其实说白了，大家"惊奇"的是它的IoC模式(使用AOP功能需要了解AOP，比较难)，那么，Spring之类的Ioc模式是什么？ 就是：你在编制程序时，只要写被调用者的接口代码，具体子类实例可通过配置实现。

　　Ioc模式是什么知道的人不多，但是，当他知道生成对象不用再使用new了，只要在配置文件里配置一下，他感到新鲜，其实这就是Ioc模式的实现，PicoContainer是另外一种真正轻量的Ioc模式实现，PicoContainer还是采取代码将对象注射一个小容器中，而Spring采取配置文件。

　　配置式编码其实有利有弊，编码本来可通过开发工具或编译器检查错误，但是过分依赖配置时，就会经常出现因为粗心导致的小错误，如果调试程序出错经常是因为配置文件中小写字母写成大写字母，不知道你是怎么心情？

　　Spring最近还发表了Spring without EJB的书，这倒是说了实话，Spring和EJB其实是相竞争，如同黑与白，如果硬是将两者搭配使用，显得不协调，更不是一些人所谓优化EJB调用的谣言，原因下面将会分析。既然Spring+EJB有缺陷，那么就直接使用Spring+Hibernate架构，但是又带来了新问题：无集群分布式计算性能，只能在一台机器上运行啊，具体分析见：可伸缩性和重/轻量，谁是实用系统的架构主选？

　　下面来分析所谓Spring+EJB的不协调性，正如水和油搅拌在一起使用一样。
　　目前，Spring+EJB有两种应用方式：

　　1. Spring不介入EJB容器，只做Web与EJB之间的接口，这个位置比较尴尬，Web层直接调用EJB的方法比较直接快捷，为什么要中间加个Spring？可实现Web缓存？使用性能更好的AOP框架aspectwerkz啊；实现Web和EJB解耦？这样的工具更多，自己都可以做个小框架实现，就不必打扰背着AOP和IOC双重重担的Spring了吧。

　　2. Spring介入EJB容器，这时，需要在你的ejb-jar.xml中配置beanFactoryPath值指向你为EJB配置的applicationContext.xml，那么你的EJB还需要继承Spring的SimpleRemoteStatelessSessionProxyFactoryBean。

　　好了，现在你的SLSB（无状态Session Bean）成为下面这个样子：

　　void updateUser(){
　　　　
　　　　　　myService.updateUser(); //委托给一个POJO的方法，真正业务逻辑封装在这个POJO中

　　}

　　这样做有很多“优点”，当然最大“优点”是：

　　由于真正业务核心在POJO中实现，因此，只要改一下applicationContext.xml配置，这样，调试时，前台就可以直接调用POJO，不必通过EJB，调试起来方便了，这有一个前提：他们认为调试EJB复杂，其实不然，在JBuilder中，结合Junit，测试EJB如同测试POJO一样方便，这是其他分支，不在此讨论。当部署使用时，再改一下applicationContext.xml配置，指引前台调用到EJB。

　　似乎很巧妙，这里有两个疑问，首先，指引到EJB的改变是什么时候做？持续集成前还是后，在前在后都有问题，这里不仔细分析。

　　这种表面巧妙的优点带来最大的问题是：粗粒度事务机制。所谓粗粒度事务机制，最早见于Petstore的WEB调用EJB Command模式，在这个帖子中有讨论。

　　下面以代码描述什么是粗粒度事务机制：

　　ejb方法：
　　public void updateUser(){
　　　　service.updateUser();
　　}

　　service是一个POJO，具体方法可能是更新两个表：
　　public void updateUser(){
　　　　updateTabel1();//更新table1
　　　　updateTable2(); //更新table2
　　}

　　当updateTable2()抛出异常，updateTable1()是不回滚的。这样，table1中就有一条错误的多余的记录，而table2则没有这条记录。

　　那么，怎么做才能使两个表记录一致，采取事务机制，只有下面这样书写才能实现真正事务：
在EJB方法中写两个方法，因为EJB方法体缺省是一个事务。
　　public void updateUser(){
　　　　updateTabel1();//更新table1
　　　　updateTable2(); //更新table2
　　}

　　关于EJB自动的事务机制，最近也有一个道友做了测试，对于JBoss中容器管理的事务的疑惑。

　　如果你从事关键事务，就是带money相关操作的事务，这种粗粒度机制可能害苦你，那么，似乎有一种办法可弥补事务，不使用EJB容器事务(CMT)，在service中使用Spring的事务机制。

　　如果使用Spring事务机制，业务核心又在POJO中实现，那么我有一个疑问：还要套上EJB干什么？至此，你终于明白，Spring本质是和EJB竞争的，如果硬套上EJB使用，只是相借助其集群分布式功能，而这个正是Spring目前所缺少的。

　　我太惊异Spring精巧的诡异了，他和EJB关系，正如异型和人的关系一样。

　　为了避免你每次使用Spring时想到粘糊糊的异型，不如Spring without EJB，这也正是Spring的初衷，也是它的一个畅销书名。

　　为让初学者更容易掌握Spring，在本站教学区新增一篇“Spring入门速成”，简单易懂，专门针对VIP会员的。

参考文章：

Ioc模式(又称DI：Dependency Injection)

IOC模式的思考和疑问

Ioc容器的革命性优点

Java企业系统架构选择考量

JBoss 5迎来Java的彻底的可配置时代

在这由三部分组成的介绍 Spring 框架的系列文章的第一期中，将开始学习如何用 Spring 技术构建轻量级的、强壮的 J2EE 应用程序。developerWorks 的定期投稿人 Naveen Balani 通过介绍 Spring 框架开始了他由三部分组成的 Spring 系列，其中还将介绍 Spring 面向方面的编程（AOP）和控制反转（IOC）容器。

Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为 J2EE 应用程序开发提供集成的框架。

在这篇由三部分组成的 Spring 系列 的第 1 部分中，我将介绍 Spring 框架。我先从框架底层模型的角度描述该框架的功能，然后将讨论两个最有趣的模块：Spring 面向方面编程（AOP）和控制反转 （IOC） 容器。接着将使用几个示例演示 IOC 容器在典型应用程序用例场景中的应用情况。这些示例还将成为本系列后面部分进行的展开式讨论的基础，在本文的后面部分，将介绍 Spring 框架通过 Spring AOP 实现 AOP 构造的方式。

请参阅 下载，下载 Spring 框架和 Apache Ant，运行本系列的示例应用程序需要它们。

Spring 框架

Spring 框架是一个分层架构，由 7 个定义良好的模块组成。Spring 模块构建在核心容器之上，核心容器定义了创建、配置和管理 bean 的方式，如图 1 所示。

图 1. Spring 框架的 7 个模块

组成 Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下：

• 核心容器：核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC） 模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。
• Spring 上下文：Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、校验和调度功能。
• Spring AOP：通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何对象支持 AOP。Spring AOP 模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。
• Spring DAO：JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向 JDBC 的异常遵从通用的 DAO 异常层次结构。
• Spring ORM：Spring 框架插入了若干个 ORM 框架，从而提供了 ORM 的对象关系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。
• Spring Web 模块：Web 上下文模块建立在应用程序上下文模块之上，为基于 Web 的应用程序提供了上下文。所以，Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。
• Spring MVC 框架：MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText 和 POI。

Spring 框架的功能可以用在任何 J2EE 服务器中，大多数功能也适用于不受管理的环境。Spring 的核心要点是：支持不绑定到特定 J2EE 服务的可重用业务和数据访问对象。毫无疑问，这样的对象可以在不同 J2EE 环境 （Web 或 EJB）、独立应用程序、测试环境之间重用。

回页首

IOC 和 AOP

控制反转模式（也称作依赖性介入）的基本概念是：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。容器 （在 Spring 框架中是 IOC 容器） 负责将这些联系在一起。

在典型的 IOC 场景中，容器创建了所有对象，并设置必要的属性将它们连接在一起，决定什么时间调用方法。下表列出了 IOC 的一个实现模式。

Spring 框架的 IOC 容器采用类型 2 和类型3 实现。

面向方面的编程

面向方面的编程，即 AOP，是一种编程技术，它允许程序员对横切关注点或横切典型的职责分界线的行为（例如日志和事务管理）进行模块化。AOP 的核心构造是方面，它将那些影响多个类的行为封装到可重用的模块中。

AOP 和 IOC 是补充性的技术，它们都运用模块化方式解决企业应用程序开发中的复杂问题。在典型的面向对象开发方式中，可能要将日志记录语句放在所有方法和 Java 类中才能实现日志功能。在 AOP 方式中，可以反过来将日志服务模块化，并以声明的方式将它们应用到需要日志的组件上。当然，优势就是 Java 类不需要知道日志服务的存在，也不需要考虑相关的代码。所以，用 Spring AOP 编写的应用程序代码是松散耦合的。

AOP 的功能完全集成到了 Spring 事务管理、日志和其他各种特性的上下文中。

回页首

IOC 容器

Spring 设计的核心是 org.springframework.beans 包，它的设计目标是与 JavaBean 组件一起使用。这个包通常不是由用户直接使用，而是由服务器将其用作其他多数功能的底层中介。下一个最高级抽象是 BeanFactory 接口，它是工厂设计模式的实现，允许通过名称创建和检索对象。BeanFactory 也可以管理对象之间的关系。

BeanFactory 支持两个对象模型。

• 单态 模型提供了具有特定名称的对象的共享实例，可以在查询时对其进行检索。Singleton 是默认的也是最常用的对象模型。对于无状态服务对象很理想。
• 原型 模型确保每次检索都会创建单独的对象。在每个用户都需要自己的对象时，原型模型最适合。

bean 工厂的概念是 Spring 作为 IOC 容器的基础。IOC 将处理事情的责任从应用程序代码转移到框架。正如我将在下一个示例中演示的那样，Spring 框架使用 JavaBean 属性和配置数据来指出必须设置的依赖关系。

BeanFactory 接口

因为 org.springframework.beans.factory.BeanFactory 是一个简单接口，所以可以针对各种底层存储方法实现。最常用的 BeanFactory 定义是 XmlBeanFactory，它根据 XML 文件中的定义装入 bean，如清单 1 所示。

清单 1. XmlBeanFactory

BeanFactory factory = new XMLBeanFactory(new FileInputSteam("mybean.xml"));

在 XML 文件中定义的 Bean 是被消极加载的，这意味在需要 bean 之前，bean 本身不会被初始化。要从 BeanFactory 检索 bean，只需调用 getBean() 方法，传入将要检索的 bean 的名称即可，如清单 2 所示。

清单 2. getBean()

MyBean mybean = (MyBean) factory.getBean("mybean");

每个 bean 的定义都可以是 POJO （用类名和 JavaBean 初始化属性定义） 或 FactoryBean。FactoryBean 接口为使用 Spring 框架构建的应用程序添加了一个间接的级别。

回页首

IOC 示例

理解控制反转最简单的方式就是看它的实际应用。在对由三部分组成的 Spring 系列 的第 1 部分进行总结时，我使用了一个示例，演示了如何通过 Spring IOC 容器注入应用程序的依赖关系（而不是将它们构建进来）。

我用开启在线信用帐户的用例作为起点。对于该实现，开启信用帐户要求用户与以下服务进行交互：

• 信用级别评定服务，查询用户的信用历史信息。
• 远程信息链接服务，插入客户信息，将客户信息与信用卡和银行信息连接起来，以进行自动借记（如果需要的话）。
• 电子邮件服务，向用户发送有关信用卡状态的电子邮件。

回页首

三个接口

对于这个示例，我假设服务已经存在，理想的情况是用松散耦合的方式把它们集成在一起。以下清单显示了三个服务的应用程序接口。

清单 3. CreditRatingInterface

public interface CreditRatingInterface {
   public boolean getUserCreditHistoryInformation(ICustomer iCustomer);
}

清单 3 所示的信用级别评定接口提供了信用历史信息。它需要一个包含客户信息的 Customer 对象。该接口的实现是由 CreditRating 类提供的。

清单 4. CreditLinkingInterface

public interface CreditLinkingInterface {
public String getUrl();
		public void setUrl(String url);
		public void linkCreditBankAccount() throws Exception ;
}

信用链接接口将信用历史信息与银行信息（如果需要的话）连接在一起，并插入用户的信用卡信息。信用链接接口是一个远程服务，它的查询是通过 getUrl() 方法进行的。URL 由 Spring 框架的 bean 配置机制设置，我稍后会讨论它。该接口的实现是由 CreditLinking 类提供的。

清单 5. EmailInterface

public interface EmailInterface {
      public void sendEmail(ICustomer iCustomer);
      public String getFromEmail();
      public void setFromEmail(String fromEmail) ;
      public String getPassword();
      public void setPassword(String password) ;
      public String getSmtpHost() ;
      public void setSmtpHost(String smtpHost);
      public String getUserId() ;
      public void setUserId(String userId);
   }

EmailInterface 负责向客户发送关于客户信用卡状态的电子邮件。邮件配置参数（例如 SMPT 主机、用户名、口令）由前面提到的 bean 配置机制设置。Email 类提供了该接口的实现。

回页首

Spring 使其保持松散

这些接口就位之后，接下来要考虑的就是如何用松散耦合方式将它们集成在一起。在 清单 6 中可以看到信用卡帐户用例的实现。

注意，所有的 setter 方法都是由 Spring 的配置 bean 实现的。所有的依赖关系 （也就是三个接口）都可以由 Spring 框架用这些 bean 注入。createCreditCardAccount() 方法会用服务去执行其余实现。在 清单 7 中可以看到 Spring 的配置文件。我用箭头突出了这些定义。

回页首

运行应用程序

要运行示例应用程序，首先必须 下载 Spring 框架 及其所有依赖文件。接下来，将框架释放到（比如说）磁盘 c:\，这会创建 C:\spring-framework-1.2-rc2 （适用于当前发行版本） 这样的文件夹。在继续后面的操作之前，还必须下载和释放 Apache Ant。

接下来，将源代码释放到文件夹，例如 c:\ 盘，然后创建 SpringProject。将 Spring 库（即 C:\spring-framework-1.2-rc2\dist 下的 spring.jar 和 C:\spring-framework-1.2-rc2\lib\jakarta-commons 下的 commons-logging.jar）复制到 SpringProject\lib 文件夹中。完成这些工作之后，就有了必需的构建依赖关系集。

打开命令提示符，将当前目录切换到 SpringProject，在命令提示符中输入以下命令：build。

这会构建并运行 CreateCreditAccountClient 类，类的运行将创建 Customer 类对象并填充它，还会调用 CreateCreditCardAccount 类创建并链接信用卡帐户。CreateCreditAccountClient 还会通过 ClassPathXmlApplicationContext 装入 Spring 配置文件。装入 bean 之后，就可以通过 getBean() 方法访问它们了，如清单 8 所示。

清单 8. 装入 Spring 配置文件

ClassPathXmlApplicationContext appContext = 
                    new ClassPathXmlApplicationContext(new String[] {
     "springexample-creditaccount.xml"
    });
CreateCreditCardAccountInterface creditCardAccount = 
                    (CreateCreditCardAccountInterface)
	appContext.getBean("createCreditCard");

回页首

结束语

在这篇由三部分组成的 Spring 系列 的第一篇文章中，我介绍了 Spring 框架的基础。我从讨论组成 Spring 分层架构的 7 个模块开始，然后深入介绍了其中两个模块：Spring AOP 和 IOC 容器。

由于学习的最佳方法是实践，所以我用一个工作示例介绍了 IOC 模式 （像 Spring 的 IOC 容器实现的那样）如何用松散耦合的方式将分散的系统集成在一起。在这个示例中可以看到，将依赖关系或服务注入工作中的信用卡帐户应用程序，要比从头开始构建它们容易得多。

请继续关注这一系列的下一篇文章，我将在这里学习的知识基础上，介绍 Spring AOP 模块如何在企业应用程序中提供持久支持，并让您开始了解 Spring MVC 模块和相关插件。

回页首

下载

	关于下载方法的信息			Get Adobe® Reader®

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 虽然 Spring AOP 提供了独特的优势，但它并不是惟一的 AOP 实现。请参阅“AOP@Work: AOP 工具比较，第 1 部分”（developerWorks，2005 年 2 月），了解 Spring AOP 的构成。
  
  
• 通过“无需容器的对象关系映射”（developerWorks，2004 年 4 月）学习如何用 Hibernate 和 Spring AOP 开发事务性的持久层（persistence layer）。
  
  
• 请从 Spring homepage 下载 Spring 框架。
  
  
• 请从 Ant homepage 下载 Apache Ant。
  
  
• 通过参与 developerWorks blogs 加入 developerWorks 社区。
  
  
• 还请参阅 developerWorks 上的一些丰富的参考资料：
  • Web 架构专区 中的文章专门介绍了各种基于 Web 的解决方案。
  • Developer Bookstore 提供了技术书籍的完整清单，其中包括数百本 Web 相关主题的书籍。
  
  

关于作者

		Naveen Balani 把他的大多数时间都花在了设计和开发基于 J2EE 的框架和产品上。他为 IBM developerWorks 撰写了各种不同的文章，涉及的主题包括：ESB、SOA、JMS、WebServices Architectures、CICS、AXIS、DB2 XML Extender、WebSphere Studio、MQSeries 和 Java Wireless Devices，以及 DB2 Everyplace for Palm、J2ME、MIDP、Java-Nokia、Visual Studio .Net 和无线数据同步。您可以通过 naveenbalani@rediffmail.com 与他联系。

在项目中使用每日构建（ Daily Build ）是为了实现“持续集成”。传统构建只发生在项目发布前夕很短的一段时间，压力和风险不小。每日构建一定程度上缓解了这种压力，削平了曲线。好东西！但每日构建也需项目组的投入，学习和使用 Ant （或 Nant ）就是一个不错的办法。

2. 单元测试（ Unit Test ）

在项目中使用单元测试（ Unit Test ）和每日构建在思想上有相似之处，在实践中又交相呼应。单元测试可以确保每个软件项目最小逻辑部件的正确性。在耦合始终存在的情况下，单元测试的作用其实也被放大了，对某个逻辑部件的测试自然也包括了对所引用其他部件的测试（虽然这并不是单元测试的初衷）。单元测试不是最重要的，但的确是非常重要的和必须的。单元测试也需要项目组的投入，编写单元测试用例是起码的，学习和使用 JUnit （或 Nunit ）能帮上不小的忙。

3. 结合起来（ Do Them All ）

单元测试的最佳实施者是每个开发人员自己，也可以采用同行测试（ Buddy Test ）。他们阅读设计文档，编写单元测试用例、编写逻辑部件，然后把逻辑部件放到测试用例中测试，测试通过就继续往前走。单元测试的发起者是项目组中单个的开发者时，会使得单元测试此起彼伏，但问题是有些单元测试有很多都是无效的。原因很简单，因为不同开发者编写的逻辑部件之间的耦合只要存在，这样的单元测试就是无效的。参考《软件配置管理模式》一书中关于“活动开发线”模式的讲述：当在项目的一条码线（ Code Line ）上，测试与开发在时间上同存时，测试都是无效的，单元测试也不例外。

也许在开发者自行单元测试的同时，我们还应该定时的让所有的开发者都停下来，提交他们的代码，然后一起来进行单元测试。其实这不难，每天下班的时候他们都会自动的停下来，如果项目的配置管理还算可以的话，他们也都会在下班前提交代码，然后让我们来运行单元测试吧。

我们用 Ant 来进行每日构建。同样，我们也可以让 Ant+JUnit 帮助我们进行每日单元测试（ Daily Test ？）。每次听微软的讲师讲 MSF ，都要讲他们的开发是深夜 12:00 开始的，也就是“自动构建 + 自动测试”，第二天早上，开发组的人拿到自动生成的报告，该 code 的就 code ，该 debug 的就 debug 。（其实，这也就是一种测试驱动开发： Test-Driven Development ，又一个很多人争议的软件方法。）这不难，是看公司要不要这么做。

4. 实践（ Practice ）

关于使用 Ant 实现每日构建的请看陋文：“一个轻巧的每日构建解决方案”。

在此基础上，在 Ant 的“ build.xml ”中加入单元测试任务即可，同时也可以生成单元测试报告。甚至可以将单元测试结果报告通过 email 发送给开发组成员。

先请出国内外的几篇好文：

“让编译和测试过程自动化”

“利用 Ant 和 JUnit 进行增量开发”

“每日创建之自动测试”

到今天（ 2004-08-20 ）为止，在 Google 上面以“ ant+junit ”可以搜出 127000 条记录，大家都做得很好。但上面 3 篇的确已经足够帮助还未实作的人快速的实现“每日构建 + 单元测试”了。

关于实践他们都说得很清楚，我也是在看了这些文档后完成实践的。我在自己的 Blog 上加点自己的东西吧，也就是在实现“每日构建 + 单元测试”时的小贴士。

1) 环境配置之<mail> ：

“让编译和测试过程自动化”一文的作者 Erik Hatcher 也是 Ant 的开发者之一。但此文有些早了，文中所提到的 Ant 的<mimemail> 已经合并到<mail> 中，<mimemail> 已经废置不用了。<mail> 任务依赖于 JavaMail 和 JAF ，如果没有用过的话，请到 SUN 公司的网站上下载，并在下载后完成以下配置（以我的目录结构为例）：

CLASSPATH ：

C:\javamail-1.3.2ea\mail.jar;

C:\javamail-1.3.2ea\lib\mailapi.jar;

C:\javamail-1.3.2ea\lib\pop3.jar;

C:\javamail-1.3.2ea\lib\smtp.jar;

C:\jaf-1.0.2\activation.jar;

这样才能保证 Ant 以 email 发送构建和测试报告时的正确。

2) 环境配置之<junit><junitreport> ：

如果项目组在白天用的是 JBuilder ，其中集成了 JUnit 和 Ant 。（建议下载单独的 Ant 和 JUnit ）但当晚上 Ant 调用 JUnit 执行测试任务时，必须保证 ，<junit><junitreport> 能被 Ant 所识别。所以，你要将 JUnit 所属的 3 个 *.jar 文件： src.jar ，junit.jar，junitmail.jar 拷贝到 Ant 的库所在目录（以我的目录结构为例）：

C:\ant\lib

这样才能保证， Ant+JUnit 会为你生成漂亮的 html 格式的测试报告，并发送到你指定的 email 中。

5. 总结（Summary）

讨论了每日构建和单元测试的作用和结合起来使用的理由。配合软件开发配置管理模式提出了供参考的结合方法，并通过实践验证该方案的可行性和简单性。最后和 java 不太熟练的朋友分享了少量经验。

因为当时“每个人”都知道BASIC是给小孩玩的语言，用这种语言只能使你写出非结构化的垃圾代码，然后你的的脑子也会被这种语言变成Camembert产的奶酪（Camembert cheese，法国的一种奶酪，实心，圆饼状，灰色，有一个拳头大小）。所以我们又花了600美元买了一个IBM公司PASCAL语言开发包，需要3张软盘才装的下。PASCAL编译器运行分别需要第一号软盘，和第二号软盘，PASCAL链接器需要第三号软盘。我写了一个简单的输出文字“你好，世界”程序然后编译链接这个程序，总共花了8分钟。

嗯，8分钟好像太长了。我写了一个脚本程序来自动化整个过程，把时间缩减为7.5分钟。这样好一点了。但是我想设计一个可以玩奥赛罗的程序。（译者按：奥赛罗原文为Othello，一种棋类游戏，规则见http://www.ugateways.com/bof4.html）这个游戏总是能打动我。我不得不花很多时间等待编译器编译我的程序。“就是这样的，”一个专业程序员告诉我，“我们通常在办公室里房放上sit-up board（译者按：一种健身器材，可以在上面做仰卧起坐或者有氧操什么的） ，当PASCAL编译器开始运行时，我们就开始锻炼。我这样编程了几个月后，我的身材不要太棒喔！”

后来有一天，丹麦程序员写了一个很灵的叫做Compas Pascal的程序。Philippe Kahn（Borland公司的创始人）买下了它，更名为Borland Turbo Pascal。Turbo Pascal好得简直难以想象，因为它能做IBM Pascal能做的所有事情，但是只要33K内存。而且还额外提供一个编辑器。 这还不是最棒的。最棒的是编译一个小程序只需要不到一秒。这就好比一个你从来没有听说过的公司生产了通用公司别克轿车的克隆版，这种克隆车可以每小时行驶一百万英里，但是只消耗了一滴汽油。一只小小的蚂蚁喝下这点汽油也不会撑死。

突然，我的编程效率变得高的多了

那时我开始明白了“REP循环”（Rep loop）这个概念. REP是“读入，求值，打印（Read, Eval, Print）”的缩写。这个概念解释了Lisp（一种编程语言，用于人工智能）解释器的基本原理：它“读入”你的输入，计算你的输入得到结果，打印结果。下面给一个例子：我输入一些东西，Lisp解释器计算，然后输出结果。

在一个稍微大点的规模上，当你写代码时，你也处于一个REP循环的宏版本中，这个循环就是“编码－编译－测试”。你编写代码，把代码编译成可执行的文件，然后测试它，看一下运行起来怎么样。

关键一点是当你写一个程序时，你的工作过程是循环的。一个循环所花时间越短，你的生产力就越高，当然最短时间不会小于编译器运行的时间。 这就是一个程序员为什么总是要一个真正够快的硬件而编译器开发者们总是不断使他们的编译器运行更快的正式的纯计算机科学角度的原因。Visual Basic的办法是当你输入代码时，它就开始进行代码的语法解析，这样程序解释运行时速度很快。Visual C++的办法是增量编译（incremental compiles），预编译头文件（precompiled headers）和增量链接（incremental linking）。

但是一个大型的团队有多个开发人员和测试人员，你碰到了同样的循环，可能不同点就是有更多的文档要写(可是这还只是草稿，天哪！)。一个测试人员发现了bug并报告，然后开发人员修复了这个bug。那么测试人员得到修正后的代码需要多少时间？在一些软件开发机构，这样的报告－修正－再测试循环（Report-Fix-Retest loop）可能需要几个礼拜。如果一个循环需要这么长的时间，通常意味着该机构生产力很低。想让整个开发过程运转得更平滑一点，你必须想方设法使得报告－修正－再测试循环（Report-Fix-Retest loop）花的时间更少。

一个好的办法是每日构建（daily builds）。 每日构建意味着自动地，每天，完整地构建整个代码树、（译者按：“代码树”，原文为source tree，意思是将整个项目源代码的目录，子目录，文件的位置尽可能事先固定下来，这样在开发过程中各个模块间，各个文件间的相对位置都不会混乱。源代码树指的就是一个项目所有的已经组织好的代码文件。通常代码树应该用版本控制软件管理起来。虽然这个概念很基本，但是据我的观察，国内还是有软件公司在这方面做的不够好的，所以有必要解释一下。）

自动地 － 因为你设定代码每天在固定的时间构建。在Unix环境下使用cron，在windows下使用“任务计划”。

每天 － 或者更频繁. 当然每天构建的次数越多越好啦。但是有时候构建次数还是有上限的，原因和版本控制有关系，等会儿我会谈到的。

完整地 －很可能你的代码有多个版本。多语言版本，多操作系统版本，或者高端低端版本。每日构建（daily build）需要构建所有这些版本。并且每个文件都需要从头编译，而不是使用编译器的不完美的增量编译功能。

以下是每日构建（daily build）能带来的好处：

1. 当一个bug被修正了，测试者可以很快得到最新的修正后的版本开始重新测试，以验证bug是否真正地被修复了。
2. 开发人员可以更加确定他们对代码做的修改不会破坏1024个操作系统上的任何一个版本。验证这一点不需要在他们的机器上安装OS/2（IBM公司生产的PC机操作系统）。
3. 那些每天将修改过的代码导入（check in）版本控制服务器的开发人员知道，他们对一个模块导入的修改不会拖别的开发人员的后腿。拖后腿的意思是，那些开发别的模块的程序员使用这个修改过的模块，出了问题，于是他们自己的模块也没有办法开发下去了。每日构建则不会有人拖后腿。如果把一个开发团队比作一台PC机，那么团队中的一个程序员对某个模块的修改导致其他人无法开发别的模块，相当于PC机发生了蓝屏。当一个程序员忘记把他（她）新建立的文件导入到repository（指版本控制服务器上的代码树）时，这种开发过程中的“蓝屏”会经常发生。因为在这个程序员自己的计算机上有这个文件，所以他（她）构建 这个程序没有问题。但是其他程序员是从版本控制服务器上导出（check out）代码的，由于服务器上没有这个文件，他们遇到了链接错误（link error），无法继续工作了。
4. 外部团队（例如市场销售部门，进行beta测试的一些客户）可以获得一个比较稳定的版本，这样对他们开展自己的工作比较有利。
5. 假如你将每日构建出的二进制文件（例如一个可执行程序，一个dll等等）存档管理，那么当你发现一个非常奇怪的，无法解决的bug时，你可以通过对这些文件进行二进制搜索（binary search）来确定什么时候这个bug第一次出现。如果有对代码进行了完善的版本控制，你也可以找出是谁在何时对代码进行的导入（check in）导致了这个bug。
6. 当开发者修正了测试者报告的一个错误时，如果测试者同时报告了发现错误时的构建的版本，开发人员可以直接在那个版本中测试是否bug真正被修复了。（译者按：测试者报告出现了一个bug，只是报告了一个错误症状，而错误的原因可能有多个，每个原因可能在不同的模块中。前文中的方法是为了避免只修正了一个模块中一个原因，别的模块由于在变动，于是掩盖了而不是修复了bug）

以下是如何进行每日构建（daily build）的具体步骤。你需要用最快的电脑建立一个每日构建服务器。写一个脚本，可以自动从版本控制服务器中导出（check out）完整的代码，（你当然使用版本控制，不是吗？），然后对代码从头开始进行构建（build），要构建所有的版本。如果你有一个安装打包程序，也要在脚本中自动运行。所有会卖给最终用户的东西都要包括在构建过程中。把构建出来的版本放在各自的的目录里，不同时间构建的相同版本也应该按日期整理好，不要相互覆盖。每天固定的时间运行这样的脚本。

• 最关键的是所有这些步骤都应该由脚本自动化完成，从导出（check out）代码到将最终产品放在网上供用户下载（当然在开发阶段，产品是放在一台测试服务器上的）。要保证开发过程中的任何东西的任何记录是由文档记录的而不是由某个人的脑子来记录的，这是唯一的办法。否则你会碰到这样的情况，产品需要发布了，可是只有Shaniqua知道如何将产品打包的，可是他刚刚被巴士撞了。在Juno公司（本文作者工作过的公司之一），要进行每日构建，你唯一需要学会的东西就是双击每日构建服务器桌面上的一个快捷方式。
• 如果你在发行程序的当天发现了一个小bug，没有问题。修正它，然后重新运行每日构建脚本，现在你可以安安心心的发行程序了。当然，黄金定律是每日构建脚本应该是把所有的事情从头做一遍，遵循这个定律就不会有什么问题。
• 将你的编译器的警告参数设到最大（在微软的VC中是-W4 ; 在GCC中是-Wall），当遇到任何一个最微小的警告时就应该停下来。
• 如果每日构建失败了，可能整个开发团队的工作会因此进行不下去。当务之急是立刻找出原因，使得每日构建能成功进行下去。某天也许你会一天运行好几次每日构建脚本的。
• 每日构建一旦失败，应该自动地将失败用email通知整个团队。提取错误日志中的恰当部分并包括在email正文中也不是很难。每日构建脚本也可以将当前的状态报告整理成一个html文件，自动发布到一个所有人都可以访问的web服务器上，这样测试者可以很快知道那个版本的构建是成功的。
• 当我在微软的excel团队中工作时，我们的一个有效办法是，谁导致每日构建（daily build）失败，他（她）就得负责照看当日的每日构建（译者按：微软通常每日构建都在半夜），直到有另一个人导致构建失败而接替他（她）。这样做当然可以使每个开发者都小心不要因为自己代码的错误破坏了构建，更重要的是团队中的每个人都可以学会每日构建（daily build）的原理。
• 如果你的团队在同一个时区工作，在午饭时间进行每日构建（daily build）是个不错的主意。午饭前每个程序员导入（check in）代码，这样当程序员在吃饭时，构建系统在工作。当程序员吃完饭回来时，如果每日构建失败了，所有的人也都在，可以尽快找出失败的原因。当构建系统运作起来时，没有人再会担心别人导入（check in）代码会妨碍自己的工作了。.
• 如果你的团队同时在两个时区工作，计划好每日构建（daily build）的时间使得一个时区的工作不会影响另一个时区的工作。在Juno公司，纽约程序员在晚上7：00导入（check in）到版本控制服务器。如果他们的导入导致构建失败，印度Hyderabad市（译者按：印度科技重镇）的程序员在纽约时间晚上8：00以后的工作几乎无法进行下去。我们每天进行两次每日构建（daily build），每次构建的时间都在两地的程序员回家之前，这下就没有问题了。

更进一步的阅读：

• 一些关于每日构建工具的讨论
• 做每日构建是很重要的，它是 获得高质量代码的12个步骤之一。
• Windows NT team G. Pascal Zachary关于微软Windows NT团队每周构建的书中有一些很有趣的东西。超级明星（译者按：原文为showstopper，指特别受人喜爱，杰出之人或之物）.
• Steve McConnell（译者按：著名的软件工程作家，Win2000开发组总负责人，其名著《Writing Solid Code》，《Debugging the Development Process》都有中文译本。） 写的关于每日构建（daily build）的文章在这里.

通过每日构建或者持续集成，项目组可以及早发现集成问题。现在它的意义已经为众多的开发团队所认识。一些重要问题的处理，如构建版本的分类和提升、与自动测试系统和项目或缺陷管理系统的集成，能够使项目组从中得到更多的收益。本文将对这些方面进行描述，并介绍作为开放源代码构建自动化和管理工具的 luntbuild 在以上方面的努力。

1 ．每日构建和存在的问题

1 ． 1 每日构建的一般机理

如今，每日构建已经在许多项目中得到广泛的应用，以便及早发现集成问题。本文描述了建立每日构建系统中的一些想法，并 介绍开放源代码的每日构建工具 luntbuild （ http://luntbuild.sf.net ）。

每日构建的机理很简单：

1．  定期（如每夜）检查源代码库

2．  如果源代码库中发生改变将触发构建和后续的冒烟测试

3．  给源代码库的当前构建作一个标签，以便将来可以提取当前构建进行重新构建

4．  给相应开发人员发送报告构建情况的 email 。

XP 方法的持续集成风格也具有与每日构建相同的机理

1 ． 2 每日构建存在的问题

如果下列方面能够得到妥善处理，项目组可以从每日构建系统中获得除尽早发现集成问题之外的好处。

1 ．为了给并行开发提供最大程度的构建支持，构建系统应该可以将源代码库中来自不同分支或有不同标签的模块组合起来进行构建。这一点对于大项目的开发尤其重要。

2 ．历史构建应该能够进行很好的管理。在项目开发尤其是持续集成过程中会产生大量的构建版本，因此，应该能够将他们加以分类以确定一些重要的构建。实现的方法有两个：第一个方法是将一个已经存在的低级构建版本（如通过每日构建产生的一个版本）提升进高级构建类（如测试构建类）。由于分类是在构建完成之后进行的，这种方法被称为后构建标识。第二个方法是直接在指定的类中构建。由于构建类是在构建之前就确定了，这种方法被称为前构建标识。除了分类，系统还应该能查找或删除历史构建。系统可以很方便地找到指定版本、日期、状态等的构建，这就能够在大量的历史构建中搜寻而快速地找到指定的构建。通过删除不重要的历史构建，可以节省存储空间。

3 ．当开发大项目时，需要构建记录不仅应该包含最终的分发包，还应该包含一些中间文件或是调试版本文件。因此，构建系统除了替项目组对源代码库进行集成校验外，还提供近期的开发基准或是调试环境。这样，将来可以很方便地通过发出一个命令实现下载特定构建的相关文件并更新开发环境。

4 ．当控制访问不同的项目或者是系统的构建或功能时，特别是系统由多个项目构成或是可以被客户下载的等情况，需要使用访问控制机制进行访问控制。

5 ．每日构建系统必须能够与项目管理、缺陷跟踪系统建立连接，这样才能方便地建立并保持构建和 bug/feature 之间的关系。例如，某开发人员提交一个 bug 给缺陷管理系统申明该 bug 将在下一个构建中改正，当下次构建完成之后构建管理系统将通知缺陷管理系统刚刚完成构建的版本号，从而缺陷跟踪系统能够知道该开发人员刚刚提交的 bug 在哪个版本中被提交。并且，当发布一个特定的版本时，构建系统可以与缺陷管理系统连接以获得本版本处于不同状态的的 bug/feature 列表和描述，并写入 release notes 中。

6 ．每日构建系统必须可以与自动测试系统连接以便在构建完成后除单元测试外的进一步测试。例如，构建系统在生成一个新的构建版本之后将通知自动测试系统，接到通知后，测试系统将下载新的构建版本，将其安装并进行项目跟踪系统所要求的冒烟测试等。

实现以上提到的每日构建系统的各个功能并不象安装一个每日构建系统那么容易。在研究了已有的工具之后，我打算开发一个全新的自动构建工具—— luntbuild ，它可以逐步实现上述功能。当前发布的 1.0.2 版本除了具有每日构建系统或持续集成工具的基本功能之外，还可以实现上述的 1 、 2 、 3 功能。下文将介绍 luntbuild ，解释它在这些方面的功能。

2 ． Luntbuild 如何解决上述问题

Luntbuild 不仅仅是一个每日构建和持续集成工具，而是一个自动构建和管理的系统。它基于 apache ant ，需要存在一个 ant build 脚本。而通过提供一个 ant 脚本封装， ant 脚本的编写会变得十分容易。在用户手册中详细说明了具体步骤。

2.1 对并行开发提供构建支持

Luntbuild 利用项目、视图、模块和计划的概念来自动化和管理构建。项目表示实际的项目以及对应的源代码库。模块表示一组具有版本号的目录以及文件，通常是一个特定分支上或者由特定标签标识的一个源代码目录路径。视图包含若干模块，而项目又包含若干视图。下面举例对此进行说明：

在 luntbuild 中配置一个 cvs 项目“ footbar ”，假定 footbar 包含“ src ”和“ web ”两个目录，“ src ”包含功能源代码而“ web ”包含 web 界面的 html 文件。我们首先创建一个由主分支上的“ src ”和“ web ”模块组成的“ development ”视图，该视图计划每晚构建。开发顺利进行，某日发布了“ foobar-1.0 build123 ”并出售给客户。后来，客户反馈的 bug 与“ src ”目录中代码有关。为了解决这些 bug ，我们在源代码管理系统中为“ src ”目录创建“ 1_0_bugfix ”分支，同时，在 luntbuild 的“ footbar ”项目下创建“ foobar1.0-bugfix ”视图，配置两个模块：“ 1_0_bugfix ”分支上的“ src ”模块，和“ foobar-1_0-build123 ”标签上的“ web ”模块。该视图的构建计划仍然是每天晚上。这样，新功能和改正 bug 的开发工作有单独的视图，并且可以分别按计划进行每日构建。

2.2 对历史构建管理的支持

在 luntbuild 中，计划不仅用于实现自动构建，还用于实现构建分类。计划被创建之后，可以与特定的视图相关联。这种视图 - 计划对被称为“构建计划”或“构建分类”。为了支持多个构建分类，一个视图可以与多个计划相关联。例如，你可以给开发视图关联三个计划：“每小时”、“每晚”和“发布构建”。“每小时”和“每晚”计划将自动被触发，而“发布构建”计划只能手动触发。为了提高构建速度，我们将“每小时”计划配置为增量构建；为了避免源代码库中的标签过多，我们将“每小时”计划的策略选为“不设标签”。“每小时”计划主要为“持续集成”而设置，这样，可以保证源代码库的一致性。为了提高可靠性，我们将“每晚”计划配置为干净构建；为了使所有的夜晚构建可再现，我们将“每晚”计划的策略选为“在构建成功时进行标签”。“每晚”计划为“更新开发环境”而设置，这将用于更新开发人员的开发环境。“发布构建”计划为维护所有已经发布出去的构建而设置，该构建类中的版本可以是手工触发该类中的构建而生成（即构建前标识），或者是采用构建后标识方法将其他构建类（如每晚构建类中的经过测试过的版本）提升到本类中。

除了构建分类和提升， luntbuild 还可以严格或不严格匹配地查找某个版本号的构建，查找指定时间范围、状态或特定构建类中的构建。可以删除查找结果或是特定的构建版本。这样，就可以很方便地执行某些操作比如查找失败的历史构建并删除之。

而且对于某个特定的构建版本，可以删除它下面的文件，或者上传新的文件。从而达到为某个特定的构建版本打补丁的目的。

2.3 对设置最新开发环境的支持

在 luntbuild 中，特定构建版本所发布的文件是由用户提供的构建脚本决定的， luntbuild 仅仅提供一个发布文件的根目录。所以您可以自由选择要在 luntbuild 中发布的文件。对于大项目来说，如果最新的开发环境包（如调试版本文件等）可以与最终分发包一起发布，开发人员就不需要花很长的时间来编译其他开发人员的代码以更新环境，这将带来极大的便利。

2.4 正在开发中的功能

所有的单体测试或冒烟测试应在构建脚本中进行， luntbuild 捕获脚本运行的输出结果，并最终发送给为失败视图负责的开发人员（邮件策略是可以配置的，你可以选择每次构建都发送邮件或是不发送邮件）。将来， luntbuild 会以图形的方式显示测试结果，这会比用原始的日志文件表示得更加清楚。

目前， luntbuild 尚未实现访问控制。当在开放环境中使用 luntbuild 时，访问控制功能具有重要的意义，因此，现在正在设计这个功能，在日后发布的版本中将会实现。

Luntbuild 尚不能与第三方项目管理 / 缺陷跟踪系统或是自动测试系统连接。这项功能将在日后发布的版本中实现。第一步是提供 web-service 类 API ，使其他系统可以方便地访问 luntbuild 构建信息。

协同是关键

从开发环境到版本控制，你常常会走过又一个循环：采购工具，使用培训，围绕着工具使用建立内部开发过程，日常应用等等。希望在合同到期时能够顺利完成并且没有超支...

让我们来问这样一个问题：下一步是什么？

在你让开发小组提高了一点点效率之后，在你配置了开发工具之后，你仍然需要保持竞争力，下一步改善那里能够获得最大的生产力？

我们要求你看一下目前你周围的信息组织，你一定能看到不同的开发小组，同时你也能够发现其它许多技术上的协作者，如文档、外部资源、客户、设计人员等等。你将发现不同的开发小组的数量在增加，麻烦也在增加。你还能发现合作者分散在不同的部门或不同的地方。

当你看到这一切时，相信你会认识到项目组织中存在的噪音和混乱带来了沉重的经济负担。你将意识到这是下一步提高生产力的突破点，不是其它的技术工具，也不是下一个更快的编译器。

下一个效益增长点将来自管理，简化技术协作，使不同的小组以一种更快速而简单的方式共享工作中的相关信息，从而降低“项目组织中的噪音”，而且使优秀的小组不会被拖住后腿。换句话说，你的下一个效益增长点将来自实现你的信息组织中所有成员之间的协同工作。

“我只需要版本控制，或许是软件配置管理... 何必要协同呢？”

获得协同的动机依赖于企业内信息组织的个体：应用开发组（如上图中的Tom），应用开发管理（如Ann）和技术协作者（如文档、帮助平台和客户等等），他们参与不同的软件活动，所以会有各自的看法。

例如，让我们考虑一下Tom，作为软件开发组长，他可能在应用开发和维护领域有特长，因此自然会倾向于采用专门技术，如版本控制等。那么Tom是否需要技术协作？

从哪儿提高生产力

版本控制和软件配置管理通过加强日常开发环境的控制，很快得到了大家的认可。但是它们能进一步提高生产力吗？

许多已经使用了版本控制和软件配置管理工具和软件组织，很快发现生产力的提高比预期的要低，下面列出了其中一些原因：

考虑到上述因素，很明显Tom肯定会对技术协作发生兴趣：

• 建立在版本控制和软件配置管理之上，提供对信息技术资源的准确访问。
• 通过无缝访问不同的版本控制工具促进代码共享。
• 从任何地方访问（LAN/WAN/Internet/WEB），改善已有的版本控制工具
• 从其它平台（通过统一的JAVA客户端），扩展垮平台的代码共享和重用。
• 提供一个具有高度伸缩性的现代化体系结构，使得将工具扩展到其它领域和功能范畴成为可能。

StarTeam满足所有上述需求，它具有：

• 与PVCS和SourceSafe的互操作性，
• 完全的地理位置独立性，
• 客户/服务器体系结构，为Internet和WAN开发环境特别优化，
• 能够运行在任何JAVA平台上的统一的客户端应用。

更重要的是，StarTeam支持开发队伍建立一个协同工作的稳固基础的需要。

队伍中的其它部分怎么办？

我的需求还未满足：我要求所有的项目组能够协调工作！我要求他们能够共享和重用，不管他们用什么样的版本控制工具，并且我需要能够完全有关联性地访问技术上的协作者，即使他们可能并不是技术方面的。

迄今为止，Tom已有了他所需要的版本控制和软件配置管理工具，如StarTeam Versions、 PVCS或Visual SourceSafe等。

但这仍然无法解决团队中其它人员的需要，如Ann。这些需要是：

• 项目组之间的协同：
Tom、John和Mary使用不同的工具，他们之间在代码共享和重用上有一定的困难。
• 系统资源的公共访问，而不管使用哪个版本数据库。像PVCS和SourceSafe这样的配置管理工具都是很专门的，使用不同的术语和操作。因此，你可能需要访问John和Mary使用的两种完全不同的系统。
• 需要支持位于不同地点的项目组成员，而且可能是动态变化的，比如你需要在用户现场干一段。
• 快速、直观地访问开发相关的内容，包括文档、计划、外部资源、管理、帮助平台和客户等不具有“软件开发头脑”的对象。除非选择一个非常容易使用、高度集成和直观的解决方案，否则要将技术协作集成到开发功能中几乎是不可能的。

因此，单纯的技术工具与期望尚有一段距离。版本控制和软件配置管理是不可缺少的工具（否则如何安全地管理信息技术财富？），但它们不是设计成用于解决协同工作需要的。

协同将他们结合在一起

一个真正的协同解决方案支持所有的功能范畴和团队，无论他们是处在传统软件开发环境之内还是之外。

StarTeam提供了真正的协同工作，使得开发环境内外的所有的功能范畴和团队能够积极参与共同的活动。协同自底向上建立：底层是安全地控制和管理信息技术财富，上层是协同：

• 版本控制和配置管理功能没有这一关键的功能。
• 透明的跨引擎（不同的工具）互操作性。
• 一个提供访问你的所有软件资源的协同框架。
• 允许已有的用户继续使用其版本控制工具的能力，保护已有的投资。
• 完全的位置独立性。
• 平台独立性（LAN/WAN/Internet/WEB）。
• 一个获奖的、非常容易使用的图形用户界面，非技术性用户也能应付自如。
• 文件、交流和变化请求等所有应用资源之间的关联。
• 虚拟的信息资源视图，允许每个项目成员将信息资源看作只与自己有关，并支持直观的进度、生命周期状态、产品版本、基线版本和私有配置。
• 完全集成的变化请求管理，集成在一个更高、更有意义的层次上。

你可以发现，这些额外的功能特性并不仅仅提供了对软件配置管理的支持。更重要的是，在软件配置管理的基础上建立技术协同。

StarTeam所提供的协同能力，能够真正提高生产力并取得竞争优势：所有成员主动合作和共享相关资源，实现更快、更好的目标。

总之，StarTeam是一个真正的技术协同解决方案。

从里到外建立协同。

所有的协同工具都有一个共同的目标：允许一起工作的人们快速有效地共享关联信息。这样就容易确定专业范围，并使在公共领域中的交流更方便。

因此，技术和事务协同解决方案适合于建立一个公共的、易于实现的工作人员协同工作的环境。

但是，技术和事务协同在一下三方面有重要差别：

使用的技术财富：事务协同的对象是办公文档和文件，而技术协同的对象是软件财富。
• 核心人员：事务协同将办公人员集合在一起；技术协同的首要也是最重要的目的是解决软件开发人员（包括管理和技术合作者）的需求。
• 使用的关联信息的复杂性：技术协同必须共享高度复杂的关联信息，其中这些关系不是立即显现的，也不会包含所有的交流内容（即交谈内容必须能被以后的合作者多次访问）。而事务合作更有时效性，简单的关联和短期的交流。

  版本控制和配置管理基础

  由于技术协同要求安全可靠、可审核以及有效地访问企业的关键应用，它必须建立在强大的版本控制和配置管理上...一个事务文件通常随着版本发展，而应用部件必须是可以在时间上游动的，即能够支持频繁的回溯和修订。

  进一步，技术协同必须与开发人员日常使用的工具和环境紧密集成在一起。

  特别支持软件开发

  除非软件开发小组利用技术协同系统，否则所有的协同将会停止在与信息组织的其余部分分隔开来的地方。这就是StarTeam为什么提供扩展的开发支持功能的原因，如差异比较、可视化合并、版本标签（version labeling）、审核印迹（audit trails）、表示阶段的虚拟视图、时间游动事例（time-travel instances）和私有对象等等。

  信息关联的表达和共享

  为了支持复杂关联信息的共享和重用，技术协同工具必须能够做到：

  • 适当地表示关系，通过一个通用化的链接引擎支持所有在协同信息库中跟踪的对象之间的扩展链接。StarTeam将这种链接扩充到文件、版本、变化请求和会话。
  • 支持同一个数据库的多虚拟视图，因此每一个功能范围都能够“看到”与之有关的关联内容。StarTeam通过最先进的虚拟视图支持这种需求，从协同环境的所有对象中虚拟选择，从而实现生命周期阶段化、时间游动、调试、私有视图和其它许多功能。
  • 不断积累应用开发中产生的知识，使得诸如文档、帮助平台、质量保证人员等等能够快速有效地共享这些知识，而不会额外增加沟通成本。

因此，技术协同加强了“同心环”之间的合作，从开发环境向外扩展到： 技术协同 程序管理办公室（PMO） 项目管理功能（PM） 下面我们将看到，这些不同的功能组的需求是有差别的，但是它们都有一个共同的目标－技术协同。

开发需求

产品化的信息库：StarTeam提供一个可伸缩、成熟的信息库，完全面向对象，版本化所有的对象（包括文件、目录、视图和变化请求），完全支持多重实体关系。StarTeam信息库使用了扩展的行业标准，如ODBC、COM、JAVA beans和Active-X等等。
 
• 真正的客户/服务器体系结构：基于文件系统的工具（如PVCS和SourceSafe）很难有效地运行在WAN、Internet或WEB环境中，因为其性能是难以接受的。
   
• WAN/WEB优化：StarTeam特别针对WAN、Internet和WEB进行了优化，增强了诸多特性，如加密、压缩、增量式提交（即只提交差异部分而不是这个文件）、数据库的远程同步（无需传输所有相关的文件）等等。
   
• 可视化配置管理：特别方便使用，且功能强大，允许开发人员以一种可视化和直观的方式定义任何数量的数据库切片，支持分阶段、“时间游动”和调试。
   
• 所有信息库对象之间的通用化链接：用户自然地用关系表示上下文相关的内容，而与其他开发人员共享这些关联内容对他们的工作来说是至关重要的。StarTeam支持对这种关系的要求，跨所有对象类型（文件、版本、会话和变化请求等）的通用化链接简便易用。
   
• 功能集成：为什么开发人员不得不使用两个单独的应用：一个制作变化，另一个跟踪这些变化和外部变化请求之间的关系？StarTeam在一个高效率的用户界面下集成了所有这些功能。
   
• 易于使用：屡获殊荣的StarTeam图形用户界面是一个高效率、直观、使用方便的开发环境。
   
• 与开发工具集成：StarTeam与所有主流的开发工具集成。同时，StarTeam提供应用接口开发的能力（通过COM和JAVA beans）。
   
• 与其它配置管理软件的透明互操作：如果你的开发队伍已经使用了其它版本控制工具，如PVCS和 SourceSafe，StarTeam保护和继承你当前的工作和投资，你可以在一个用户界面下透明地使用三个产品的版本档案（单独或通过StarTeam）。这不是导入/导出功能，这是完全的透明互操作！

技术协同

作为一个例子，让我们考虑WEB应用开发：JAVA开发人员如何能够没有说明文档、设计人员、手册编写人员等的密切协同？

如果不能满足下列关键需求，则这些技术协同将不能发挥作用：

非常容易使用：传统的开发工具需要大量的使用培训。而让管理人员去上课是乎有些困难。
• 熟悉文件管理界面：用于存取文件夹、文件和任何其它对象的界面应该与Windows资源管理器相似，绝大多数合作者都会使用它。
• 地理位置独立：管理人员和开发人员都可能分布在不同的地方，或临时变动工作地点，但他们都需要随时访问有关系统。
• 直接的关联导航：StarTeam的多向链接能给技术协同者带来巨大的好处，因为链接提供了一个容易跟随、直观的导航机制，轻松访问与特定对象关联的文件、变化请求和会话等。
• 线索化的会话：在开发和维护过程中，StarTeam用线索化的会话的形式保持日常的活动和决定，用户将从中积累大量有价值的知识，这些知识库可以直接被其它技术协同者访问。

程序管理办公室（PMO）

在大型项目中，经常需要一个程序办公室，是管理这个应用的中心。

根据行业专家的研究报告，如果不使用集中的记录数据库，程序办公室将无法开展工作，集中数据库中所有受影响的对象会被跟踪。

StarTeam 2000是StarTeam Professional的一个特别版本，增加了以上功能，提供对依从跟踪系统（Compliance Tracking System）的综合支持。

CTS变成了建立记录数据库的理想工具，通过与StarTeam的集成，将数字化财富、依从工作及其在软件部件上的表示形成了一个闭环。

项目管理功能

开发环境处理文件、变化和资源，项目管理针对任务、工作分配、依赖关系和时间。

尽管有许多项目管理产品，如Microsoft Project，但通常都不能很好地支持开发项目，因为跟踪制作变化的时间、执行它们所用的资源和更新贯穿整个生命周期的项目信息需要很高的开销。

这是很不幸的，因为开发人员确实希望从项目管理功能中获得好处，并且因为诸如应用软件这样关键的财富游离于项目管理框架之外。

要提高团队生产力，必须将项目管理功能与开发环境集成在一起。集成必须能够：

• 支持任务，任务是一个完全激活的对象，用于关联资源、变化请求 、工作分配和变化。
• 完全集成任务对象与开发信息库中维护的其它对象。
• 支持项目模板，因此任务和工作分配能够自动应用到相似的项目中。
• 开发信息库和MS Project引擎之间透明、双向的数据更新。

StarBase支持上述功能，为你提供了一个完整的应用开发项目管理解决方案。

协同的所有原理是－自底向上。即从低层的服务到高层次的协同功能。

首先，协同提供的最基本的服务是产品化的、成熟的版本控制和软件配置管理。因为协同是建立在应用财富之上的，它们必须被安全地管理、审查、保护和版本化。

StarTeam提供的版本控制引擎支持典型的软件开发事务，如文件差异分析和合并、版本标签、建立支持和文件管理等等。

StarTeam的版本控制引擎与Oracle、Symantec、Allaire、Haht Software等其它许多软件公司提供的版本控制工具是一样的。

共同访问信息技术财富

多少年来，开发队伍已经使用版本控制保护其信息技术财富。因此，当在开发小组之间实现协同时，你将发现开发小组会逐渐抛弃传统的版本控制工具。

StarTeam是唯一能保护你的版本控制工具投资的这种产品，提供与其它版本控制工具（如PVCS和SourceSafe）的透明互操作。不仅是导入/导出功能：完全的真实的互操作。即用户A可以使用SourceSafe建立一个文件的版本，用户B使用StarTeam，那么任一用户都可以通过SourceSafe和StarTeam访问自己或他人的版本。

协同框架

在版本控制引擎互操作之上，StarTeam建立了它最重要的功能层：协同框架。StarTeam这一独特的体系结构，是建立世界级产品的基础。

该功能层的技术描述是：强壮的，可伸缩的，基于标准的，面向对象的信息数据库，完全版本化的，支持多向通用化链接。用通俗的话来说就是，协同框架是StarTeam允许所有团队成员快速有效地进行协同工作的功能性（表示和共享关联信息）。

协同框架提供：

从任何地方进行安全有效的访问：StarTeam是一个客户/服务器产品，针对宽带和窄带连接进行了优化设计。用户能够使用下列方式访问PVCS、SourceSafe和StarTeam版本库：
• 运行在LAN、WAN或TCP/IP连接（如Internet）上的StarTeam客户端应用。
• 运行在任何JAVA平台并连接在LAN、WAN或Internet上的StarTeam JAVA客户端。
• 一个标准的浏览器，不需要装入插件程序和JAVA小程序。
   
• 获奖的易于使用的图形用户界面：StarTeam已经多次被专家和用户一致评定为软件配置管理类中最容易使用的产品。无论你是开发人员或是不懂版本控制的技术协同者，都可以立即学会使用StarTeam，并且其功能性将会给你留下深刻的影响。
   
• 直观的文件管理界面：StarTeam让你通过熟悉的Windows风格访问项目中的文件目录结构。你可以在许多文件夹中使用相同的文件名：StarTeam使用的文件和版本名字没有限制，这与Windows环境不同（许多基于文件相同的工具是有限制的）。
   
• 通用化链接引擎：StarTeam数据库中所有的对象，无论文件、版本、变化请求或会话，都可以被任意链接，以表示它们之间逻辑和/或物理关系中包含的关联信息。你要想了解一个对象的上下文关系，只需跟着链接走。
   
• 可视化配置管理：定义信息库的虚拟视图的能力对用户来说总是有吸引力的，但通常在高端的SCM工具中才会有。StarTeam实现了这一特性并且更进一步，包括用户界面的所有可视化元素。StarTeam用户能够可视化定义和维护虚拟视图实现隔离应用场合、阶段化（例如开发、测试、集成和产品等）、对应用过去的任何精确的日期和时间的时间游动、执行增量式调试等等。

协同框架中的所有功能可应用于信息库中的所有对象、建立在其上的任何生产力模块以及任何与StarTeam通讯的应用。

标准接口

StarTeam基于标准的集成接口层能够扩展信息数据库的功能性。它提供了从任何使用COM或JAVA Beans的应用完全存取所有信息库对象的能力。因此用Visual Basic、JAVA以及COM或JAVA兼容的语言编写的应用都能存取StarTeam中保存的版本、变化请求、会话、任务或其它任何对象。想象一下这样的可能性，将自己内部开发的应用和第三方的软件包集成在一个保存有你的信息技术财富的透明的信息库中，不管它们是在StarTeam还是在SourceSafe数据库中，这不是很美妙吗？

生产力模块

生产力模块是集成的部件，它增加了对象定义和功能性，如变化请求管理、会话、任务管理等等。

生产力模块自动集成到StarTeam的用户界面。要在StarTeam客户端应用中实现一个新对象只要有一个动态连接库.DLL即可。将一个.DLL拿走，与该特殊对象（如变化请求）有关的所有功能性将立即从用户界面上消失。

这一独特、最先进的对象集成技术是StarTeam强大的协同框架体系和信息数据库实现的副产品。

集成自己的应用

前面描述的基于标准的集成，同样适用于你自己内部开发的应用，可以用VB或任何COM或JAVA Beans兼容的语言实现。

集成多厂家的应用

互操作层让版本控制引擎协同工作，协同框架使用户合作。同样，标准接口层实现技术的协同。

StarTeam正在推出StarPartner软件合作伙伴策略，通过StarTeam SDK，保证其它技术能够利用StarTeam生产力模块同样的机制使用产品信息数据库的服务。

StarTeam是目前唯一的企业级协同解决方案。

StarTeam是一个集成的解决方案，为企业信息组织中从开发人员到项目管理人员的所有成员带来了好处。

这一革命性的解决方案事实上正在成为标准。许多全球性的大型企业正在采用StarTeam，通过建立跨团队、跨部门、跨专业的协同工作，提高应用队伍的效率。

---　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

--　　-分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

--　　-经理觉得奇怪：“我不是刚告诉你我的需求了吗？”

--　　-分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”

--　　-经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

---　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

---　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”

---　　风险躲在需求的迷雾之后

-　　--以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

--　　-拨开需求分析的迷雾

---　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：

--　-·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

---　·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

---　·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

--　-·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

---　·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

---　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

---　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

---　经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

---　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

---　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

---　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

--　-客户的需求观

--　-客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

---　1、 分析人员要使用符合客户语言习惯的表达

---　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

---　2、分析人员要了解客户的业务及目标

---　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s

---　3、 分析人员必须编写软件需求报告

---　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

---　4、 要求得到需求工作结果的解释说明

---　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

---　5、 开发人员要尊重客户的意见

---　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

---　6、 开发人员要对需求及产品实施提出建议和解决方案

---　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

---　7、 描述产品使用特性

---　客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

---　8、 允许重用已有的软件组件

---　需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

---　9、 要求对变更的代价提供真实可靠的评估

---　有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

---　10、 获得满足客户功能和质量要求的系统

---　每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

---　11、 给分析人员讲解您的业务

---　分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

---　12、 抽出时间清楚地说明并完善需求

---　客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

---　13、 准确而详细地说明需求

---　编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

---　在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

---　14、 及时作出决定

---　分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

---　15、 尊重开发人员的需求可行性及成本评估

---　所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

---　16、 划分需求的优先级

---　绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

---　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

---　17、 评审需求文档和原型

---　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。

---　更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

---　18、 需求变更要立即联系

---　不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

---　19、 遵照开发小组处理需求变更的过程

---　为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

---　20、 尊重开发人员采用的需求分析过程

---　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

---　“需求确认”意味着什么

---　在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

---　这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

---　同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

---　这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

---　对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。

---　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。

JavaServer Pages（JSP）是用于 J2EE 平台的标准表示层技术。JSP 技术提供了用于执行计算（这些计算用来动态地生成页面内容）的脚本编制元素和操作。脚本编制元素允许在 JSP 页面中包括程序源代码，在为响应用户请求而呈现页面时可以执行这些源代码。操作将计算操作封装到很象 HTML 或 XML 标记的标记中，JSP 页面的模板文本通常包含这些标记。JSP 规范只将几种操作定义成了标准，但从 JSP 1.1 开始，开发人员已经能够以定制标记库的方式创建其自己的操作了。

JSP 标准标记库（JSTL）是 JSP 1.2 定制标记库集，这些标记库实现大量服务器端 Java 应用程序常用的基本功能。通过为典型表示层任务（如数据格式化和迭代或条件内容）提供标准实现，JSTL 使 JSP 作者可以专注于特定于应用程序的开发需求，而不是为这些通用操作“另起炉灶”。

当然，您可以使用 JSP 脚本编制元素（scriptlet、表达式和声明）来实现此类任务。例如，可以使用三个 scriptlet 实现条件内容，清单 1 中着重显示了这三个 scriptlet。但是，因为脚本编制元素依赖于在页面中嵌入程序源代码（通常是 Java 代码），所以对于使用这些脚本编制元素的 JSP 页面，其软件维护任务的复杂度大大增加了。例如，清单 1 中的 scriptlet 示例严格地依赖于花括号的正确匹配。如果不经意间引入了一个语法错误，则条件内容中的嵌套其它 scriptlet 可能会造成严重破坏，并且在 JSP 容器编译该页面时，要使所产生的错误信息有意义可能会很困难。

												
														<% if (user.getRole() == "member")) { %>
    <p>Welcome, member!</p>
<% } else { %>
    <p>Welcome, guest!</p>
<% } %>
												
										

修正此类问题通常需要相当丰富的编程经验。尽管通常会由十分精通页面布局和图形设计的设计人员来开发和维护 JSP，但是同一页面中的脚本编制元素出现问题时，需要程序员的介入。这种状况将单个文件中代码的责任分担给多人，因而使得开发、调试和增强此类 JSP 页面成为很麻烦的任务。通过将常用功能包装到定制标记库的标准集合中，JSTL 使 JSP 作者可以减少对编制脚本元素的需求，甚至可以不需要它们，并避免了相关的维护成本。

JSTL 1.0

JSTL 1.0 发布于 2002 年 6 月，由四个定制标记库（ core 、 format 、 xml 和 sql ）和一对通用标记库验证器（ ScriptFreeTLV 和 PermittedTaglibsTLV ）组成。 core 标记库提供了定制操作，通过限制了作用域的变量管理数据，以及执行页面内容的迭代和条件操作。它还提供了用来生成和操作 URL 的标记。顾名思义， format 标记库定义了用来格式化数据（尤其是数字和日期）的操作。它还支持使用本地化资源束进行 JSP 页面的国际化。 xml 库包含一些标记，这些标记用来操作通过 XML 表示的数据，而 sql 库定义了用来查询关系数据库的操作。

两个 JSTL 标记库验证器允许开发人员在其 JSP 应用程序中强制使用编码标准。可以配置 ScriptFreeTLV 验证器以在 JSP 页面中禁用各种类型的 JSP 脚本元素 ― scriptlet、表达式和声明。类似地， PermittedTaglibsTLV 验证器可以用来限制可能由应用程序的 JSP 页面访问的定制标记库集（包括 JSTL 标记库）。

尽管 JSTL 最终将会成为 J2EE 平台的必需组件，但目前只有少数应用程序服务器包括它。JSTL 1.0 的参考实现可作为 Apache 软件基金会（Apache Software Foundation）的 Jakarta Taglibs 项目（请参阅 参考资料）的一部分而获得。可以将该参考实现中的定制标记库合并到任何支持 JSP 1.2 和 Servlet 2.3 规范的服务器，以添加对 JSTL 的支持。

表达式语言

在 JSP 1.2 中，可以使用静态字符串或表达式（如果允许的话）指定 JSP 操作的属性。例如，在清单 2 中，对 <jsp:setProperty> 操作的 name 和 property 属性指定了静态值，而用表达式指定了其 value 属性。这个操作的效果是将请求参数的当前值赋予命名的 bean 特性。以这种形式使用的表达式被称为 请求时属性值（request-time attribute value），这是构建到 JSP 规范中的用于动态指定属性值的唯一机制。

												
														<jsp:setProperty name="user" property="timezonePref"
                 value='<%= request.getParameter("timezone") %>'/>

												
										

因为请求时属性值是用表达式指定的，所以它们往往有和其它脚本元素一样的软件维护问题。因此，JSTL 定制标记支持另一种用于指定动态属性值的机制。可以用简化的 表达式语言（EL）而不使用完整的 JSP 表达式来指定 JSTL 操作的属性值。EL 提供了一些标识符、存取器和运算符，用来检索和操作驻留在 JSP 容器中的数据。EL 在某种程度上以 EcmaScript（请参阅 参考资料）和 XML 路径语言（XML Path Language，XPath）为基础，因此页面设计人员和程序员都应该熟悉它的语法。EL 擅长寻找对象及其特性，然后对它们执行简单操作；它不是编程语言，甚至不是脚本编制语言。但是，与 JSTL 标记一起使用时，它就能使用简单而又方便的符号来表示复杂的行为。EL 表达式的格式是这样的：用美元符号（$）定界，内容包括在花括号（{}）中，如清单 3 所示。

												
														<c:out value="${user.firstName}"/>

												
										

此外，您可以将多个表达式与静态文本组合在一起以通过字符串并置来构造动态属性值，如清单 4 所示。单独的表达式由标识符、存取器、文字和运算符组成。标识符用来引用存储在数据中心中的数据对象。EL 有 11 个保留标识符，对应于 11 个 EL 隐式对象。假定所有其它标识符都引用 限制了作用域的变量。存取器用来检索对象的特性或集合的元素。文字表示固定的值 ― 数字、字符、字符串、布尔型或空值。运算符允许对数据和文字进行组合以及比较。

												
														<c:out value="Hello ${user.firstName} ${user.lastName}"/>

												
										

限制了作用域的变量

JSP API 通过 <jsp:useBean> 操作允许从 JSP 容器内的四个不同作用域中存储和检索数据。JSTL 通过提供用于指定和除去这些作用域中的对象的附加操作来扩展这一能力。此外，EL 提供将这些对象作为限制了作用域的变量进行检索的内置支持。特别地，任何出现在 EL 表达式中但不对应于任何 EL 隐式对象的标识符，都被自动假定为引用存储在四个 JSP 作用域的其中某个中的对象，这四个作用域是：

• 页面作用域
• 请求作用域
• 会话作用域
• 应用程序作用域

您可能还记得，只有在为特定请求处理页面期间才能检索存储在该页面作用域中的对象。如果对象是存储在请求作用域中的，可以在处理所有参与处理某请求的页面期间检索这些对象（譬如在对某个请求的处理中遇到了一个或多个 <jsp:include> 或 <jsp:forward> 操作）。如果对象是存储在会话作用域中的，则在与 Web 应用程序的交互式会话期间，可以由用户访问的任何页面检索它（即，直到与该用户交互相关联的 HttpSession 对象无效为止）。可以由任何用户从任何页面访问存储在应用程序作用域中的对象，直到卸载 Web 应用程序本身为止（通常是由于关闭 JSP 容器所致）。

通过将字符串映射为期望作用域中的对象来将对象存储到该作用域。然后，就可以通过提供相同字符串来从该作用域检索该对象。在作用域的映射中查找字符串，并返回被映射的对象。在 Servlet API 中，将此类对象称为相应作用域的 属性。但是，在 EL 的上下文中，也将与属性相关联的字符串看作变量的名称，该变量通过属性映射的方式获得特定的值。

在 EL 中，与隐式对象无关联的标识符被认为是存储在四个 JSP 作用域中的名称对象。首先对页面作用域检查是否存在这样的标识符，其次对请求作用域、然后对会话作用域、最后对应用程序作用域依次进行这样的检查，然后测试该标识符的名称是否与存储在该作用域中的某个对象的名称匹配。第一个这样的匹配作为 EL 标识符的值被返回。通过这种方法，可以将 EL 标识符看作引用限制了作用域的变量。

从更技术的方面来说，没有映射到隐式对象的标识符是用 PageContext 实例的 findAttribute() 方法求值的，该实例表示对页面的处理，在该页面上，当前正在处理用于请求的表达式。标识符的名称作为参数传递给这个方法，然后该方法依次在四个作用域中搜索具有相同名称的属性。并将所找到的第一个匹配项作为 findAttribute() 方法的值返回。如果未在这四个作用域中找到这样的属性，则返回 null 。

最终，限制了作用域的变量是四个 JSP 作用域的属性，这些属性具有可以用作 EL 标识符的名称。只要对限制了作用域的变量赋予由字母数字组成的名称，就可以通过 JSP 中提供的用于设置属性的任何机制来创建它们。这包括内置的 <jsp:useBean> 操作，以及由 Servlet API 中的几个类定义的 setAttribute() 方法。此外，四个 JSTL 库中定义的许多定制标记本身就能够设置作为限制了作用域的变量使用的属性值。

隐式对象

表 1 中列出了 11 个 EL 隐式对象的标识符。不要将这些对象与 JSP 隐式对象（一共只有九个）混淆，其中只有一个对象是它们所共有的。

表 1. EL 隐式对象

尽管 JSP 和 EL 隐式对象中只有一个公共对象（ pageContext ），但通过 EL 也可以访问其它 JSP 隐式对象。原因是 pageContext 拥有访问所有其它八个 JSP 隐式对象的特性。实际上，这是将它包括在 EL 隐式对象中的主要理由。

其余所有 EL 隐式对象都是映射，可以用来查找对应于名称的对象。前四个映射表示先前讨论的各种属性作用域。可以用它们来查找特定作用域中的标识符，而不用依赖于 EL 在缺省情况下使用的顺序查找过程。

接下来的四个映射用来获取请求参数和请求头的值。因为 HTTP 协议允许请求参数和请求头具有多个值，所以它们各有一对映射。每对中的第一个映射返回请求参数或头的主要值，通常是恰巧在实际请求中首先指定的那个值。每对中第二个映射允许检索参数或头的所有值。这些映射中的键是参数或头的名称，但这些值是 String 对象的数组，其中的每个元素都是单一参数值或头值。

cookie 隐式对象提供了对由请求设置的 cookie 名称的访问。这个对象将所有与请求相关联的 cookie 名称映射到表示那些 cookie 特性的 Cookie 对象。

最后一个 EL 隐式对象 initParam 是一个映射，它储存与 Web 应用程序相关联的所有上下文的初始化参数的名称和值。初始化参数是通过 web.xml 部署描述符文件指定的，该文件位于应用程序的 WEB-INF 目录中。

存取器

因为 EL 标识符是作为隐式对象或限制了作用域的变量（通过属性来实现）解析的，因此有必要将它们转换成 Java 对象。EL 可以自动包装和解包其相应的 Java 类中的基本类型（例如，可以在后台将 int 强制转换成 Integer 类，反之亦可），但大多数的标识符将成为指向完整的 Java 对象的指针。

结果是，对这些对象的特性或（在对象是数组和集合的情况下）对其元素的访问通常是令人满意的。就为了实现这种用途，EL 提供了两种不同的存取器（点运算符（ . ）和方括号运算符（ [] ）），也支持通过 EL 操作特性和元素。

点运算符通常用于访问对象的特性。例如，在表达式 ${user.firstName} 中，使用点运算符来访问 user 标识符所引用对象的名为 firstName 的特性。EL 使用 Java bean 约定访问对象特性，因此必须定义这个特性的 getter 方法（通常是名为 getFirstName() 的方法），以便表达式正确求值。当被访问的特性本身是对象时，可以递归地应用点运算符。例如，如果我们虚构的 user 对象有一个实现为 Java 对象的 address 特性，那么也可以用点运算符来访问这个对象的特性。例如，表达式 ${user.address.city} 将会返回这个地址对象嵌套的 city 特性。

方括号运算符用来检索数组和集合的元素。在数组和有序集合（也即，实现了 java.util.List 接口的集合）的情况下，把要检索的元素的下标放在方括号中。例如，表达式 ${urls[3]} 返回 urls 标识符所引用的数组或集合的第四个元素（和 Java 语言以及 JavaScript 中一样，EL 中的下标是从零开始的）。

对于实现 java.util.Map 接口的集合，方括号运算符使用关联的键查找存储在映射中的值。在方括号中指定键，并将相应的值作为表达式的值返回。例如，表达式 ${commands["dir"]} 返回与 commands 标识符所引用的 Map 中的 "dir" 键相关联的值。

对于上述两种情况，都可允许表达式出现在方括号中。对嵌套表达式求值的结果将被作为下标或键，用来检索集合或数组的适当元素。和点运算符一样，方括号运算符也可以递归应用。这使得 EL 能够从多维数组、嵌套集合或两者的任意组合中检索元素。此外，点运算符和方括号运算符还可以互操作。例如，如果数组的元素本身是对象，则可以使用方括号运算符来检索该数组的元素，并结合点运算符来检索该元素的一个特性（例如 ${urls[3].protocol} ）。

假定 EL 充当指定动态属性值的简化语言，EL 存取器有一个有趣的功能（与 Java 语言的存取器不同），那就是它们在应用于 null 时不抛出异常。如果应用 EL 存取器的对象（例如， ${foo.bar} 和 ${foo["bar"]} 中的 foo 标识符）是 null ，那么应用存取器的结果也是 null 。事实证明，在大多数情况下，这是一个相当有用的行为，不久您就会了解这一点。

最后，点运算符和方括号运算符可能实现某种程度的互换。例如，也可以使用 ${user["firstName"]} 来检索 user 对象的 firstName 特性，正如可以用 ${commands.dir} 获取与 commands 映射中的 "dir" 键相关联的值一样。

运算符

EL 还可以通过使用标识符和存取器，遍历包含应用程序数据（通过限制了作用域的变量公开）或关于环境的信息（通过 EL 隐式对象）的对象层次结构。但是，只是访问这些数据，通常不足以实现许多 JSP 应用程序所需的表示逻辑。

最终，EL 还包括了几个用来操作和比较 EL 表达式所访问数据的运算符。表 2 中汇总了这些运算符。

表 2. EL 运算符

算术运算符支持数值的加法、减法、乘法和除法。还提供了一个求余运算符。注：除法和求余运算符都有替代的、非符号的名称（为的是与 XPath 保持一致）。清单 5 中显示了一个演示算术运算符用法的示例表达式。对几个 EL 表达式应用算术运算符的结果是将该算术运算符应用于这些表达式返回的数值所得的结果。

												
														${item.price * (1 + taxRate[user.address.zipcode])}

												
										

关系运算符允许比较数字或文本数据。比较的结果作为布尔值返回。逻辑运算符允许合并布尔值，返回新的布尔值。因此，可以将 EL 逻辑运算符应用于嵌套的关系或逻辑运算符的结果，如清单 6 所示。

												
														${(x >= min) && (x <= max)}

												
										

最后一种 EL 运算符是 empty ，它对于验证数据特别有用。 empty 运算符采用单个表达式作为其变量（也即， ${empty input} ），并返回一个布尔值，该布尔值表示对表达式求值的结果是不是“空”值。求值结果为 null 的表达式被认为是空，即无元素的集合或数组。如果参数是对长度为零的 String 求值所得的结果，则 empty 运算符也将返回 true 。

表 3 显示了 EL 运算符的优先级。正如清单 5 和 6 所示，可以用圆括号对表达式分组，高于普通的优先级规则。

表 3. EL 运算符优先级（自顶到底，从左到右）

文字

在 EL 表达式中，数字、字符串、布尔值和 null 都可以被指定为文字值。字符串可以用单引号或双引号定界。布尔值被指定为 true 和 false 。

Taglib 伪指令

正如我们先前讨论的，JSTL 1.0 包括四个定制标记库。为了演示 JSTL 标记和表达式语言的交互，我们将研究几个来自 JSTL core 库的标记。和使用任何 JSP 定制标记库一样，必须在您想要使用这个库标记的任何页面中包括 taglib 伪指令。清单 7 显示了用于这个特定库的伪指令。

												
														<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>

												
										

实际上，对应于 JSTL core 库的 taglib 伪指令有两种，因为在 JSTL 1.0 中，EL 是可选的。所有四个 JSTL 1.0 定制标记库都有使用 JSP 表达式（而不是 EL）指定动态属性值的备用版本。因为这些备用库依赖于 JSP 的更传统的请求时属性值，所以它们被称为 RT库，而那些使用表达式语言的则被称为 EL 库。开发人员用不同的 taglib 伪指令来区分每个库的这两个版本。清单 8 显示了使用 core 库的 RT 版本的伪指令。但是，由于现在我们讨论的重点是 EL，所以首先需要这些伪指令。

												
														<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c_rt" %>

												
										

变量标记

我们首先要考虑的 JSTL 定制标记是 <c:set> 操作。正如已经说明的，限制了作用域的变量在 JSTL 中起关键作用， <c:set> 操作提供基于标记的机制来创建和设置限制了作用域的变量。清单 9 中显示了该操作的语法，其中 var 属性指定了限制了作用域的变量的名称， scope 属性表明了该变量驻留在哪个作用域中， value 属性指定了分配给该变量的值。如果指定变量已经存在，则简单地将所指明的值赋给它。如果不存在，则创建新的限制了作用域的变量，并用该值初始化这个变量。

												
														<c:set var="
        name" scope="
        scope" value="
        expression"/>

      
												
										

scope 属性是可选的，其缺省值是 page 。

清单 10 中显示了 <c:set> 的两个示例。在第一个示例中，将会话作用域变量设置成 String 值。在第二个示例中，用表达式来设置数值：将页面作用域内名为 square 的变量赋值为名为 x 的请求参数的值的平方。

												
														<c:set var="timezone" scope="session" value="CST"/>
<c:set var="square" value="${param['x'] * param['x']}"/>

												
										

您还可以将限制了作用域的变量的值指定为 <c:set> 操作的主体内容，而不是使用属性。使用这种方法，您可以重新编写清单 10 中的第一个示例，如清单 11 所示。此外，正如我们马上可以看到的， <c:set> 标记的主体内容本身也可以使用定制标记。 <c:set> 主体内生成的所有内容都将作为一个 String 值赋给指定变量。

												
														<c:set var="timezone" scope="session">CST</c:set>

												
										

JSTL core 库包含第二个用于管理限制了作用域的变量的标记 ― <c:remove> 。顾名思义， <c:remove> 操作是用来删除限制了作用域的变量的，它获取两个属性。 var 属性指定待删除变量的名称， scope 属性是可选的，它表示待删除变量来自哪个作用域，缺省为 page ，如清单 12 所示。

												
														<c:remove var="timezone" scope="session"/>

												
										

输出

尽管 <c:set> 操作允许将表达式结果赋给限制了作用域的变量，但开发人员通常会希望只显示表达式的值，而不存储它。JSTL <c:out> 定制标记承担这一任务，其语法如清单 13 所示。该标记对由其 value 属性指定的表达式进行求值，然后打印结果。如果指定了可选属性 default ，那么，在对 value 属性的表达式求值所得结果为 null 或空 String 的情况下， <c:out> 将打印其值。

												
														<c:out value="
        expression" default="
        expression" escapeXml="
        boolean"/>

      
												
										

escapeXml 属性也是可选的。它控制当用 <c:out> 标记输出诸如“<”、“>”和“&”之类的字符（在 HTML 和 XML 中具有特殊意义）时是否应该进行转义。如果将 escapeXml 设置为 true，则会自动将这些字符转换成相应的 XML 实体（此处提到的字符分别转换成 < 、 > 和 & ）。

例如，假定有一个名为 user 的会话作用域变量，它是一个类的实例，该类为用户定义了两个特性： username 和 company 。每当用户访问站点时，这个对象被自动分配给会话，但直到用户实际登录后，才会设置这两个特性。假定是这种方案，请考虑清单 14 中的 JSP 片段。在用户登录之后，这个片段将显示单词“Hello”，其后是他／她的用户名和一个惊叹号。但是，在用户登录之前，由这个片段生成的内容则是短语“Hello Guest!”。在这种情况下，因为 username 特性还有待初始化，所以 <c:out> 标记将转而打印出 default 属性的值（即字符串“Guest”）。

												
														Hello <c:out value="${user.username}" default=="Guest"/>!

												
										

接下来，考虑清单 15，它使用了 <c:out> 标记的 escapeXml 属性。如果在这种情况下已经将 company 特性设置成 Java String 值 "Flynn & Sons" ，那么，实际上该操作生成的内容将是 Flynn & Sons 。如果这个操作是生成 HTML 或 XML 内容的 JSP 页面的一部分，那么，这个字符串中间的“&”符号最终可能被解释为 HTML 或 XML 控制字符，从而妨碍了对该内容的显示或解析。但是，如果将 escapeXml 属性值设置成 true ，则所生成的内容将是 Flynn & Sons 。浏览器或解析器不会因在解释时遇到这种内容而出问题。假定 HTML 和 XML 是 JSP 应用程序中最常见的内容类型，所以 escapeXml 属性的缺省值是 true 就不足为奇了。

												
														<c:out value="${user.company}" escapeXml=="false"/>

												
										

用缺省值设置变量

除了简化动态数据的显示之外，当通过 <c:set> 设置变量值时， <c:out> 指定缺省值的能力也很有用。正如 清单 11 所示，用来赋给限制了作用域的变量的值可以指定为 <c:set> 标记的主体内容，也可以通过其值属性来指定。通过将 <c:out> 操作嵌套在 <c:set> 标记的主体内容中，变量赋值就可以利用其缺省值能力。

清单 16 中说明了这种方法。外部 <c:set> 标记的行为非常简单：它根据其主体内容设置会话作用域 timezone 变量的值。但是，在这种情况下，主体内容是通过 <c:out> 操作生成的。这个嵌套操作的值属性是表达式 ${cookie['tzPref'].value} ，它尝试通过 cookie 隐式对象返回名为 tzPref 的 cookie 值。（ cookie 隐式对象将 cookie 名称映射到相应的 Cookie 实例，这意味着必须通过对象的 value 特性使用点运算符来检索储存在 cookie 中的实际数据。）

												
														<c:set var="timezone" scope=="session">
   <c:out value="${cookie['tzPref'].value}" default=="CST"/>
</c:set>

												
										

但是，请考虑以下情况，用户是第一次尝试使用这段代码的 Web 应用程序。结果是，请求中没有提供名为 tzPref 的 cookie。这意味着使用隐式对象的查找将返回 null ，在这种情况下整个表达式将返回 null 。因为对 <c:out> 标记的 value 属性求值的结果是 null ，所以 <c:out> 标记会转而输出对其 default 属性求值的结果。在这里是字符串 CST 。因此，实际的结果是将 timezone 限制了作用域的变量设置成用户的 tzPref cookie 中存储的时区，或者，如果没有，则使用缺省时区 CST 。

EL 和 JSP 2.0 目前，表达式语言仅可用于指定 JSTL 定制标记中的动态属性值。但 JSTL 1.0 表达式语言的一个扩展已经被提出，会把它包括到 JSP 2.0 中去，眼下正在进行最后评审。这个扩展将允许开发人员通过自己的定制标记来使用 EL。页面作者将可以在目前允许使用 JSP 表达式的任何地方使用 EL 表达式，譬如将动态值插入模板文本中： <p>Your preferred time zone is ${timezone}</p> 。 这个 JSP 2.0 功能（就象 JSTL 本身一样）将支持页面作者进一步减少对 JSP 编制脚本元素的依赖，从而改进 JSP 应用程序的可维护性。

回页首

结束语

EL（与四个 JSTL 定制标记库提供的操作结合起来）允许页面作者不使用脚本元素即可实现表示层逻辑。例如，对比本文开头 清单 1 中的 JSP 代码和清单 17 中显示的通过 JSTL 实现的同样功能。（JSTL core 库中其余的标记，包括 <c:choose> 及其子标记，将在本系列的下一篇文章中讨论。）尽管显然执行了条件逻辑，但是 JSTL 版本中没有 Java 语言源代码，并且标记之间的关系（尤其是关于嵌套需求）对于任何精通 HTML 语法的人都应该是熟悉的。

												
														<c:choose><c:when test="${user.role == 'member'}">
    <p>Welcome, member!</p>
  </c:when><c:otherwise>
    <p>Welcome, guest!</p>
  </c:otherwise></c:choose>
												
										

通过提供大多数 Web 应用程序常用功能的标准实现，JSTL 有助于加速开发周期。与 EL 结合起来，JSTL 可以不需要对表示层程序编写代码，这极大地简化了 JSP 应用程序的维护。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• Sun 的 JSP 标准标记库主页是了解关于 JSTL 的更多信息的良好起点。
  
  
  
• JSTL 1.0 规范 是关于 EL 和四个 JSTL 标记库的最终权威文本。
  
  
  
• Jakarta Taglibs 项目是 JSTL 1.0 参考实现的起源。
  
  
  
• Shawn Bayern 所著的 JSTL in Action（Manning Publications Co.，2002 年）提供了对所有 JSTL 功能的精彩论述，作者是该参考实现的领导。
  
  
  
• David Geary 是 Java 技术方面很受欢迎的作者，他也写了一本关于 JSTL 的书，书名是 Core JSTL。
  
  
  
• JSPTags.com 是 JSP 技术参考资料的目录，它尤其专注于定制标记库。
  
  
  
• Sun 的 Java Web Services Tutorial中包含了对 JSTL 的讨论。
  
  
  
• “ Using JSPs and custom tags within VisualAge for Java and WebSphere Studio”（ WebSphere 开发者园地）是一篇 WBOnline 实用论文，它演示了 servlet、JSP 和定制标记库的使用。
  
  
  
• 通过 Jeff Wilson 精彩的文章“ 使用定制标记控制 JSP 页面”（ developerWorks，2002 年 1 月）了解关于定制标记库的一切。
  
  
  
• Noel Bergman 的文章“ JSP 标记库：着意设计的更好的可用性”（ developerWorks，2001 年 12 月）向您展示了声明性标记是如何帮助提高 JSP 页面的可用性的。
  
  
  
• 有关 EcmaScript 的更多详细信息，请参阅 Sing Li 的“ 快速上手 Java 编程”（ developerWorks，2001 年 7 月）。
  
  
  
• 在 developerWorksJava 技术专区 可以找到多达数百篇的 Java 技术参考资料。
  

此翻译稿很大一部分内容出自国内出现的那个先前版本，我只是对新加入的几项进行了翻译，并且对我熟悉的产品项着重介绍了一下，以后我会抽时间收集文中提到AJAX工具相关的文章，尽量将内容介绍和功能点评做到全面详细点。所以请关注和准备用AJAX做开发的朋友关注这篇文章，我会时常更新的。原文因为是由一个wiki系统维护，所以在所难免出现参差不齐，风格上也有不统一的情况，翻译时我也是参照原文原封不动的挪了过来，以后我会抽时间改良下。

翻译正文

基于浏览器的应用框架一般分为两种：

• Aplication frameworks:提供了浏览器功能，但其最著名的还是在于通过窗口生成组件建立桌面GUI。
• Infrastructural frameworks:提供基本的框架功能和轻便式浏览器端操作，让开发者去创建具体应用，主要功能包括：
  • 基于XMLHttpRequest组件的浏览器交互功能
  • XML解析和操作功能
  • 根据XMLHttpRequest的返回信息进行相应的DOM操作
  • 一些特殊情况下，和其他的浏览器端技术如Flash（或Java Applets）等集合到一起应用

• HTML/JS Generation(HTML/JS生成)：通过服务器端生成HTML和JS代码在传递给浏览器端进行直接运行
• 远程交互：JavaScript调用服务器端函数(例如调用Java函数)并返回给JavaScript的回调句柄，或者请求服务器端数据信息，例如Session信息，数据库查询等。

目录