hk

计算机思维Computational Thinking

作者： OneEyeWolf∣来源：BlogJava∣原文地址∣2006-7-16

走下神坛的项目经理

　　以下的问题，谁看谁解答：
　　１、很多招聘项目经理的信息上，无异例外的提到：风险控制，以目前国内的开发现状，风险控制是项目经理的责任吗？ 你做到了吗
　　２、对于进度控制，项目工具、理论教条、计划、报告、经验的作用有多大，孰重孰轻，到底是什么是进度控制中的决定性因素。
　　３、性格决定命运，项目经理的人格魅力，亲和力，沟通技巧是不是项目成败的关键因素？
　　４、项目经理真的能掌控一切吗，遇到低素质的开发人员，性格怪异的程序员，桀骜不驯的程序员，你真的能搞定他吗，遇到啥也不懂的老总，遇到胡搅蛮缠的客户，怎么去搞定他们。
　　５、不懂技术，也能带好团队吗？能做好一个项目吗，至少我没有见过这样的案例。
　　６、项目经理如何能摆脱写作的海洋，要写计划，写需求分析，写进度报告，写设计记录，写会议记录，写考评记录，写....。文档真的就能提高项目质量吗，文档之与开发效率是提高，还是降低？你喜欢做这样的项目经理吗？
　　７、项目经理在开发期间需不需要写程序？，是审查文档，还是审核代码，需不需要考评（我工作这几年，经历N个公司，考评都流与形式，即浪费了时间，又没有效果，希望能有人给出明灯，照亮迷途）。
　　８、如果你到了一个新开张的公司开始了第一个新项目，没有测试部门，没有质量管理，没有规范，没有制度，没有企业文化，没有项目积累，团队需要你自己招兵买马（薪资不会很高，中间还有人跑掉），老总又不懂技术，你怎么来带好这个项目？
　　９、如果团队中没有一个懂得敏捷开发，指望看书，查资料，能应用到项目中去吗？
１０、如果新来一个软件学院的硕士，来做你们公司的开发部经理，天天都是软件工程，敏捷开发，测试驱动，RUP，IOC，你们怎样面对这样的开发经理？
　　１１、现在招聘项目经理的条件上，都附上了敏捷开发，RUP等，不懂这些，就不能管理好一个项目吗？

　　
　　程序员总是骂项目经理，他们人多呀，没办法，他们在人群中高呼，项目经理要爱护程序员，如何去爱护，相爱也难呀，人都是犯贱，你越是给他个好脸，他越不知道自己是谁，什么是都讲究个度，这是最难把握的。

　　领导老是说，要关心下属，了解他们的能力和缺点、性格与心理，一天就８个小时，十几人的团队，项目经理又不是８爪鱼，又不是心理学家，能做多少事呢。
　　
　　项目经理能辞退一个人吗，不能，
　　能选择一个团队吗，不能，
　 　能主动要求公司给骨干成员加薪吗，不能（很多人动不动拿这涨薪资来作为项目经理管理的一条必做的内容，我觉得瞎扯淡，可能吗，薪资结构是公司的上层建 筑，不可动摇，就算动了，也是毛毛雨，我们公司一个骨干，能力很强，在一次工程中，很努力，吃了很多的苦，结束后，公司主动给他涨了２００块钱，他觉得是 一种侮辱，就BYE　BYE　了，太失败了）
　　如果在项目进展过程中掌握项目成员情况或平息人民内部矛盾就要多沟通，就要搞活动，请吃饭， 公司不补贴的话，就要自己放血（我自己家里还一大堆人民内部矛盾呢），老总在和我谈话时，总是说要多请他们吃吃钣，唱唱K，我都想抽他。一次两次可以，多 了我也不愿意，做人不能伪大方，最失败的是总见我请别人吃饭，没有请我吃饭。
　　项目成员要求上班有学习看书的时间，我觉得是扯淡，总不能让我一个人扛着，你们看书吧？我自己已经多长时间没有看书了，我也记不清楚了。
　　谁没有受过进度上的逼迫，有几个人能做好呢，项目经理不压程序员压谁，总不能被上头骂完后，跟没事的，还乐呵呵的请大家吃饭吧。
　　有人说项目经理要有骨气，要敢于说不，有几个呢，再说公司接个单也不容易，好不容易来个单，你又搞个一年半载才出来一个beta版，还被客户骂了半死。

　　我觉得大家都应当把自己的项目，自己的公司的，实情都说出来，不要讲一些书上才能看到的东西，撇开虚伪，敞开胸脯让大家来分析。

　　我对我们公司成员（包括我自己）的现状大体分析如下，可能有主观成分，大家仁者见仁：

１、并不认同公司的发展，混日子，你要说不想干了就走，他马上拿起包就走，没有一点留恋
２、热衷技术，有一定的软件工程基础，能够参与项目管理决策，能够对自己的分配任务给出合理的时间表（这种人真的很少，论坛中多，现实中少，现在是蓝领泛滥的社会）
３、普通的人，只能写代码，对于别人的事情，就是别人的事情，参与度不高，不愿意多做一项工作，９点钟来，６点钟走（太多了）
４、 对于自己的任务，并不能给出合理的估计与时间表，如果让他做估计，常常是延期完成的，这时，你需要自己去帮他做，如果延误了，你需要要帮助他解决问题，批 评与指责，告状，解决不了任何的问题。（比较多，很多项目经理对于进度，众口一词的说，把任务分解后，让成员来估计，是不是这样呢，他自己都不知道，估计 什么呀！）
５、有困难也不说，死鳖一样，什么也不说，解决不了，就放在那儿，也不反映，如果需求或设计中有错误，知道错了，也不说，就按错的来。（有这样的人，当然不多，谁遇到谁倒霉）
６、有的人，完不成任务，总是一大堆理由，你想批评他一句，他能回十句，烦都烦死了
７、缺乏团队精神的人，别人犯了错，如果影响到自己就大声的骂，如果没有影响到自己，就嘲笑。背后搞鬼搞怪。自己出了错，就隐瞒，害怕别人指出自己的错误，不承认犯错，脸红脖子粗的跟你没有完没了。
８、刚毕业的人，脑子灵巧，基础不扎实，知道一点东西，就不知天高地厚，贪玩，写出来的代码功能虽然实现了，但跟大便差不多，看了都想吐。没有团队精神，没有价值观（公司薪资不高，就只能这样的人，需要加功夫培训雕琢）
９、 传说中的项目经理：有一个平常心的，知道自己缺点不足，不充大，不自大，不吹毛求疵，真正在做项目管理的项目经理，能够真正理解和掌控整个项目进程的管理 者（很少，连基本功能都没做扎实呢，却整天抓这个布局不好，那个颜色不好看，这个类命名不符合规范，程序员说完成了，他就认为完成了，整天只会问这个功能 你需要多长时间完成，那个功能需要多少时间完成，程序员拍胸脯说９天，他就向上面拍胸脯是９天，到底需不需要９天，谁也说不清楚，９天过后完不成了，除了 继续做下去也没折）

得出结论：一只高素质而且有着非长高的向心力的开发团队是传说中才能出现的。

作为公司一个PM，能做的事是非常非常有限的，谁有能力去撼动一个公司的企业文化呢，在百十号人的公司里说句话，有人能深情的看你一眼呢？再说了公司不发展，总不能自己也不发展吧，所以只能离开，去寻找党组织了。到底什么时候才能找到党组织？

都是例子，很容易懂

[转贴]
Java很诱人，但对于刚跨入Java门槛的初学者来说，编译并运行一个无比简单的Java程序简直就是一个恶梦。明明程序没错，但各种各样让人摸不着头脑的错误信息真的让你百思不得其解，许多在Java门口徘徊了很久的初学者就这样放弃了学习Java的机会，很是可惜。笔者也经历过这个无比痛苦的阶段，感觉到编译难的问题就出在classpath的设置及对package的理解之上。本文以实例的方式，逐一解决在编译过程中所出现的各种 classpath的设置问题。本文实例运行的环境是在Windows XP + JDK 1.5.0。对其他的环境，读者应该很容易进行相应的转换。

1. 下载并安装JDK1.5.0，并按默认路径，安装到C:\Program Files\Java\jdk1.5.0中。

2. 用鼠标单击WindowsXP的“开始”->“运行”，在弹出的运行窗口中输入cmd，按确定或回车，打开一个命令行窗口。

3. 在命令行中输入：

java

有一列长长的洋文滚了出来，这是JDK告诉我们java这个命令的使用方法。其中隐含了一个重要信息，即JDK安装成功，可以在命令行中使用java此命令了。

4. 在命令行中输入

javac

屏幕显示：

"javac"不是内部或外部命令，也不是可运行的程序或批处理文件。

这是由于windows找不到javac这个命令的原因。这就不明白了，java与javac都是JDK在同一个子目录里面的两个文件，为什么可以直接运行 java而不能直接运行javac呢？原来，Sun公司为了方便大家在安装完JDK后马上就可以运行Java类文件，在后台悄悄地将java命令加入了 Path的搜索路径中，因此我们可以直接运行java命令(但我们是看不到它到底是在哪设置的，无论是在用户的Path或系统的Path设置中均找不到这个java存放的路径)。但Sun所做的到此为止，其他JDK的命令，一概不管，需要由用户自己添加到搜索路径中。

5. 既然如此，那我们自己添加Path的搜索路径吧。对“我的电脑”按右键，选“属性”，在“系统属性”窗口中选“高级”标签，再按“环境变量”按钮，弹出一个“环境变量”的窗口，在用户变量中新建一个变量，变量名为“Path”，变量值为"C:\Program Files\Java\jdk1.5.0\bin;%PATH%"。最后的%PATH%的意思是说，保留原有的Path设置，且将目前的Path设置新加到其前面。一路按“确定”退出(共有3次)。关掉原来的命令行窗口，依照第2步，重新打开一个新的命令行窗口。在此窗口中输入

javac

长长的洋文又出现了，这回是介绍javac的用法。设置成功。

6. So far so good. 到目前为止，我们已经可以编程了。但是，这不是一个好办法。因为随着以后我们深入学习Java，我们就会用到JUnit、Ant或NetBeans等应用工具，这些工具在安装时，都需要一个名为指向JDK路径的“JAVA_HOME”的环境变量，否则就安装不了。因此，我们需要改进第5步，为以后作好准备。依照第5步，弹出“环境变量”的窗口，在用户变量中新建一个变量，变量名为“JAVA_HOME”，变量值为"C:\Program Files\Java\jdk1.5.0"。注意，这里的变量值只到jdk1.5.0，不能延伸到bin中。确定后，返回“环境变量”的窗口，双击我们原先设定的Path变量，将其值修改为“%JAVA_HOME%\bin;%PATH%”。这种效果与第5步是完全一样的，只不过多了一个 JAVA_HOME的变量。这样，以后当我们需要指向JDK的路径时，只需要加入“%JAVA_HOME%”就行了。至此，Path路径全部设置完毕。一路确定退出，打开新的命令行窗口，输入

javac

如果长长的洋文出现，Path已经设置正确，一切正常。如果不是，请仔细检查本步骤是否完全设置正确。

7. 开始编程。在C盘的根目录中新建一个子目录，名为“JavaTest”，以作为存放Java源代码的地方。打开XP中的记事本，先将其保存到 JavaTest文件夹中，在“文件名”文本框中输入"Hello.java"。注意，在文件名的前后各加上一个双引号，否则，记事本就会将其存为 "Hello.java.txt"的文本文件。然后输入以下代码：

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

再次保存文件。

8. 在命令行窗口中输入

cd C:\JavaTest

将当前路径转入JavaTest中。然后，输入

javac Hello.java

JDK 就在JavaTest文件夹中编译生成一个Hello.class的类文件。如果出现“1 error”或“XX errors”的字样，说明是源代码的输入有误，请根据出错提示，仔细地按第7步的代码找出并修正错误。请读者注意甄别代码输入有误的问题与 classpath设置有误的问题。因为本文是关于如何正确设置classpath及package的，因此，这里假设读者输入的代码准确无误。到目前为此，由于我们是在源代码的当前路径下编译，因此，不会出现classpath设置有误的问题。

9. 在命令行窗口中输入

java Hello

屏幕出现了

Hello world

成功了，我们已经顺利地编译及运行了第一个Java程序。
但是，第8步及第9步是不完美的，因为我们是在JavaTest这个存放源码的文件夹中进行编译及运行的，因此，一些非常重要的问题并没有暴露出来。实际上，第8步的“javac Hello.java”及第9步的“java Hello”涉及到两个问题，一是操作系统如何寻找“javac”及“java”等命令，二是操作系统如何寻找“Hello.java”及 “Hello.class”这些用户自己创建的文件。对于“javac”及“java”等命令，由于它们均是可执行文件，操作系统就会依据我们在第6步中设置好的Path路径中去寻找。而对于“Hello.java”及“Hello.class”这些文件，Path的设置不起作用。由于我们是在当前工作路径中工作，java及javac会在当前工作路径中寻找相应的java文件(class文件的寻找比较特殊，详见第11步)，
因此一切正常。下面我们开始人为地将问题复杂化，在非当前工作路径中编译及运行，看看结果如何。

10. 在命令行窗口中输入

cd C:\
转入到C盘根目录上，当前路径离开了存放源码的工作区。输入

javac Hello.java

屏幕出现：

error: cannot read: Hello.java
1 error

找不到Hello.java了。我们要给它指定一个路径，告诉它到C:\JavaTest去找Hello.java文件。输入

javac C:\JavaTest\Hello.java

OK，这回不报错了，编译成功。

11. 输入

java C:\JavaTest\Hello

这回屏幕出现：

Exception in thread "main" java.lang.NoClassDefFoundError: C:\JavaTest\Hello

意思为在“C:\JavaTest\Hello”找不到类的定义。明明C:\JavaTest\Hello是一个.class文件，为什么就找不到呢？原来，Java对待.java文件与.class文件是有区别的。对.java文件可以直接指定路径给它，而java命令所需的.class文件不能出现扩展名，也不能指定额外的路径给它。

那么，如何指定路径呢？对于Java所需的.class文件，必须通过classpath来指定。

12. 依照第5步，弹出“环境变量”窗口，在用户变量中新建一个变量，变量名为“classpath”，变量值为"C:\JavaTest"。一路按“确定”退出。关闭原命令行窗口，打开新的命令行窗口，输入

java Hello

“Hello world”出来了。由此可见，在“环境变量”窗口中设置classpath的目的就是告诉JDK，到哪里去寻找.class文件。这种方法一旦设置好，以后每次运行java或javac时，在需要调用.class文件时，JDK都会自动地来到这里寻找。因此，这是一个全局性的设置。

13. 除了这种在环境变量”窗口中设置classpath的方法之外，还有另一种方法，即在java命令后面加上一个选项classpath，紧跟着不带扩展名的class文件名。例如，

java -classpath C:\JavaTest Hello

JDK 遇到这种情况时，先根据命令行中的classpath选项中指定的路径去寻找.class文件，找不到时再到全局的classpath环境变量中去寻找。这种情况下，即使是没有设置全局的classpath环境变量，由于已经在命令行中正确地指定类路径，也可以运行。

为了在下面的例子中更好地演示classpath的问题，我们先将全局的classpath环境变量删除，而在必要时代之以命令行选项-classpath。弹出“环境变量”窗口，选中“classpath”的变量名，按“删除”键。

此外，java命令中还可以用cp，即classpath的缩写来代替classpath，如java -cp C:\JavaTest Hello。特别注意的是，JDK 1.5.0之前，javac命令不能用cp来代替classpath，而只能用classpath。而在JDK 1.5.0中，java及javac都可以使用cp及classpath。因此，为保持一致，建议一概使用classpath作为选项名称。

14. 我们再次人为地复杂化问题。关闭正在编辑Hello.java的记事本，然后将JavaTest文件夹名称改为带空格的“Java Test”。在命令行中输入

javac C:\Java Test\Hello.java

长长的洋文又出来了，但这回却是报错了：

javac: invalid flag: C:\Java

JDK将带有空格的C:\Java Test分隔为两部分"C:\Java"及"Test\Hello.java"，并将C:\Java视作为一个无效的选项了。这种情况下，我们需要将整个路径都加上双引号，即

javac "C:\Java Test\Hello.java"

这回JDK知道，引号里面的是一个完整的路径，因此就不会报错了。同样，对java命令也需要如此，即

java -classpath "C:\Java Test" Hello

对于长文件名及中文的文件夹，XP下面可以不加双引号。但一般来说，加双引号不容易出错，也容易理解，因此，建议在classpath选项中使用双引号。

15. 我们再来看.java文件使用了其他类的情况。在C:\Java Test中新建一个Person.java文件，内容如下：

public class Person {
private String name;

public Person(String name) {
this.name = name;
}

public String getName() {
return name;
}
}

然后，修改Hello.java，内容如下：

public class Hello {
public static void main(String[] args) {
Person person = new Person("Mike");
System.out.println(person.getName());
}
}

在命令行输入

javac "C:\Java Test\Hello.java"

错误来了：

C:\Java Test\Hello.java:3: cannot find symbol
symbol: class Person

JDK 提示找不到Person类。为什么javac "C:\Java Test\Hello.java"在第14步中可行，而在这里却不行了呢？第14步中的Hello.java文件并没有用来其他类，因此，JDK不需要去寻找其他类，而到了这里，我们修改了Hello.java，让其使用了一个Person类。根据第11步，我们需要告诉JDK，到哪里去找所用到的类，即使这个被使用的类就与Hello.java一起，同在C:\Java Test下面！输入

javac -classpath "C:\Java Test" "C:\Java Test\Hello.java"

编译通过，JDK在C:\Java Test文件夹下同时生成了Hello.class及Person.class两个文件。实际上，由于Hello.java使用了Person.java 类，JDK先编译生成了Person.class，然后再编译生成Hello.class。因此，不管Hello.java这个主类使用了多少个其他类，只要编译这个类，JDK就会自动编译其他类，很方便。输入

java -classpath "C:\Java Test" Hello

屏幕出现了

Mike

成功。

16. 第15步说明了在Hello.java中如何使用一个我们自己创建的Person.java，而且这个类与Hello.java是同在一个文件夹下。在这一步中，我们将考查Person.java如果放在不同文件夹下面的情况。

先将C:\Java Test文件夹下的Person.class文件删除，然后在C:\Java Test文件夹下新建一个名为DF的文件夹，并将C:\Java Test文件夹下的Person.java移动到其下面。在命令行输入

javac -classpath "C:\Java Test\DF" "C:\Java Test\Hello.java"

编译通过。这时javac命令没有什么不同，只需将classpath改成C:\Java Test\DF就行了。

在命令行输入

java -classpath "C:\Java Test" Hello

这时由于Java需要找在不同文件夹下的两个.class文件，而命令行中只告诉JDK一个路径，即C:\Java Test，在此文件夹下，只能找到Hello.class，找不到Person.class文件，因此，错误是可以预料得到的：

Exception in thread "main" java.lang.NoClassDefFoundError: Person
at Hello.main(Hello.java:3)

果真找不到Person.class。在设置两个以上的classpath时，先将每个路径以双引号引起来，再将这些路径以“;”号隔开，并且每个路径与“;”之间不能带有空格。因此，我们在命令行重新输入：

java -classpath "C:\Java Test";"C:\Java Test\DF" Hello

编译成功。但也暴露出一个问题，如果我们需要用到许多分处于不同文件夹下的类，那这个classpath的设置岂不是很长！有没有办法，对于一个文件夹下的所有.class文件，只指定这个文件夹的classpath，然后让JDK自动搜索此文件夹下面所有相应的路径？有，只要使用package。

17. package简介。Java中引入package的概念，主要是为了解决命名冲突的问题。比如说，在我们的例子中，我们设计了一个很简单的Person 类，如果某人开发了一个类库，其中恰巧也有一个Person类，当我们使用这个类库时，两个Person类出现了命名冲突，JDK不知道我们到底要使用哪个Person类。更有甚者，当我们也开发了一个很庞大的类库，无可避免地，我们的类库中与其他人开发的类库中命名冲突的情况就会越来越多。总不能为了避免自己的类名与其他人开发的类名相同，而让每个编程人员都绞尽脑汁地将一个本应叫Writer的类强行改名为SarkuyaWriter， MikeWriter, SmithWriter吧？

现实生活中也是如此。假如你名叫张三，又假如与你同一单位的人中有好几个都叫张三，那你的问题就来了。某天单位领导在会上宣布，张三被任命为办公室主任，你简直不知道是该哭还是该笑。但如果你的单位中只有你叫张三，你才不会在乎全国叫张三的人有多少个，因为其他张三都分布在全国各地、其他城市，你看不见他们，摸不着他们，自然不会担心。

Sun从这个“张三问题”受到了很大的启发，为解决命名冲突问题，就采取了“眼不见心不烦”的策略：将每个类都归属到一个特定的区域中，在同一个区域中的所有类，都不允许同名；而不同区域的类，由于相互看不到，则允许有同名的类存在。这样，就解决了命名冲突的问题，正如北京的张三与上海的张三毕竟不是同一人。这个区域在Java中就叫 package。由于package在Java中非常重要，如果你没有定义自己的package，JDK将会你的类都归到一个默认的无名package 中。

自定义package的名称可以由各个程序员自由创建。作为避免命名冲突的手段，package的名称最好足以与其他程序员的区别开来。在互联网上，每个域名都是唯一的，因此，Sun推荐将你自己的域名倒写后作为package的名称。如果你没有自己的域名，很可能只是因为囊中羞涩而不去申请罢了，并不见得你假想的域名与其他域名发生冲突。例如，笔者假想的域名是sarkuya.com，目前就是唯一的，因此我的package就可以定名为com.sarkuya。谢谢Java给了我们一个免费使用我们自己域名的机会，唯一的前提是倒着写。当然，每个package下面还可以带有不同的子package，如com.sarkuya.util，com.sarkuya.swing，等等。

定义package的方式是在相应的.java文件的第一行加上“package packagename;”的字样，而且每个.java文件只能有一个package。实际上，Java中的package的实现是与计算机文件系统相结合的，即你有什么样的package，在硬盘上就有什么样的存放路径。例如，某个类的package名为com.sarkuya.util，那么，这个类就应该必须存放在com/sarkuya/util的路径下面。至于这个com/sarkuya/util又是哪个文件夹的子路径，第18步会谈到。

package除了有避免命名冲突的问题外，还引申出一个保护当前package下所有类文件的功能，主要通过为类定义几种可视度不同的修饰符来实现：public, protected, private, 另外加上一个并不真实存在的friendly类型。

对于冠以public的类、类属变量及方法，包内及包外的任何类均可以访问；
protected的类、类属变量及方法，包内的任何类，及包外的那些继承了此类的子类才能访问；
private的类、类属变量及方法，包内包外的任何类均不能访问；
如果一个类、类属变量及方法不以这三种修饰符来修饰，它就是friendly类型的，那么包内的任何类都可以访问它，而包外的任何类都不能访问它(包括包外继承了此类的子类)，因此，这种类、类属变量及方法对包内的其他类是友好的，开放的，而对包外的其他类是关闭的。

前面说过，package主要是为了解决命名冲突的问题，因此，处在不同的包里面的类根本不用担心与其他包的类名发生冲突，因为JDK在默认情况下只使用本包下面的类，对于其他包，JDK一概视而不见：“眼不见心不烦”。如果要引用其他包的类，就必须通过import来引入其他包中相应的类。只有在这时， JDK才会进行进一步的审查，即根据其他包中的这些类、类属变量及方法的可视度来审查是否符合使用要求。如果此审查通不过，编译就此卡住，直至你放弃使用这些类、类属变量及方法，或者将被引入的类、类属变量及方法的修饰符改为符合要求为止。如果此审查通过，JDK最后进行命名是否冲突的审查。如果发现命名冲突，你可以通过在代码中引用全名的方式来显式地引用相应的类，如使用

java.util.Date date = new java.util.Date();

或是

java.sql.Date date = new java.sql.Date();

package的第三大作用是简化classpath的设置。还记得第16步中的障碍吗？这里重新引用其java命令：

java -classpath "C:\Java Test";"C:\Java Test\DF" Hello

我们必须将所有的.class文件的路径一一告诉JDK，而不管DF其实就是C:\Java Test的子目录。如果要用到100个不同路径的.class文件，我们就得将classpath设置为一个特别长的字符串，很累。package的引入，很好地解决了这个问题。package的与classpath相结合，通过import指令为中介，将原来必须由classpath完成的类路径搜索功能，很巧妙地转移到import的身上，从而使classpath的设置简洁明了。我们先看下面的例子。

18. 先在Hello.java中导入DF.Person。代码修改如下：

import DF.Person;

public class Hello {
public static void main(String[] args) {
Person person = new Person("Mike");
System.out.println(person.getName());
}
}

再将DF子文件夹中的Person.java设置一个DF包。代码修改如下：

package DF;

public class Person {
private String name;
public Person(String name) {
this.name = name;
}

public String getName() {
return name;
}
}

好了，神奇的命令行出现了：

javac -classpath "C:\Java Test" "C:\Java Test\Hello.java"
java -classpath "C:\Java Test" Hello

尽管这次我们只设置了C:\Java Test的classpath，但编译及运行居然都通过了！事实上，Java在搜索.class文件时，共有三种方法：
一是全局性的设置，详见第12步，其优点是一次设置，每次使用；
二是在每次的javac及java命令行中自行设置classpath，这也是本文使用最多的一种方式，其优点是不加重系统环境变量的负担；
三是根据import指令，将其内容在后台转换为classpath。JDK将读取全局的环境变量classpath及命令行中的classpath选项信息，然后将每条classpath与经过转换为路径形式的import的内容相合并，从而形成最终的classpath. 在我们的例子中，JDK读取全局的环境变量classpath及命令行中的classpath选项信息，得到C:\Java Test。接着，将import DF.Person中的内容，即DF.Person转换为DF\Person, 然后将C:\Java Test与其合并，成为C:\Java Test\DF\Person，这就是我们所需要的Person.class的路径。在Hello.java中有多少条import语句，就自动进行多少次这样的转换。而我们在命令行中只需告诉JDK最顶层的classpath就行了，剩下的则由各个类中的import指令代为操劳了。这种移花接木的作法为我们在命令行中手工地设置classpath提供了极大的便利。

应注意的一点是，import指令是与package配套使用的，只有在某类通过“package pacakgename;”设定了包名后，才能给其他类通过import指令导入。如果import试图导入一个尚未设置包的类，JVM就会报错。

19. 我们接下来看，当使用JDK类库时，classpath如何设置。

20. 修改Hello.java，内容如下：

import DF.Person;
import java.util.Date;

public class Hello {
public static void main(String[] args) {
Date date = new Date();
System.out.println(date);

Person person = new Person("Mike");
System.out.println(person.getName());
}
}

21. JDK类库存放于C:\Program Files\Java\jdk1.5.0\jre\lib\rt.jar文件中。关于jar文件的介绍，已经超出了本文的范围，感兴趣的读者可以阅读Horstmann写的Core Java一书。

jar 文件可以用WinRar打开。用WinRar打开后，可以看到里面有一些文件夹，双击其中的java文件夹，再双击util的文件夹，可以在看到 Date.class文件就在其中。如果你看过Data.java或其他JDK类库的源码(在C:\Program Files\Java\jdk1.5.0\src.zip文件中)，你就会发现，像java、util这些文件夹均是package。这也是 Hello.java第2行中使用了import指令的原因。

我们可以通过WinRar的查找功能来定位某个类所在的包。在“查找文件” 的窗口中的“要查找的文件名”文本框中输入Date.class，就会查找出在rt.jar文件中存在两个Date.class文件，一个是java\ sql\Date.class，另一个是java\util\Date.class。其中，sql下面的Date.class文件与数据库有关，并非我们这里所需，java\util\Date.class才是我们所要的。

rt.jar文件就像本文中的C:\Java Test中一样，是JDK类库的唯一入口。我们可以在命令行的classpath选项指定.jar文件。需要注意，.jar文件的classpath设置有些特珠。在以前的例子中，我们设置classpath时都是设置了路径就行了，而对于.jar文件，我们必须将.jar文件名直接加到 classpath中。

22. 在命令行输入

javac -classpath "C:\Program Files\Java\jdk1.5.0\jre\lib\rt.jar";"C:\Java Test" "C:\Java Test\Hello.java"
java -classpath "C:\Program Files\Java\jdk1.5.0\jre\lib\rt.jar";"C:\Java Test" Hello

这样当然没有问题，因为我们指定了rt.jar文件及C:\Java Test两个classpath。但且慢，在命令行输入：

javac -classpath "C:\Java Test" "C:\Java Test\Hello.java"
java -classpath "C:\Java Test" Hello

不可思议的是，编译及运行成功了！令人惊讶的是在我们将classspath只设置为C:\Java Test的情况下，JDK如何得出java.util.Date的classpath？

原因在于，就像java的Path路径已经悄悄在后台设置好一样，rt.jar的classpath路径也悄悄地在后台设置了。因此，我们不必多此一举手工设置其classpath了。

23. 最后一点需要谈到的是，如果主类恰好也在一个package中(在大型的开发中，其实这才是一种最常见的现象)，那么java命令行的类名前面就必须加上包名。

在C:\Java Test下面新建一个文件夹，名为NF。将C:\Java Test下面的Hello.class删除，将Hello.java移到NF文件夹下。打开NF文件夹下的Hello.java，为其设置package属性。

package NF;

import DF.Person;
import java.util.Date;

public class Hello {
public static void main(String[] args) {
Date date = new Date();
System.out.println(date);

Person person = new Person("Mike");
System.out.println(person.getName());
}
}

编译与以前没啥区别，只不过是修正一下改过之后的路径。

javac -classpath "C:\Java Test" "C:\Java Test\NF\Hello.java"

而java命令行却有了变化

java -classpath "C:\Java Test" NF.Hello

上面命令行语句中，NF.Hello告诉JDK，Hello.class在NF的package下面。

至此，本文有关classpath及package的问题的讨论已经全部结束。由此可见，Java的入门的确非常不易。如果初学Java的程序员一见到 Java的编译竟是如此的复杂，多半就会抽身而退。因此，笔者认为，Sun在J2SE的Tutorial中故意将编译的问题尽量简单化，以吸引更多的 Java初学者。一旦品尝了Java的香醇可口的美味后，就不用担心他们退出了，因为咖啡是非常容易让人上瘾的。

　　1.Google Talk

　　Google Talk是搜索界巨头Google刚刚推出的一款即时通讯软件，支持文字和语音交流。Google Talk与Gmail进行了整合应用，使用Gmail账号登录，并支持检查Gmail信件。Google Talk一出道便以其先进与人性的通讯理念，以及比Skype更高的通话质量，令QQ、Msn、Yahoo Messenger等聊天软件望尘莫及。据悉，正式版的Google Talk将兼容MSNAIMICQYahoo Messenger等几乎所有的即时通讯软件，并有可能将Google Talk与Google的浏览器与操作系统融合在一起。Google Talk不仅会对其他通讯软件造成致命的打击，也显示了Google“超媒体”战略的前兆。

　　2.摩托罗拉V3

　　“渊”自丰富科技，“薄”于尖峰设计，这就是摩托罗拉V3凝聚的艺术造诣。摩托罗拉V3由于是全金属材质，即使是超薄外形，牢固程度也让人放心。其内部的框架采用了镁合金，耐用程度实在大大提高。让这款手机从内而外透露出卓而不凡的品质。

　　3.索尼豌豆MP3

　　也许这样的创意让你我都感到惊讶，但是索尼豆子造型MP3确实已经让我们看到了什么叫设计的新异，不管是不是接受它，它真的已经开始销售了。索尼豆子MP3拥有512MB容量，采用闪存存储介质，支持FM调频功能，OLED显示屏，内嵌式USB传输接口，这款产品上市价格为120美元。当然这个价格确实不便宜，但是我们还能在哪里找到这么酷的产品呢？

　　4.MobiBlu“Cube”

　　DAH-1500i播放器

　　全球最小的MP3播放器，重0.65盎司(18.4克)，1G容量。除了具备播放功能，它还可以接收FM广播及录音等功能。售价为130美元。

　　5.iZ

　　iZ是一种ipod玩具，可以说是ipod的附属产品。这个怪异的小东西看起来好像是由异类和精灵结合的私生子。将ipod连上iZ，它会随着音乐翩翩起舞，发出亮光，转动它的眼睛，还会伴有各种或好或坏的音效。

　　6.MIRT红外线发射器

　　出于处理紧急事务需要，交通信号灯基本上都安装有特殊的红外传感器。如果将MIRT安装在汽车上，那么就可以确保汽车所到之处皆为绿灯。目前，该款设备在美国许多州属于非法产品，因此只能私下出售。售价300～500美元。

　　7.索尼Libré电子书

　　索尼的Libré使用了E Ink技术，只需4节AA电池便可至少阅读1万页图书。由于未采用液晶显示屏，因此不存在屏幕可视角度的问题。即使侧面阅读，屏幕依然十分清晰。目前，Libré只在日本市场有售，不过相信不久之后登陆全球市场。售价479美元。

 1.Google Earth

　　2005年，Google正式推出了免费的基于卫星图片的地图软件——Google Earth。Google Earth的功能犹如该公司的在线地图服务——Google Map，用户可以在一副3D地图上放大目的地或获得驾车指南。而Google Earth采用的3D地图定位技术则把Google Map上的最新卫星图片推向了一个新水平。用户可以在3D地图上搜索特定区域，放大缩小虚拟图片。而Google Earth与Google Map最大的不同点是，Google Earth还可以让用户旋转角度来观看地形和建筑物，为地图增添注释。

　　Google Earth主要通过访问Keyhole的航天和卫星图片扩展数据库来实现这些上述功能。该数据库在不久前进行了更新，它含有美国宇航局提供的大量地形数据，未来还将覆盖更多的地形，涉及田园，荒地等。由于它极其强大的功能，引发了人们对于它会成为恐怖袭击地图指南的担心。

　　2.IPTV

　　IPTV(宽带网络数字电视)是当前全球IT圈最热门的技术之一。它运用IP协议来提供包括电视节目在内的多种数字媒体服务及其增值服务，其接入方式有两种：“普通电视机＋IP机顶盒”方式以及PC方式。IPTV具有双向互动性，还可以在普通电视机上简单实现多种互联网增值业务。

　　从2004年开始，全球IPTV业务用户数持续增长，预计市场大规模启动将在2006年，IPTV全球业务收入将达到80亿美元，用户数将达到800万以上。2005年5月，中国广电总局发给了上海文广中国第一块IPTV牌照，UT斯达康、盛大、长虹等厂商都开始摩拳擦掌，争取这块充满诱惑力的大饼。但是，从全球的发展情况来看，由于电信运营商开展IPTV缺乏足够的运营经验，运营市场尚未成熟，用户市场仍需要培育。

　　3.Sparkle

　　微软早就看着Macromedia Flash(已被Adobe收购)的利润眼红，所以作为软件巨头的它早已暗中搞起了一个Sparkle来和Flash对抗，最近Sparkle终于初露倪端，而它被称为“Flash杀手”。Sparkle是个基于矢量图的应用系统，是微软计划中的Expression Studio家族中的一员。Expression Studio是专门为Windows Presentation Foundation(WPF)设计的开发工具(WPF之前的代号即Avalon)。Sparkle主要基于XAML语言，由于和微软是一家，会有很多Windows自带的API供它使用。这些都决定了Sparkle天生具备了比Macromedia Flash更强的可编程性。早在2003年底就有关于Sparkle的传言流出，不过微软直到2005年才确认了它的存在。

　 4.播客

　　一个麦克风、一台电脑加上制作软件，你就可以自制音频节目并放到网上，向无数人秀你所想秀的一切，这时你就成为了一名“播客”。作为数字广播技术的一种，播客最初借助一个叫“ipodder”的软件与一些便携播放器相结合而实现。而在2005年6月，苹果公司将iTunes软件版本升级到4.9，推出内置的播客支持功能，一夜之间让播客成为主流。播客的新时代来临了。

　　如果说博客颠覆了受众被动接受文字信息模式的话，那么播客则改变了传统的被动收听模式。任何人都可以在网上选择听谁的、什么时候听、什么地点听，还可以自己制作节目，播客就是新一代广播，播客时代，没有金钱与权利的门槛。

　　5.甲吧(Jabber)

　　“甲吧”是英文Jabber的谐音，是一种即时通讯技术的通用平台，兼容与通用性是甲吧的最大优势。很多聊天器的通讯协议是不公开的，各自为阵，结果用户需要下载好几个软件，开好几个窗口和不同的朋友聊。甲吧带给即时通讯的影响则是革命性的，其通讯协议完全公开，服务器原码完全开放，甲吧服务完全免费。由于这样的开放性，甲吧在全球范围内吸引了大批优秀软件开发人员为甲吧写各种应用软件。现在你只要下载一个甲吧聊天软件，就既可以和全球的甲吧用户聊，又可以和MSN，YAHOO，ICQ等其他用户聊天了。Jabber还同时支持windowsMAC OSXLinux等不同的操作系统。Jabber的跨平台软件有Psi、Gaim、Jajc等，目前最受网友追捧的Google Talk即基于Jabber协议。

　　6.Skype

　　Skype是一款基于P2P技术的超清晰网络电话软件，它让电脑与电脑之间通话免费，而打国内国际长途电话只需市话费。相对其他即时通信软件，Skype是P2P技术与VOIP的完美结合，Skype有其过人之处，它的语音效果更好，服务成本更低，不过它也有弱点——还没有视频服务。

　　虽然Skype并不是一项最新的技术，但它是在2005年引来最多话题的技术。在没有任何广告的情况下，Skype已经被下载了一亿五千万次，用户已经超过五千万。这样的业绩撼动了通信行业，它的技术成熟度令传统电信服务商们万分紧张。Skype抛开了传统运营商，直接从通信市场中独自掘金，因此它有可能带来一场全球性的电信革命，也使Skype遭到了全球电信运营商的阻击。它的发展前景会怎样，目前还不好说。

　　7.网摘

　　“网摘服务”通俗地说就是一个放在网络上的收藏夹，基于它在网络上的独特优势，它能提供很多本地收藏夹所不能提供的功能。其核心价值已经从保存浏览的网页，发展成了一个新的信息共享的中心，能够真正做到“共享中收藏、收藏中分享”。2005年，国内的网摘服务年迅速普及开来，很多网站纷纷推出自己的网摘服务平台，网友们也开始积极使用各种各样的网摘。

　　网摘服务作为一种个人的信息整理平台，目前可供选择的既有365Key、和讯网摘、博采中心、新浪ViVi等这样的国货，又有Delicious、Furl等这样的舶来品。Del.icio.us和Furl是国外网摘服务的先行者，国内最早的专业网摘站点是365key，它通过与内容提供商进行合作的模式向国内提供网摘服务。而其他网摘服务领域的生力军，发展潜力都不容忽视。

　　8.统一威胁管理(UTM)技术

　　2005年，统一威胁管理(UTM)得到了著名分析机构、信息安全厂商和用户的严重关注。准确地说，统一威胁管理(UTM)技术并不是2005年出现的新技术，它最早由Fortinet公司在2002年就提出了，当时，因为混合威胁的出现，为了满足中小企业对防火墙、IDS、VPN、反病毒等的集中管理需求，Fortinet提出了将这些技术整合进一个盒子里，做出高性能的统一威胁管理(UTM)设备。它的优势在于将企业防火墙、入侵检测和防御以及防病毒结合于一体。直到2005年，UTM技术似乎才真正开始得到用户的关注，并开始大规模的部署，同时，市场上一些传统的防火墙或IPS厂商也开始全面进入UTM领域。IDC的一份调查报告认为，UTM将有可能取代防火墙，成为人们首选的安全设备。到2008年时，它将占有整个信息安全市场的半壁江山，达到 57.6%。

　　9.维基百科

　　维基百科是由全球无数志愿学者、玩家、学生等等有知识的人共同建筑的，该计划的参与者叫做维基百科人。直至现在，参与者的人数仍在不断增加，特别是受到良好教育的人士。事实上，维基百科不能说是一种技术，而是一种创造性运用技术的方式，但对一种先进技术来说，能把它用好其实是最重要的事情。

　　维基百科本身有三个引人注意的特点，这些特点使维基百科与传统的百科全书有所区别：

　　首先，维基百科将自己定位为一个包含人类所有知识领域的百科全书，而不是一本词典、在线的论坛或其他任何东西。其次，维基百科允许大众的广泛参与，它是一个协作计划。另外，维基百科是一部内容开放的百科全书，它允许任何第三方不受限制地复制、修改及再发布材料的任何部分或全部。在这个讲究参与性的时代，维基百科这样的互动学习模式必将发扬光大。

　　10.分子磁性

　　分子磁性是中国科技大学在单分子基础研究领域获得的重大突破。可以设想一个革命性的改变：现在的笔记本电脑，是用半导体材料做的，携带已经很方便了，但是在将来，我们还可以把电脑做得像手表一样戴在手腕上，也可以像手绢一样随意叠起放在衣兜里，可是它的计算能力和存储量却是现在的100倍甚至1000倍。日前中国科技大学对单分子磁性改变和控制的研究，为这种新型电脑的问世打下了重要的基础。2005年9月，中国科技大学用全封闭的超真空显微镜，给比头发丝直径还小一万倍的分子做“手术”，不但使一个没有磁性的分子变成有磁性的，而且还可以控制和改造它。美国《科学》杂志评价说，中国的这项工作开辟了一个新领域，使世界上单分子基础研究迈上了新台阶，它为未来光电器件和生物工程技术的应用提供了广泛的前景。

JSP Model1 Model2 在JavaServer Pages - Specification 0.92中的描述

JavaServer Pages Access Model

You can apply the JavaServer Pages technology in two ways:
A user working in a client Web browser makes a request that is sent to a JavaServer Pages (.jsp) file. The .jsp file accesses server components that generate dynamic content and displays the dynamic content in the browser.

A user working a client Web browser makes a request that is sent to a Java Servlet that generates a result and stores the result in component. The servlet then calls a JavaServer Pages file, which accesses the component and displays the dynamic content in the browser.
Model 1: A request sent to a JavaServer Pages file

The user working in a client Web browser can make a request directly of a JavaServer Pages file.

 

After receiving the client request, the JavaServer Pages file requests information from a JavaBean. The JavaBean can in turn request information from an Enterprise JavaBean or a database. Once the JavaBean generates content (perhaps working with an Enterprise JavaBean, a database, or both), the JavaServer Pages file can query and display the Bean's content.
Model 2: A request sent to a Java Servlet

Another way to to use JavaServer Pages is to send a request to a Java Servlet.

 

In this example, the client makes a request that is handled by a Java Servlet. The servlet generates the dynamic content -- in this example, the servlet uses JDBC to communicate with a database to obtain the content. The servlet then wraps the dynamic content into a bean. The JavaServer Pages file accesses the dynamic content from the bean and displays the content in the client web browser.

 
Common to both access models

In either Model 1 or Model 2, the JavaServer Pages file is identified to the server by a .jsp extension -- this tells the server that special handling is required. The first time a request is made for such a file -- either directly from a client browser or from a servlet -- the .jsp file is compiled into an object. (For that reason, there can be a slight delay on the first request for a .jsp page.) The output from the object is standard HTML which the browser interprets and displays as usual.

After compilation, the compiled-page object is stored in memory on the server. On subsequent requests for that page, the server checks to see if the .jsp file has changed. If it has not changed, the server uses the compiled-page object stored in memory to generate the response to the client. (Because the object is stored in memory, the response is very fast.) If the .jsp file has changed, the server automatically recompiles the page file and replaces the object in memory.

Some examples of components that can be called from a JavaServer Pages file are JDBCTM or JavaTM BlendTM components. The results are obtained from the components by the JavaServer Pages, using standard Bean property readers, and are displayed using HTML.

标题   正则表达式之全部符号解释     选择自 kgdiwss 的 Blog  
关键字   正则表达式之全部符号解释 
出处    

字符  描述 
\  将下一个字符标记为一个特殊字符、或一个原义字符、或一个 向后引用、或一个八进制转义符。例如，'n' 匹配字符 "n"。'\n' 匹配一个换行符。序列 '\\' 匹配 "\" 而 "\(" 则匹配 "("。 
^  匹配输入字符串的开始位置。如果设置了 RegExp 对象的 Multiline 属性，^ 也匹配 '\n' 或 '\r' 之后的位置。 
$  匹配输入字符串的结束位置。如果设置了RegExp 对象的 Multiline 属性，$ 也匹配 '\n' 或 '\r' 之前的位置。 
*  匹配前面的子表达式零次或多次。例如，zo* 能匹配 "z" 以及 "zoo"。* 等价于{0,}。 
+  匹配前面的子表达式一次或多次。例如，'zo+' 能匹配 "zo" 以及 "zoo"，但不能匹配 "z"。+ 等价于 {1,}。 
?  匹配前面的子表达式零次或一次。例如，"do(es)?" 可以匹配 "do" 或 "does" 中的"do" 。? 等价于 {0,1}。 
{n}  n 是一个非负整数。匹配确定的 n 次。例如，'o{2}' 不能匹配 "Bob" 中的 'o'，但是能匹配 "food" 中的两个 o。 
{n,}  n 是一个非负整数。至少匹配n 次。例如，'o{2,}' 不能匹配 "Bob" 中的 'o'，但能匹配 "foooood" 中的所有 o。'o{1,}' 等价于 'o+'。'o{0,}' 则等价于 'o*'。 
{n,m}  m 和 n 均为非负整数，其中n <= m。最少匹配 n 次且最多匹配 m 次。例如，"o{1,3}" 将匹配 "fooooood" 中的前三个 o。'o{0,1}' 等价于 'o?'。请注意在逗号和两个数之间不能有空格。 
?  当该字符紧跟在任何一个其他限制符 (*, +, ?, {n}, {n,}, {n,m}) 后面时，匹配模式是非贪婪的。非贪婪模式尽可能少的匹配所搜索的字符串，而默认的贪婪模式则尽可能多的匹配所搜索的字符串。例如，对于字符串 "oooo"，'o+?' 将匹配单个 "o"，而 'o+' 将匹配所有 'o'。 
.  匹配除 "\n" 之外的任何单个字符。要匹配包括 '\n' 在内的任何字符，请使用象 '[.\n]' 的模式。 
(pattern)  匹配 pattern 并获取这一匹配。所获取的匹配可以从产生的 Matches 集合得到，在VBScript 中使用 SubMatches 集合，在JScript 中则使用 $0…$9 属性。要匹配圆括号字符，请使用 '\(' 或 '\)'。 
(?:pattern)  匹配 pattern 但不获取匹配结果，也就是说这是一个非获取匹配，不进行存储供以后使用。这在使用 "或" 字符 (|) 来组合一个模式的各个部分是很有用。例如， 'industr(?:y|ies) 就是一个比 'industry|industries' 更简略的表达式。 
(?=pattern)  正向预查，在任何匹配 pattern 的字符串开始处匹配查找字符串。这是一个非获取匹配，也就是说，该匹配不需要获取供以后使用。例如，'Windows (?=95|98|NT|2000)' 能匹配 "Windows 2000" 中的 "Windows" ，但不能匹配 "Windows 3.1" 中的 "Windows"。预查不消耗字符，也就是说，在一个匹配发生后，在最后一次匹配之后立即开始下一次匹配的搜索，而不是从包含预查的字符之后开始。 
(?!pattern)  负向预查，在任何不匹配 pattern 的字符串开始处匹配查找字符串。这是一个非获取匹配，也就是说，该匹配不需要获取供以后使用。例如'Windows (?!95|98|NT|2000)' 能匹配 "Windows 3.1" 中的 "Windows"，但不能匹配 "Windows 2000" 中的 "Windows"。预查不消耗字符，也就是说，在一个匹配发生后，在最后一次匹配之后立即开始下一次匹配的搜索，而不是从包含预查的字符之后开始 
x|y  匹配 x 或 y。例如，'z|food' 能匹配 "z" 或 "food"。'(z|f)ood' 则匹配 "zood" 或 "food"。 
[xyz]  字符集合。匹配所包含的任意一个字符。例如， '[abc]' 可以匹配 "plain" 中的 'a'。 
[^xyz]  负值字符集合。匹配未包含的任意字符。例如， '[^abc]' 可以匹配 "plain" 中的'p'。 
[a-z]  字符范围。匹配指定范围内的任意字符。例如，'[a-z]' 可以匹配 'a' 到 'z' 范围内的任意小写字母字符。 
[^a-z]  负值字符范围。匹配任何不在指定范围内的任意字符。例如，'[^a-z]' 可以匹配任何不在 'a' 到 'z' 范围内的任意字符。 
\b  匹配一个单词边界，也就是指单词和空格间的位置。例如， 'er\b' 可以匹配"never" 中的 'er'，但不能匹配 "verb" 中的 'er'。 
\B  匹配非单词边界。'er\B' 能匹配 "verb" 中的 'er'，但不能匹配 "never" 中的 'er'。 
\cx  匹配由 x 指明的控制字符。例如， \cM 匹配一个 Control-M 或回车符。x 的值必须为 A-Z 或 a-z 之一。否则，将 c 视为一个原义的 'c' 字符。 
\d  匹配一个数字字符。等价于 [0-9]。 
\D  匹配一个非数字字符。等价于 [^0-9]。 
\f  匹配一个换页符。等价于 \x0c 和 \cL。 
\n  匹配一个换行符。等价于 \x0a 和 \cJ。 
\r  匹配一个回车符。等价于 \x0d 和 \cM。 
\s  匹配任何空白字符，包括空格、制表符、换页符等等。等价于 [ \f\n\r\t\v]。 
\S  匹配任何非空白字符。等价于 [^ \f\n\r\t\v]。 
\t  匹配一个制表符。等价于 \x09 和 \cI。 
\v  匹配一个垂直制表符。等价于 \x0b 和 \cK。 
\w  匹配包括下划线的任何单词字符。等价于'[A-Za-z0-9_]'。 
\W  匹配任何非单词字符。等价于 '[^A-Za-z0-9_]'。 
\xn  匹配 n，其中 n 为十六进制转义值。十六进制转义值必须为确定的两个数字长。例如，'\x41' 匹配 "A"。'\x041' 则等价于 '\x04' & "1"。正则表达式中可以使用 ASCII 编码。. 
\num  匹配 num，其中 num 是一个正整数。对所获取的匹配的引用。例如，'(.)\1' 匹配两个连续的相同字符。 
\n  标识一个八进制转义值或一个向后引用。如果 \n 之前至少 n 个获取的子表达式，则 n 为向后引用。否则，如果 n 为八进制数字 (0-7)，则 n 为一个八进制转义值。 
\nm  标识一个八进制转义值或一个向后引用。如果 \nm 之前至少有 nm 个获得子表达式，则 nm 为向后引用。如果 \nm 之前至少有 n 个获取，则 n 为一个后跟文字 m 的向后引用。如果前面的条件都不满足，若 n 和 m 均为八进制数字 (0-7)，则 \nm 将匹配八进制转义值 nm。 
\nml  如果 n 为八进制数字 (0-3)，且 m 和 l 均为八进制数字 (0-7)，则匹配八进制转义值 nml。 
\un  匹配 n，其中 n 是一个用四个十六进制数字表示的 Unicode 字符。例如， \u00A9 匹配版权符号 (?)。

Appfuse是Matt Raible 开发的一个指导性的入门级J2EE框架，它继承了流行的Spring、Hibernate、ibatis、struts、Xdcolet、junit等基础框架，最新的1.7版更是提供了对Taperstry和JSF的支持。在持久层，AppFuse采用了Hibernate O/R映射工具（http://www.hibernate.org）；在容器方面，它采用了Spring Framework（http://www.springframework.org）。用户可以自由选择Struts、Spring/MVC，Webwork，Taperstry、JSF这几个web框架。采用TDD的开发方式，使用JUnit测试各层，甚至测试 jsp 输出的 w/o 错误。为了简化开发，预定义好了一套目录结构、基类、用来创建数据库、配置Tomcat、测试部署应用的 Ant 任务，帮助快速自动生成源程序和自动维护部分配置文件。

参考资料：
　　在https://appfuse.dev.java.net/可以下载Appfuse，目前的版本是1.7。
　　Appfuse的参考资料和文档可以在http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse查看。

http://www.mingsou.com/shiyong/058.htm

Struts中使用Validator框架(1)
  作者： Chuck Cavaness  

每个应用程序都有责任确保它们插入到后台资料库的数据是合法有效的，毕竟，如果这些应用程序所依赖的数据一旦遭到了破坏，那将是灾难性的，那应用程序还能拿什么来使自己正常运转呢？比如说，使用正规关系数据库的一个应用程序，数据库中的每个字段都有自己一定的规则和约束，来保证存储在其中的数据在一定程度上的正确性。任何要使用后台资料库数据的应用程序都有责任保护它们提交的数据的完整性。
任何试图插入或更新不符合标准的数据的操作都有可能被发现并拒绝。这种检测可能遍布在整个应用程序的每个角落，在表现层可能进行一些验证，在业务逻辑层，商业逻辑对象一般也有商业逻辑的验证，还有在后台资料库也要对数据进行检查。

不幸的是，由于这种验证在应用程序中无处不在，造成了应用程序在一定程度上的验证数据的代码冗余。这并不是应用程序所希望的，因为这种在多处的重复劳动，使得应用程序的部署和维护要花去更多的时间。如果在整个应用程序中，这些验证规则可以重复使用，将使得应用程序更加富有弹性，换句话说就是，部署更快捷，定制更容易，程序更灵活。

Jakarta Commons 项目Validator框架简介

Validator是由David Winterfeldt创建的开源项目，它也是Jakarta Commons的一个子项目。Commons项目主要是提供一些像Validator这样的一些可重用组件。其他著名的Commons组件还有如BeanUtils,Digester,Logging框架等。Validator 1.0版本发布于2002年11月初。

使用Validator的好处

.使用Validator框架比一般的在应用程序的代码中定义验证规则有好多优点，如：
.可以在一处为应用程序定义验证规则；
.验证规则和应用程序是松耦合的；
.服务器端和客户端的验证规则可以在同一处定义；
.配置新验证规则或修改已有验证规则变得更加简单；
.支持国际化；
.支持正则表达式；
.可以用于Web应用程序也可用于标准的Java应用程序；
.采用声明的方法实现而不是编程实现；

除了之外，Validator最大的特征就是自身支持可插性（pluggability）。在文章的后面你将会看到使用Validator框架内置的验证规则来更好地完成你的工作，而更重要的是，Validator框架允许你自定义验证程序，并插入到框架中。

Struts和Validator的关系

应该指出的是Validator框架本身是因Struts框架而建立的。Validator的创建者David Winterfeldt在使用Struts的过程中发现，在许多ActionForm类中需要反复使用同一个验证规则，这样造成了大量的代码冗余。于是他决定创建Validator框架来消除这种冗余，这样Validator就诞生了。

尽管Validator架构最初是为Struts架构而生，但它还是被设计和构造成了可以独立于Struts架构而单独使用。这一个特征使得你可以在任何的应用程序中使用这个框架，不必管它是不是Struts架构的。并不会因为你不使用Struts框架而影响Validator架构对你的应用程序作用。事实上，这就是为什么Validator是Jakarta Commons项目的一部分而不直接是Struts项目的一部分。

现在，我们来将这个框架整合应用到像基于Struts构架这样的Web应用程序上。在文章的最后中我们再介绍如何把它应用到其他类型的应用程序中，如基于EJB的应用程序。

Validator组件概述

Validator架构有下面这些组件组成：
Validators；
配置文件；
资源绑定；
JSP自定义标签；
Validator Form类；

什么是Validators?

一个Validator就是，执行一个验证规则时Validator框架调用的一个Java类。框架根据配置文件中定义的方法签名来调用这个Validaotor类。一般情况下，每个Validator类提供一个单独的验证规则，然后这些规则可以组合成更复杂的规则集。

注意：有时出于方便，一个Validator类也可以定义多个验证规则，而每个规则是一个静态方法且并不包含任何客户端状态信息。

框架提供了14种默认的验证规则，有时候这些规则也被称为Validator框架的“基本规则”，这些基本规则如表一：

名称 描述
byte,short,integer,long,float,double 检验值是否能被转换成对应的基本数据类型
creditCard 检验输入域是否是一个合法的信用卡号码
date 检验输入域是否是一个合法日期
email 检验输入是否是一个合法Email地址
mask 检验输入域是否能成功匹配一个正则表达式
maxLength 检验值的长度是否小于等于给定的最大长度
minLength 检验值的长度是否大于等于给定的最小长度
range 检验值的范围是否在最大值和最小值之间
required 检验输入域是否为不为空，或不包含空格值的长度是否大于零

正像你在表一中看到的，Validator框架提供了Web应用程序需要的大多数的验证规则。你可以使用这些现有的验证规则来创建自己验证配置文件。尽管这样，也正如我们前面提到的，和后面要讲到的，你可以根据你的需要随意的增加更多的Validator。

现在，让我们来讨论如何在一个基于Struts架构的应用程序中配置使用这些基本的Validator。

使Validator框架具有弹性的原因在于所有的验证规则和其具体细节都是通过在外部文件中配置声明实现的。你的应用程序并不必要知道这些具体的验证规则。这一特征使得规则集的发生扩展和修改时，你并不用去动你应用程序的源代码。这一点对你要进行每次的个性化安装或当需求发生变化时来说是非常重要的。

如果你使用Struts1.1的Validator框架，你会用到这样两个配置文件，一个叫validator- rules.xml，另一个叫validation.xml；其实你也可以随意的给他们命名，甚至可以把它们合并成一个XML文件。但是，你还是最好把它们分开，因为它们各有各的用途。

注意：如果你从Jakarta网站上下载Validator，并不包含这两个文件。只有在包含的Validator框架的Struts的下载中才可以找到这两个文件。

validator-rules.xml文件

validator-rules.xml文件定义应用程序可以使用的Validator。validator-rules.xml充当模板的作用，定义所有应用程序可能要用到的Validator。

注意：这个xml文件和我们下面要讨论的另一个xml文件都应该放到类加载器可以找得到的地方。当我们在Web应用程序中使用Validator框架时，正确的位置应该是在WEB-INF下。

validator-rules.xml文件服从validator- rules_1_1.dtd的管理，validator- rules_1_1.dtd可以在jakarta.apache.org/struts/dtds/validator- rules_1_1.dtd下载到。我们并不想花太多的时间放在研究这个文件的具体细节上，我们在这儿只作一些基本的介绍。

validator-rules.xml文件中最重要的元素包含在元素中，例如，例一：

例一：一个简单的validator-rules.xml文件

name="required"
classname="org.apache.struts.util.StrutsValidator"
method="validateRequired"
methodparams="java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,
javax.servlet.http.HttpServletRequest"
msg="errors.required"/>

classname="org.apache.struts.util.StrutsValidator"
method="validateMinLength"
methodparams="java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,
javax.servlet.http.HttpServletRequest"
depends="required"
msg="errors.minlength"/>

应用程序使用的每个Validator对应一个元素。在例一中给大家展示了两个Validator，一个是请求Validator，另一个是最小长度Validator。元素支持许多属性。这些属性是必要的，用于告知框架这个Validator应当调用哪个正确的类和方法。例如，例一中的请求Validator元素表明这个Validator将调用org.apache.struts.util.StrutsValidator类的validateRequest()方法。Validator也可能要依赖另一个Validator,如例一中的最小长度的Validator就是这样一个例子，它包含一个depends属性，用它来表示这个Validator将依赖于请求Validator。msg属性用一个键值指定一个资源绑定，框架将用它来生成正确的错误信息。资源绑定的使用有益于错误信息的本地化。

元素还支持子元素，允许你指定一个客户端运行的javascript函数。这样服务器端和客户端验证可以在同一处指定，这使应用程序的维护变得简单。

validation.xml文件

Validator框架的第二个配置文件就是这个叫validation.xml的文件。其实你可以随意把它命名为你喜欢的任何名字，也可以把它放到validator-rules.xml文件中。

validation.xml用于把你在validator-rules.xml中定义的各个Validator和你的应用程序中的组件映射起来。由于我们在这里讨论的是在Struts中使用Validator框架，那么在这里validation.xml就是把这些Validator和Struts的ActionForm类建立映射。ActionForm类其实是一个类似JavaBean一样的类，在Struts中用于捕捉用户输入并帮助传输这些输入到下一级应用程序组件。ActionForm也提供了在用户输入被传到业务逻辑层之前验证这些输入的便利场所。例二是一个简单的validation.xml:

例二：一个简单的validation.xml文件

property="firstName"
depends="required">

property="lastName"
depends="required">

例二向大家展现了一个name属性叫checkoutForm的一个form元素。checkoutForm是一个在Struts配置文件中定义的一个ActionForm Bean。所以，例二的XML文件就是把这个ActionForm Bean和请求Validator建立映射，Bean的firstName和lastName属性分别对应XML文件中相应的firstName和lastName field元素。

其实它还有许多其它作用，如可以在validation.xml中定义常量和全局变量，用于在整个文件中使用，当你想使时可以方便的反复使用。对于validation.xml的元素和属性更详细的解释，可以下载jakarta.apache.org/struts/dtds/validation_1_1.dtd参阅。

资源绑定
资源绑定用于帮助消息本地化和一些其它文本信息的本地化处理。由于它减少了应用程序的许多冗余的硬编码，故对应用程序有很大益处。比如，如果你要在JSP页面中要使用一个“Name”标签时，你可以把这个字符串放到一个资源绑定中，然后使用资源绑定的一个逻辑键值引用这个字符串，而不是直接使用这个字符串，这样做的好处在于，当你想把这个字符串改为“First Name”时，你只需在资源绑定中修改一处即可，而不必修改整个应用程序的全部代码。

对于Validator框架，当验证规则失败的时候，可以从资源绑定中创建错误信息。Validator框架提供几种默认消息，同一般的应用程序消息资源放在一起。如下：

#Normal resource bundle messages
label.firstName=First Name
label.lastName=Last Name

#Error messages used by the Validator
errors.required={0} is required.
errors.minlength={0} can not be less than {1} characters.
errors.maxlength={0} can not be greater than {1} characters.
errors.invalid={0} is invalid.
...

当一个验证规则失败时，这个验证规则创建一个错误信息。框架将自动给消息插入参数。比如说，我们使用例一和例二的验证规则，当checkoutForm的firstName属性为空时，我们会看到这样的错误信息：

First Name is required.

你也可以修改绑定或配置文件来显示你喜欢的消息。

“挂”Validator到Struts上

现在我们已经了解了Validator框架，感觉蛮不错吧！下面我们将快速的讲一下我们是如何轻松地在Struts框架中使用Validator框架的。

首先要做的就是让Struts框架认识Validator框架。你可以使用Struts1.1的Plug-in新特性来实现它。只要在Struts配置文件中增加下面代码即可：

property="pathnames"
value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>

这样Struts就可以自动识别Validator框架了。

另外一个必需的步骤就是创建ActionForm Bean（标准的或是动态的）和确保Validator框架的配置文件是可用的，这样就搞定了。并不需要作一些调用验证规则或做其他具体的事情，Struts框架会自动完成这些工作，这就是所谓的基于声明的配置。然后当验证规则失败的时候，你就可以用JSP标签看到显示的错误信息了。

创建自己的Validator

尽管Validator框架已为大家提供了Web应用程序需要的大多数验证规则，但有时我们还是需要创建一些自己的验证规则。幸运的，Validator框架的扩展性相当好，为你提供了这种便利，而这样做对程序造成的影响相当小的。

创建自己的Validator并不是一件难事，只要创建一个实现这个规则的Java类即可。比如，（在国外）要去超市买二锅头，要验证顾客是否达到合法饮酒年龄。你可以使用已有的验证规进行验证，但我们觉得创建一个验证规则进行验证要更加直截了一些。验证饮酒年龄规则Validator Java代码如下:

例三：自定义验证规则

import java.io.Serializable;
import javax.servlet.http.HttpServletRequest;
import org.apache.commons.validator.Field;
import org.apache.commons.validator.GenericValidator;
import org.apache.commons.validator.ValidatorAction;
import org.apache.commons.validator.ValidatorUtil;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.util.StrutsValidatorUtil;

public class NewValidator implements Serializable{

public static boolean validateDrinkingAge( Object bean,
ValidatorAction va,
Field field,
ActionErrors errors, HttpServletRequest request) {

String value = null;
if (isString(bean)) {
value = (String) bean;
} else {
value =
ValidatorUtil.getvalueAsString(bean, field.getProperty());
}
String sMin = field.getVarvalue("drinkingAge");

if (!GenericValidator.isBlankOrNull(value)) {
try {
int ivalue = Integer.parseInt(value);
int drinkingAge = Integer.parseInt(sMin);

if ( ivalue < drinkingAge ){
errors.add(field.getKey(),
StrutsValidatorUtil.getActionError(request, va, field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
StrutsValidatorUtil.getActionError(request, va, field));
return false;
}
}
return true;
}

private static boolean isString(Object o) {
if (o == null) {
return (true);
}
return (String.class.isInstance(o));
}
}

你创建完新的Validator之后，你只要把他加到现存的Validator框架的validator-rules.xml的列表中，你就可以像使用基本验证规则一样使用你自己创建的验证规则。

在非Struts应用程序中使用Validator框架

正像我们在前面谈到的，Validator框架最初是为在Struts框架中使用而设计的。可是，Validator框架设计的相当灵活，并没有直接把它耦合在Struts框架中，这样你就可以在普通的应用程序中也可以使用Validator框架来进行验证。但是，你必须执行一些必需的步骤。

你可以利用像在Web应用程序中一样使用配置文件。这也是使用Validatoe框架的另一个优点。你可以在Struts框架使用插件的方式来定位和装载这些文件。而在非Struts应用程序中你必须人为地手动的定位和装载这些配置文件。下面就是应用程序在启动时一般要调的方法：

...
ValidatorResources resources = new ValidatorResources();

InputStream rules =
ValidateExample.class.getResourceAsStream("validator-rules.xml");

ValidatorResourcesInitializer.initialize(resources, in);

InputStream forms =
ValidateExample.class.getResourceAsStream("validation.xml");

ValidatorResourcesInitializer.initialize(resources, forms);

...

这段代码片断创建了一个ValidatorResources实例，并根据两个配置文件进行了初始化。然后你就可以在你应用程序使用这个ValidatorResources对象验证你配置的JavaBean了。

例四向你展示如何使用已初始化的ValidatorResources对象来验证一个Person Bean。

例四：如何使用Validator验证你的Bean。

//假设我们已经创建和装配了一个CheckoutForm Bean对象
CheckoutForm form = new CheckoutForm();
//使用chekoutForm创建一个Validator
Validator validator = new Validator(resources, "checkoutForm");
//告诉Validator要验证哪个Bean
validator.addResource(Validator.BEAN_KEY, form);
//验证checkoutForm对象并存储验证结果
ValidatorResults results = validator.validate();

在例四中，我们看到我们把checkoutForm JavaBean的名字传给Validator类的构造器，这是为了告诉Validator实例使用哪套验证规则来验证这个Bean。

正如你看到的一样，在非Struts应用程序中使用Validator框架显得有点不自动化，但是它还是提供了比较灵活的解决方案。使用Validator框架的另一个好处就是把验证从源代码中分离到外部的配置文件中。这使我们可以把更多的时间放在我们的业务逻辑开发上。

客户端VS服务器端Validator

最后我们简单的阐述一下Validator框架对javascript的支持。因为有些应用程序需要执行一些客户端验证，在某些时候使用javascript进行一些客户端的验证是很有必要的。这里的客户端我们一般特指Web浏览器。

Validator框架提供使用配置文件中的规则动态和自动生成javascript验证规则的支持。对于每个元素，它可以有一个子元素和包含一些javascript代码。当包含一些自定义标签的JSP页面被解释时，javascript也被解释，并当表单提交时执行这些验证规则。这些叫javascriptValidatorTag的标签被包含在Struts的标签集中。这些标签可以像这样进行使用：

笔者认为在需要时使用一定的javascript是可以接受的。当你需要执行一些客户端的验证时，使用Validator框架标签是也是一种不错的选择，而且支持根据用户的区域进行本地化。

结束语

到此为止，我给大家简单地介绍了Validator框架，这些其实是框架的一些表面的东西。这个框架的内容深不可测，仅正则表达式就可以写一本小册子。

像任何一个框架一样，Validator框架为大家提供的是一个基础的架构，你可以根据你的需求对其进行扩展和个性化。使用像Validator的框架的最重要的一点就是它们是经过千锤百炼，是技术的精华。你并不需重蹈前人失败的覆辙，你可以节省下时间把更多的精力集中在对业务逻辑的开发上。