java项目.docx
《java项目.docx》由会员分享，可在线阅读，更多相关《java项目.docx（14页珍藏版）》请在冰点文库上搜索。
java项目
java项目
第17章项目
本章包含了一系列项目，它们都以本书介绍的内容为基础，并对早期的章节进行了一定程度的扩充。
与往常经历过的项目相比，这儿的大多数项目都明显要复杂得多，它们充分演示了新技术以及类库的运用。
17.1文字处理
假如您有C或C++的体会，那么最开始可能会对Java操纵文本的能力感到怀疑。
事实上，我们最可怕的确实是速度专门慢，这可能阻碍我们制造能力的发挥。
然而，Java对应的工具（专门是String类）具有专门强的功能，就象本节的例子展现的那样（而且性能也有一定程度的提升）。
正如大伙儿立即看到的那样，建立这些例子的目的差不多上为了解决本书编制过程中遇到的一些问题。
然而，它们的能力并非仅止于此。
通过简单的改造，即可让它们在其他场合大显身手。
除此以外，它们还揭示出了本书往常没有强调过的一项Java特性。
17.1.1提取代码列表
关于本书每一个完整的代码列表（不是代码段），大伙儿无疑会注意到它们都用专门的注释记号起始与终止（'//:
'和'///:
~'）。
之因此要包括这种标志信息，是为了能将代码从本书自动提取到兼容的源码文件中。
在我的前一本书里，我设计了一个系统，可将测试过的代码文件自动合并到书中。
但关于这本书，我发觉一种更简便的做法是一旦通过了最初的测试，就把代码粘贴到书中。
而且由于专门难第一次就编译通过，因此我在书的内部编辑代码。
但如何提取并测试代码呢？
那个程序确实是关键。
假如你打算解决一个文字处理的问题，那么它也专门有利用价值。
该例也演示了String类的许多特性。
我第一将整本书都以ASCII文本格式储存成一个独立的文件。
CodePackager程序有两种运行模式（在usageString有相应的描述）：
假如使用-p标志，程序就会检查一个包含了ASCII文本（即本书的内容）的一个输入文件。
它会遍历那个文件，按照注释记号提取出代码，并用位于第一行的文件名来决定创建文件使用什么名字。
除此以外，在需要将文件置入一个专门名目的时候，它还会检查package语句（依照由package语句指定的路径选择）。
但如此还不够。
程序还要对包（package）名进行跟踪，从而监视章内发生的变化。
由于每一章使用的所有包都以c02，c03，c04等等起头，用于标记它们所属的是哪一章（除那些以com起头的以外，它们在对不同的章进行跟踪的时候会被忽略）——只要每一章的第一个代码列表包含了一个package，因此CodePackager程序能明白每一章发生的变化，并将后续的文件放到新的子名目里。
每个文件提取出来时，都会置入一个SourceCodeFile对象，随后再将那个对象置入一个集合（后面还会详尽讲述那个过程）。
这些SourceCodeFile对象能够简单地储存在文件中，那正是本项目的第二个用途。
假如直截了当调用CodePackager，不添加-p标志，它就会将一个“打包”文件作为输入。
那个文件随后会被提取（开释）进入单独的文件。
因此-p标志的意思确实是提取出来的文件已被“打包”（packed）进入那个单一的文件。
但什么缘故还要如此苦恼地使用打包文件呢？
这是由于不同的运算机平台用不同的方式在文件里储存文本信息。
其中最大的问题是换行字符的表示方法；因此，还有可能存在另一些问题。
然而，Java有一种专门类型的IO数据流——DataOutputStream——它能够保证“不管数据来自何种机器，只要使用一个DataInputStream收取这些数据，就可用本机正确的格式储存它们”。
也确实是说，Java负责操纵与不同平台有关的所有细节，而这正是Java最具魅力的一点。
因此-p标志能将所有东西都储存到单一的文件里，并采纳通用的格式。
用户可从Web下载那个文件以及Java程序，然后对那个文件运行CodePackager，同时不指定-p标志，文件便会开释到系统中正确的场所（亦可指定另一个子名目；否则就在当前名目创建子名目）。
为确保可不能留下与特定平台有关的格式，凡是需要描述一个文件或路径的时候，我们就使用File对象。
除此以外，还有一项专门的安全措施：
在每个子名目里都放入一个空文件；那个文件的名字指出在那个子名目里应找到多少个文件。
下面是完整的代码，后面会对它进行详细的说明：
959-968页程序
我们注意到package语句差不多作为注释标志出来了。
由于这是本章的第一个程序，因此package语句是必需的，用它告诉CodePackager已改换到另一章。
然而把它放入包里却会成为一个问题。
当我们创建一个包的时候，需要将结果程序同一个特定的名目结构联系在一起，这一做法对本书的大多数例子差不多上适用的。
但在那个地点，CodePackager程序必须在一个专用的名目里编译和运行，因此package语句作为注释标记出去。
但对CodePackager来说，它“看起来”依旧象一个一般的package语句，因为程序还不是专门复杂，不能侦查到多行注释（没有必要做得这么复杂，那个地点只要求方便就行）。
头两个类是“支持／工具”类，作用是使程序剩余的部分在编写时更加连贯，也更便于阅读。
第一个是Pr，它类似ANSIC的perror库，两者都能打印出一条错误提示消息（但同时也会退出程序）。
第二个类将文件的创建过程封装在内，那个过程已在第10章介绍过了；大伙儿差不多明白，如此做专门快就会变得专门累赘和苦恼。
为解决那个问题，第10章提供的方案致力于新类的创建，但这儿的“静态”方法差不多使用过了。
在那些方法中，正常的违例会被捕捉，并相应地进行处理。
这些方法使剩余的代码显得更加清新，更易阅读。
关心解决问题的第一个类是SourceCodeFile（源码文件），它代表本书一个源码文件包含的所有信息（内容、文件名以及名目）。
它同时还包含了一系列String常数，分别代表一个文件的开始与终止；在打包文件内使用的一个标记；当前系统的换行符；文件路径分隔符（注意要用System.getProperty（）侦查本地版本是什么）；以及一大段版权声明，它是从下面那个Copyright.txt文件里提取出来的：
969-967页程序
从一个打包文件中提取文件时，起初所用系统的文件分隔符也会标注出来，以便用本地系统适用的符号替换它。
当前章的子名目储存在chapter字段中，它初始化成c02（大伙儿可注意一下第2章的列表正好没有包含一个打包语句）。
只有在当前文件里发觉一个package（打包）语句时，chapter字段才会发生改变。
1.构建一个打包文件
第一个构建器用于从本书的ASCII文本版里提取出一个文件。
发出调用的代码（在列表里较深的地点）会读入并检查每一行，直到找到与一个列表的开头相符的为止。
在那个时候，它就会新建一个SourceCodeFile对象，将第一行的内容（差不多由调用代码读入了）传递给它，同时还要传递BufferedReader对象，以便在那个缓冲区中提取源码列表剩余的内容。
从这时起，大伙儿会发觉String方法被频繁运用。
为提取出文件名，需调用substring（）的过载版本，令其从一个起始偏移开始，一直读到字串的末尾，从而形成一个“子串”。
为算出那个起始索引，先要用length（）得出startMarker的总长，再用trim（）删除字串头尾余外的空格。
第一行在文件名后也可能有一些字符；它们是用indexOf（）侦测出来的。
若没有发觉找到我们想查找的字符，就返回-1；若找到那些字符，就返回它们第一次显现的位置。
注意这也是indexOf（）的一个过载版本，采纳一个字串作为参数，而非一个字符。
解析出并储存好文件名后，第一行会被置入字串contents中（该字串用于储存源码清单的完整正文）。
随后，将剩余的代码行读入，并合并进入contents字串。
因此情况并没有想象的那么简单，因为特定的情形需加以专门的操纵。
一种情形是错误检查：
若直截了当遇到一个startMarker（起始标记），说明当前操作的那个代码列表没有设置一个终止标记。
这属于一个出错条件，需要退出程序。
另一种专门情形与package关键字有关。
尽管Java是一种自由形式的语言，但那个程序要求package关键字必须位于行首。
若发觉package关键字，就通过检查位于开头的空格以及位于末尾的分号，从而提取出包名（注意亦可一次单独的操作实现，方法是使用过载的substring（），令其同时检查起始和终止索引位置）。
随后，将包名中的点号替换成特定的文件分隔符——因此，那个地点要假设文件分隔符仅有一个字符的长度。
尽管那个假设可能对目前的所有系统差不多上适用的，但一旦遇到问题，一定不要忘了检查一下那个地点。
默认操作是将每一行都连接到contents里，同时还有换行字符，直到遇到一个endMarker（终止标记）为止。
该标记指出构建器应当停止了。
若在endMarker之前遇到了文件结尾，就认为存在一个错误。
2.从打包文件中提取
第二个构建器用于将源码文件从打包文件中复原（提取）出来。
在这儿，作为调用者的方法不必担忧会跃过一些中间文本。
打包文件包含了所有源码文件，它们相互间紧密地靠在一起。
需要传递给该构建器的仅仅是一个BufferedReader，它代表着“信息源”。
构建器会从中提取出自己需要的信息。
但在每个代码列表开始的地点还有一些配置信息，它们的身份是用packMarker（打包标记）指出的。
若packMarker不存在，意味着调用者试图用错误的方法来使用那个构建器。
一旦发觉packMarker，就会将其剥离出来，并提取出名目名（用一个'#'结尾）以及文件名（直到行末）。
不管在哪种情形下，旧分隔符都会被替换成本地适用的一个分隔符，这是用Stringreplace（）方法实现的。
老的分隔符被置于打包文件的开头，在代码列表稍靠后的一部分即可看到是如何把它提取出来的。
构建器剩下的部分就专门简单了。
它读入每一行，把它合并到contents里，直到遇见endMarker为止。
3.程序列表的存取
接下来的一系列方法是简单的访问器：
directory（）、filename（）（注意方法可能与字段有相同的拼写和大小写形式）和contents（）。
而hasFile（）用于指出那个对象是否包含了一个文件（专门快就会明白什么缘故需要那个）。
最后三个方法致力于将那个代码列表写进一个文件——要么通过writePacked（）写入一个打包文件，要么通过writeFile（）写入一个Java源码文件。
writePacked（）需要的唯独东西确实是DataOutputStream，它是在别的地点打开的，代表着预备写入的文件。
它先把头信息置入第一行，再调用writeBytes（）将contents（内容）写成一种“通用”格式。
预备写Java源码文件时，必须先把文件建好。
这是用IO.psOpen（）实现的。
我们需要向它传递一个File对象，其中不仅包含了文件名，也包含了路径信息。
但现在的问题是：
那个路径实际存在吗？
用户可能决定将所有源码名目都置入一个完全不同的子名目，那个名目可能是尚不存在的。
因此在正式写每个文件之前，都要调用File.mkdirs（）方法，建好我们想向其中写入文件的名目路径。
它可一次性建好整个路径。
4.整套列表的包容
以子名目的形式组织代码列表是专门方便的，尽管这要求先在内存中建好整套列表。
之因此要如此做，还有另一个专门有说服力的缘故：
为了构建更“健康”的系统。
也确实是说，在创建代码列表的每个子名目时，都会加入一个额外的文件，它的名字包含了那个名目内应有的文件数目。
DirMap类可关心我们实现这一成效，并有效地演示了一个“多重映射”的概述。
这是通过一个散列表（Hashtable）实现的，它的“键”是预备创建的子名目，而“值”是包含了那个特定名目中的SourceCodeFile对象的Vector对象。
因此，我们在这儿并不是将一个“键”映射（或对应）到一个值，而是通过对应的Vector，将一个键“多重映射”到一系列值。
尽管这听起来看起来专门复杂，但具体实现时却是专门简单和直截了当的。
大伙儿能够看到，DirMap类的大多数代码都与向文件中的写入有关，而非与“多重映射”有关。
与它有关的代码仅极少数而已。
可通过两种方式建立一个DirMap（名目映射或对应）关系：
默认构建器假定我们期望名目从当前位置向下展开，而另一个构建器让我们为起始名目指定一个备用的“绝对”路径。
add（）方法是一个采取的行动比较密集的场所。
第一将directory（）从我们想添加的SourceCodeFile里提取出来，然后检查散列表（Hashtable），看看其中是否差不多包含了那个键。
假如没有，就向散列表加入一个新的Vector，并将它同那个键关联到一起。
到这时，不管采取的是什么途径，Vector都差不多就位了，能够将它提取出来，以便添加SourceCodeFile。
由于Vector可象如此同散列表方便地合并到一起，因此我们从两方面都能感受得专门方便。
写一个打包文件时，需打开一个预备写入的文件（当作DataOutputStream打开，使数据具有“通用”性），并在第一行写入与老的分隔符有关的头信息。
接着产生对Hashtable键的一个Enumeration（枚举），并遍历其中，选择每一个名目，并取得与那个名目有关的Vector，使那个Vector中的每个SourceCodeFile都能写入打包文件中。
用write（）将Java源码文件写入它们对应的名目时，采纳的方法几乎与writePackedFile（）完全一致，因为两个方法都只需简单调用SourceCodeFile中适当的方法。
但在那个地点，根路径会传递给SourceCodeFile.writeFile（）。
所有文件都写好后，名字中指定了已写文件数量的那个附加文件也会被写入。
5.主程序
前面介绍的那些类都要在CodePackager中用到。
大伙儿第一看到的是用法字串。
一旦最终用户不正确地调用了程序，就会打印出介绍正确用法的那个字串。
调用那个字串的是usage（）方法，同时还要退出程序。
main（）唯独的任务确实是判定我们期望创建一个打包文件，依旧期望从一个打包文件中提取什么东西。
随后，它负责保证使用的是正确的参数，并调用适当的方法。
创建一个打包文件时，它默认位于当前名目，因此我们用默认构建器创建DirMap。
打开文件后，其中的每一行都会读入，并检查是否符合专门的条件：
（1）若行首是一个用于源码列表的起始标记，就新建一个SourceCodeFile对象。
构建器会读入源码列表剩下的所有内容。
结果产生的句柄将直截了当加入DirMap。
（2）若行首是一个用于源码列表的终止标记，说明某个地点显现错误，因为终止标记应当只能由SourceCodeFile构建器发觉。
提取／开释一个打包文件时，提取出来的内容可进入当前名目，亦可进入另一个备用名目。
因此需要相应地创建DirMap对象。
打开文件，并将第一行读入。
老的文件路径分隔符信息将从这一行中提取出来。
随后依照输入来创建第一个SourceCodeFile对象，它会加入DirMap。
只要包含了一个文件，新的SourceCodeFile对象就会创建并加入（创建的最后一个用光输入内容后，会简单地返回，然后hasFile（）会返回一个错误）。
17.1.2检查大小写样式
尽管对涉及文字处理的一些项目来说，前例显得比较方便，但下面要介绍的项目却能赶忙发挥作用，因为它执行的是一个样式检查，以确保我们的大小写形式符合“事实上”的Java样式标准。
它会在当前名目中打开每个.java文件，并提取出所有类名以及标识符。
若发觉有不符合Java样式的情形，就向我们提出报告。
为了让那个程序正确运行，第一必须构建一个类名，将它作为一个“仓库”，负责容纳标准Java库中的所有类名。
为达到那个目的，需遍历用于标准Java库的所有源码子名目，并在每个子名目都运行ClassScanner。
至于参数，则提供仓库文件的名字（每次都用相同的路径和名字）和命令行开关-a，指出类名应当添加到该仓库文件中。
为了用程序检查自己的代码，需要运行它，并向它传递要使用的仓库文件的路径与名字。
它会检查当前名目中的所有类和标识符，并告诉我们哪些没有遵守典型的Java大写写规范。
要注意那个程序并不是十全十美的。
有些时候，它可能报告自己查到一个问题。
但当我们认真检查代码的时候，却发觉没有什么需要更换的。
尽管这有点儿烦人，但仍比自己动手检查代码中的所有错误强得多。
下面列出源代码，后面有详细的说明：
974-980页程序
MultiStringMap类是个专门的工具，承诺我们将一组字串与每个键项对应（映射）起来。
和前例一样，那个地点也使用了一个散列表（Hashtable），只是这次设置了继承。
该散列表将键作为映射成为Vector值的单一的字串对待。
add（）方法的作用专门简单，负责检查散列表里是否存在一个键。
假如不存在，就在其中放置一个。
getVector（）方法为一个特定的键产生一个Vector；而printValues（）将所有值逐个Vector地打印出来，这对程序的调试专门有用。
为简化程序，来自标准Java库的类名全都置入一个Properties（属性）对象中（来自标准Java库）。
记住Properties对象实际是个散列表，其中只容纳了用于键和值项的String对象。
然而仅需一次方法调用，我们即可把它储存到磁盘，或者从磁盘中复原。
实际上，我们只需要一个名字列表，因此为键和值都使用了相同的对象。
针对特定名目中的文件，为找出相应的类与标识符，我们使用了两个MultiStringMap：
classMap以及identMap。
此外在程序启动的时候，它会将标准类名仓库装载到名为classes的Properties对象中。
一旦在本地名目发觉了一个新类名，也会将其加入classes以及classMap。
如此一来，classMap就可用于在本地名目的所有类间遍历，而且可用classes检查当前标记是不是一个类名（它标记着对象或方法定义的开始，因此收集接下去的记号——直到碰到一个分号——并将它们都置入identMap）。
ClassScanner的默认构建器会创建一个由文件名构成的列表（采纳FilenameFilter的JavaFilter实现形式，参见第10章）。
随后会为每个文件名都调用scanListing（）。
在scanListing（）内部，会打开源码文件，并将其转换成一个StreamTokenizer。
依照Java关心文档，将true传递给slashStartComments（）和slashSlashComments（）的本意应当是剥除那些注释内容，但如此做看起来有些问题（在Java1.0中几乎无效）。
因此相反，那些行被当作注释标记出去，并用另一个方法来提取注释。
为达到那个目的，'/'必须作为一个原始字符捕捉，而不是让StreamTokeinzer将其当作注释的一部分对待。
现在要用ordinaryChar（）方法指示StreamTokenizer采取正确的操作。
同样的道理也适用于点号（'.'），因为我们期望让方法调用分离出单独的标识符。
但对下划线来说，它最初是被StreamTokenizer当作一个单独的字符对待的，但现在应把它留作标识符的一部分，因为它在staticfinal值中以TT_EOF等等形式使用。
因此，这一点只对目前那个专门的程序成立。
wordChars（）方法需要取得我们想添加的一系列字符，把它们留在作为一个单词看待的记号中。
最后，在解析单行注释或者舍弃一行的时候，我们需要明白一个换行动作什么时候发生。
因此通过调用eollsSignificant（true），换行符（EOL）会被显示出来，而不是被StreamTokenizer吸取。
scanListing（）剩余的部分将读入和检查记号，直至文件尾。
一旦nextToken（）返回一个finalstatic值——StreamTokenizer.TT_EOF，就标志着差不多抵达文件尾部。
若记号是个'/'，意味着它可能是个注释，因此就调用eatComments（），对这种情形进行处理。
我们在这儿唯独感爱好的其他情形是它是否为一个单词，因此还可能存在另一些专门情形。
假如单词是class（类）或interface（接口），那么接着的记号就应当代表一个类或接口名字，并将其置入classes和classMap。
若单词是import或者package，那么我们对这一行剩下的东西就没什么爱好了。
其他所有东西确信是一个标识符（这是我们感爱好的），或者是一个关键字（对此不感爱好，但它们采纳的确信是小写形式，因此不必兴师动众地检查它们）。
它们将加入到identMap。
discardLine（）方法是一个简单的工具，用于查找行末位置。
注意每次得到一个新记号时，都必须检查行末。
只要在主解析循环中碰到一个正斜杠，就会调用eatComments（）方法。
然而，这并不表示确信遇到了一条注释，因此必须将接着的记号提取出来，检查它是一个正斜杠（那么这一行会被丢弃），依旧一个星号。
但假如两者都不是，意味着必须在主解析循环中将刚才取出的记号送回去！
幸运的是，pushBack（）方法承诺我们将当前记号“压回”输入数据流。
因此在主解析循环调用nextToken（）的时候，它能正确地得到刚才送回的东西。
为方便起见，classNames（）方法产生了一个数组，其中包含了classes集合中的所有名字。
那个方法未在程序中使用，但对代码的调试专门有用。
接下来的两个方法是实际进行检查的地点。
在checkClassNames（）中，类名从classMap提取出来（请记住，classMap只包含了那个名目内的名字，它们按文件名组织，因此文件名可能相伴错误的类名打印出来）。
为做到这一点，需要取出每个关联的Vector，并遍历其中，检查第一个字符是否为小写。
若确实为小写，则打印出相应的出错提示消息。
在checkIdentNames（）中，我们采纳了一种类似的方法：
每个标识符名字都从identMap中提取出来。
假如名字不在classes列表中，就认为它是一个标识符或者关键字。
现在会检查一种专门情形：
假如标识符的长度等于3或者更长，而且所有字符差不多上大写的，则忽略此标识符，因为它可能是一个staticfinal值，比如TT_EOF。
因此，这并不是一种完美的算法，但它假定我们最终会注意到任何全大写标识符差不多上不合适的。
那个方法并不是报告每一个以大写字符开头的标识符，而是跟踪那些已在一个名为reportSet（）的Vector中报告过的。
它将Vector当作一个“集合”对待，告诉我们一个项目是否已在那个集合中。
该项目是通过将文件名和标识符连接起来生成的。
若元素不在集合中，就加入它，然后产生报告。
程序列表剩下的部分由main（）构成，它负责操纵命令行参数，并判定我们是预备在标准Java库的基础上构建由一系列类名构成的“仓库”，依旧想检查已写好的那些代码的正确性。
不管在哪种情形下，都会创建一个ClassScanner对象。
不管预备构建一个“仓库”，依旧预备使用一个现成的，都必须尝试打开现有仓库。
通过创建一个File对象并测试是否存在，就可决定是否打开文件并在ClassScanner中装载classes那个Properties列表（使用load（））。
来自仓库的类将追加到由ClassScanner构建器发觉的类后面，而不是将其覆盖。
假如仅提供一个命令行参数，就意味着自己想对类名和标识符名字进行一次检查。
但假如提供两个参数（第二个是"-a"），就说明自己想构成一个类名仓库。
在这种情形下，需要打开一个输出文件，并用Properties.save（）方法将列表写入一个文件，同时用一个字串提供文件头信息。
17.2方法查找工具
第11章介绍了Java1.1新的“反射”概念，并利用那个概念查询一个
升级会员 