public static AffineTransform getTranslateInstance(double tx, double ty)

public static AffineTransform getScaleInstance(double sx, double sy)

public static AffineTransform getShearInstance(double shx, double shy)

public static AffineTransform getRotateInstance(double theta)

public static AffineTransform getRotateInstance(double theta, double x, double y)

    可能有不少初学者会有这样的困惑（以前我也有过）：在你的代码里调用了一些资源文件，如图片，音乐等，在调试环境或单独运行的时候可以正常显示或播放，而一旦打包到jar文件中，这些东东就再也出不来了，除非把这个jar放到原来未打包以前的目录下，但通常jar是单独发布的。这里介绍一个解决这类问题的方法。

getResource和getResourceAsStream

    问题的根源还是在于老生常谈的所谓class path，不信的话你在系统环境变量里的ClassPath加上你的jar文件，这下你就看得到你的图片了！但单独发布jar的话不可能指望每次都让用户为你的jar而专门修改classpath。那么有没有什么办法一劳永逸地搞定它呢？我们需要从类的装载入手。先扯远一点，在开发JSP之类的Web应用程序的时候要用到第三方的库怎么办？通常的做法是把这些库（可以是class，也可以是jar）统统放到WEB-INF/lib/目录下面，为什么这样系统就认了呢？因为Web容器（譬如Tomcat）在装载类的时候有自己的组织方式（可以参考Tomcat手册）。特别地，jar也是类装载器的一个可访问媒介，ClassLoader提供了两个方法用于从装载的类路径中取得资源：

public URL getResource(String name);
public InputStream getResourceAsStream(String name);

这里name是资源的类路径，它是相对与“/”根路径下的位置。getResource得到的是一个URL对象来定位资源，而getResourceAsStream取得该资源输入流的引用保证程序可以从正确的位置抽取数据。
    真正使用的不是ClassLoader的这两个方法，而是Class的getResource和getResourceAsStream方法，因为Class对象可以从你的类得到（如YourClass.class或YourClass.getClass()），而ClassLoader则需要再调用一次YourClass.getClassLoader()方法，但根据JDK文档的说法，Class对象的这两个方法其实是“委托”（delegate）给装载它的ClassLoader来做的，所以只需要使用Class对象的这两个方法就可以了。
    在参考资料中有一篇老外写的文章比较深入介绍了从jar中装载资源的方法。

一个应用的例子

    以下是在我写的一个小工具MSNHistoryCombiner中用到的一段代码，可以从jar中装载图片和文本信息。譬如，你的jar中根目录下有个img目录，里面放有一些图片，如img1.jpg，你可以这样调用

Utilities.getImageFromJar("/img/img1.jpg", YourClass.class);

注意必须这里是“/img/img1.jpg”而非“img/img1.jpg”。从jar中读文本资源也是类似方法调用getTextFromJar。
    需要说明的是，这段代码也不是我原创的，是从一段别的代码中经过修改得到的，但原代码的来源忘记了，在这里向原作者表示感谢和歉意。

import java.io.*;
import java.awt.*;

public class Utilities
{
  /**//**
   * <p>
   * Description: Return an Image based on the supplied image identifier. The
   * image is assumed to reside at the defined location within the same
   * repository as this class.
   */
  public static Image getImageFromJar(final String imageId, Class c)
  {
    // Image reference initialised to null (the image may not be found).
    Image image = null;
    // Open a resource stream on the supplied image identifier.
    final InputStream inputStream = c.getResourceAsStream(imageId);
    // If the image data is found
    if (inputStream != null)
    {
      // Open a byte array output stream so that we can create a byte
      // array with which to create the image.
      final ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
      // Attempt to copy the source image data into the byte array
      // stream, and then create an image from the result.
      try
      {
        // Read/write image data in 1k chunks.
        final byte[] bytes = new byte[1024];
        int read = 0;
        while ((read = inputStream.read(bytes)) >= 0)
        {
          byteArrayOutputStream.write(bytes, 0, read);
        }

        // Create an image from the resulting byte array.
        image = Toolkit.getDefaultToolkit().createImage(
            byteArrayOutputStream.toByteArray());
      }
      catch (IOException exception)
      {
        exception.printStackTrace();
      }
    }
    return image;
  }

  public static String getTextFromJar(final String filename, Class c)
  {
    String text = "";
    // Open a resource stream on the supplied file name.
    final InputStream inputStream = c.getResourceAsStream(filename);
    // If the file is found
    if (inputStream != null)
    {
      final BufferedReader in = new BufferedReader(new InputStreamReader(
          inputStream));
      try
      {
        String s;
        while ((s = in.readLine()) != null)
        {
          text += s + "\n";
        }
      }
      catch (IOException exception)
      {
        exception.printStackTrace();
      }
    }
    return text;
  }
}

参考资料

J2SE API Documentation

用 One-JAR 简化应用程序交付

         如果你是一个MSN的多年用户，是否会有这样的烦恼：可能你在好几个不同的地方上网（家中、学校、公司、使用笔记本移动等等），在每个地方的机器上都保留一套MSN聊天记录，一段时间后也许你就要离开某个地方了（譬如毕业），但又想保存那台机器上的聊天记录，怎么办？一般是把“C:\Documents and Settings\<你的机器帐号>\My Documents\我接收到的文件\<你的MSN帐号再加上一串数字>\历史记录”文件夹拷贝一份备份着，这样时间一长，你可能就有好几个这样的“历史记录”，在MSN Messenger里查看得到的只是你当前机器上的那部分记录，如果想要看其它记录，只好手动打开那些拷贝过来的XML文件了。当然，QQ可能也有类似的问题，但我早就不用它了，所以只能说“可能”
         懒汉jungleford于是就想了，能不能把这好几套聊天记录合并成一套，同时又保持记录原有的格式使MSN能够识别呢？于是google之，找了好久都没有找到，哼，于是自己动手了，趁毕业前的空闲花几天时间写了这么个小工具——MSN历史记录合并器。由于只是玩玩，可能还有一些不尽人意的地方，但大抵可以满足要求了。

使用方法

         该程序是纯Java编写的，需要你的机器上安装JRE或JDK，如果没有，可以到以下地址下载：

         http://java.sun.com/j2se/1.5.0/download.jsp

         安装完后一般直接双击我这个Combiner.jar文件就可以运行了。如果有什么问题，就在“我的电脑→属性→高级→环境变量”里添加一个名为“JAVA_HOME”的环境变量，其值为你安装的JRE或JDK的路径，然后修改“path”环境变量，在其值尾部加一个“%JAVA_HOME%\bin”。然后打开一个命令行方式的控制台，转到Combiner.jar所在的目录，键入

         javaw -jar Combiner.jar

或

         java -jar Combiner.jar

运行即可。
          本工具可以合并两个历史记录目录（比如一个是你当前机器上的“C:\Documents and Settings\<你的机器帐号>\My Documents\我接收到的文件\<你的MSN帐号再加上一串数字>\历史记录”，一个是你从其它机器上拷过来的另一套MSN聊天记录，当然，这两套记录必须都属于你自己的同一个MSN帐号，同时要保证这两个目录里都有MessageLog.xsl配置文件），也可以合并两个单独的历史记录XML文件。合并完后把这些新生成的记录拷回到“C:\Documents and Settings\<你的机器帐号>\My Documents\我接收到的文件\<你的MSN帐号再加上一串数字>\历史记录”里去，以后运行MSN就可以看到所有的聊天记录啦~~~如果担心有什么问题，在拷回去之前最好先备份一下你当前的历史记录。工具虽小，但如果能给您帮一点小忙的话，jungleford也很高兴

开发工具

         J2SE 5.0 SDK，Eclipse 3.01

声明

         本工具主要算法和代码是我写的，但有部分是修改自Java Almanac的例子代码。本工具是完全自由和免费的，在Combiner.jar中已经包含了所有源代码（用jar xf命令或zip解压缩工具就看得到），您尽可以修改这些代码，也欢迎继续传播，但请注名“Powered by JUNGLEFORD”之类的说明来源的字眼。对于您的修改后传播可能产生的任何法律问题，本人概不负责。

运行时截图


下载
点这里

     近来实在太忙了，一个邮件客户端写写停停，直到现在还是一个没怎么经过测试的命令行方式的版本，但聊胜于无，通过这个小项目学习了一下JavaMail和POP协议，又实践了一两个设计模式，感觉还是比较有意义的，以后有空会慢慢做好。ICEMail是个相当不错的客户端系统，但我试过以后还是发现它每次接受POP邮件的时候还是从头开始收起，POP协议虽然简单——的确是简单——但方便了服务器的同时却让客户端的开发人员皱眉头：不维护状态的协议需要在客户端考虑太多的东西。JavaMail虽然封装得非常好，但要写一个好的客户端并不是一件easy的事情。我只用了JavaMail本身的API，没有用SUN的provider，中间碰到了不少细节上的问题，有的地方解决方法还是老土，但觉得比啥都copy来得有意思，呵呵……现在这个版本可能有的中文邮件显示成乱码，那是因为根据RFC 822，邮件在发送时可能没有按标准编码，如果指定用中文解码可以得到解决，但在别的字符集下仍然不是一个好的方案，利用Locale可能是一个办法，等我忙完手头的先～～～

JExp 0.1 命令行版本：JExp.rar

环境：JDK 1.4，JAF，JavaMail；将activation.jar和mail.jar加入classpath

运行：先解开rar文件，再用 jar -x 解开jar包，在目录下运行 java com.jungleford.jexp.JExp，进入命令行用help命令显示各种命令（仿UNIX的形式）

源代码：已经包含在jar包中，是完全公开的，你可以随意修改，如果你能给我一些意见建议的话，我将会非常感激  :)

截图：

资料：

• JavaMail API 文档
• JavaMail FAQ
• ICEMail project

    近来在完善一个简单的邮件客户端程序，还好SUN J2EE SDK提供了JavaMail API，我们可以方便地调用它已经封装好的接口而不用理会协议本身的实现。但现在很多mail服务器都提供的是POP协议接收邮件，由于POP3是“无状态”的协议，服务器端不保存诸如标记这样的任何状态，你把一封邮件移到“垃圾箱”里在服务器端看来和其它邮件并没有什么区别，所以所有邮件状态的解析工作全部留给客户端处理，这就是为什么利用JavaMail编写接收邮件的程序要比编写发送邮件的程序要困难不少的原因。尽管JavaMail封装得相当不错，但写一个好的邮件客户端仍需要对基本协议有一定的了解，初次接触JavaMail的朋友可能会有一些困惑，譬如：为什么Message对象不是可序列化的对象，否则我的客户端解析起来可能方便得多；为什么对中文内容的邮件支持得不好，我应当如何实现自己的中文邮件处理方案；……这些问题的答案可以在SUN官方网站上提供的JavaMail API FAQ找到，它会对你的疑问有一个初步的解释，还有它的中文译文转自SUN中国网站。不过清晰的概念还是了解协议和RFC比较好，比如RFC 822等。

    这是我们几乎不用查什么JDK文档就能信手拈来的代码段，写的时候也应该思考一下套一个BufferedInputStream的意义何在。另一个就是我们不怎么看到的PushbackInputStream（其对应的字符流模式为PushbackReader）。
    在通常状态下，“流”意味着“一次性”，就是说你进行了一次操作后它的状态就变了，譬如读，无论是文件还是socket，你读的过程中一个潜在的“读指针”一样的东东就在移动，你无法在读以后再重新定位（当然RandomAccessFile是另一种情况），如果你以前奇怪为什么数据库操作中ResultSet里get某个字段以后就不能再第二次get它了，这里或许是个解释。但好在PushbackInputStream给了我们第二次读的机会。我们先来区别一下“监听”和“截获”的概念，“监听”就是把得到的消息copy一份，原始消息并不作任何改变地传递到目的地；而“截获”则是先把消息“扣押”下来，不让其自动转给目标，而是先进行一些处理以后在转发给目标（如果是网络安全专业的背景知识，大概知道“监听”是对“机密性”的攻击，而“截获”不仅是对“机密性”还是对“完整性”的攻击）。有的朋友大概对hook这个名词有些了解，它是一种Windows的一种消息处理机制，似乎就是一种消息截获手段，但我对Windows编程几乎一窍不通；此外，如果你熟悉Servlet的话，也能找到像Filter这样的处理机制，在对每个HTTP请求/应答进行转发之前，先在里头耍一点花招，确定哪些予以转发，哪些屏蔽掉，这也算是“截获”吧。通过上面的介绍，我们不妨把PushbackInputStream看成是对输入流的一种“截获”手段，其中最重要的方法是unread：

jungleford如是说

文件I/O：文件流→序列化

网络I/O：Socket→RMI

数据库I/O：CMP、Hibernate

序列化再探讨

一点启示

参考资料

• Core Java 2. by Cay S. Horstmann, Gary Cornell
• J2SE进阶. by JavaResearch.org
• Thinking in Java. by Bruce Eckel
• J2SE 1.4.2 Documentation. by java.sun.com
• Java Network Programming. by Elliotte R. Harold
• Java分布式对象：RMI和CORBA. by IBM developerWorks

jungleford如是说

始祖：System.out.println(...)

    为什么还是要一再提到它？毕竟我们的习惯不是那么容易改变的，而且System.out（别忘了还有System.err）是一个直接和控制台打交道的PrintStream对象，是终端显示的基础，高级的Logger要在终端显示日志内容，就必然会用到这个。一个小规模的程序调试，恰当地使用System.out.println(...)我认为仍然是一种最方便最有效的方法，所以我们仍把它放在最开始，以示不能“数典忘祖” :)

不常用的关键字：assert

    assert对多数人来讲可能还比较陌生，它也是一个调试工具，好像是J2SE 1.4才加进来的东东，一种常见的用法是：

assert (布尔表达式);

    当表达式为true时没有任何反映，如果为false系统将会抛出一个AssertionError。如果你要使用assert，在编译时必须加上“-source 1.4”的选项，在运行时则要加上“-ea”选项。

后生可畏：Java Logging API一瞥

    System.out.println(...)对于较高要求的用户是远远不够的，它还不是一个日志系统，一个比较完善的日志系统应当有输出媒介、优先级、格式化、日志过滤、日志管理、参数配置等功能。伴随J2SE 1.4一起发布的Java日志包java.util.logging适时地满足了我们的初步需求，在程序中按一定格式显示和记录丰富的调试信息已经是一件相当easy的事情。

1. 日志记录器：Logger
    Logger是一个直接面向用户的日志功能调用接口，从用户的角度上看，它完成大部分日志记录工作，通常你得到一个Logger对象，只需要使用一些简单方法，譬如info，warning，log，logp，logrb等就能完成任务，简单到和System.out.println(...)一样只用一条语句，但后台可能在向控制台，向文件，向数据库，甚至向网络同时输出该信息，而这个过程对用户是完全透明的。
    在使用Logger之前，首先需要通过getLogger()或getAnonymousLogger()静态方法得到一个Logger对象（想想看，这里是不是设计模式当中的“工厂方法”的一个实实在在的应用？可以参考一下Logger的源代码，你就明白LogManager是“工厂类”而Logger是“产品类”，凡事都要学以致用嘛，呵呵）。这里我们需要了解的是Logger的“名字空间”（namespace）的概念：通常我们调试时需要清楚地知道某个变量是出现在什么位置，精确到哪个类的哪个方法，namespace就是这么个用处。我们用getLogger()得到Logger时需要指定这个Logger的名字空间，通常是一个包名，譬如“com.jungleford.test”等，如果是指定了namespace，那么将在一个全局对象LogManager中注册这个namespace，Logger会基于namespace形成层次关系，譬如namespace为“com.jungleford”的Logger就是namespace为“com.jungleford.test”的Logger的父，后者调用getParent()方法将返回前者，如果当前没有namespace为“com.jungleford”的Logger，则查找namespace为“com”的Logger，要是按照这个链找不到就返回根Logger，其namespace为""，根Logger的父是null。从理论上说，这个namespace可以是任意的，通常我们是按所调试的对象来定，但如果你是使用getAnonymousLogger()方法产生的Logger，那它就没有namespace，这个“匿名Logger”的父是根Logger。
    得到一个Logger对象后就可以记录日志了，下面是一些常用的方法：

finest、finer、fine、info、config、warning、severe：简洁的方法，输出的日志为指定的级别。关于日志级别我们在后面将会详细谈到。 log：不仅可以指定消息和级别，还可以带一些参数，甚至可以直接是一个LogRecord对象（这些参数是LogRecord对象的重要组成部分）。 logp：更加精细了，不但具有log方法的功能，还可以不使用当前的namespace，定义新的类名和方法名。 entering、exiting：这两个方法在调试的时候特别管用，用来观察一个变量变化的情况，就如同我们在VC的调试状态下watch一个变量，然后按F10，呵呵。

2. 输出媒介控制：Handler
    日志的意义在于它可以以多种形式输出，尤其是像文件这样可以长久保存的媒介，这是System.out.println(...)所无法办到的。Logging API的Handler类提供了一个处理日志记录（LogRecord，它是对一条日志消息的封装对象）的接口，包括几个已实现的API：

ConsoleHandler：向控制台输出。 FileHandler：向文件输出。 SocketHandler：向网络输出。

    这三个输出控制器都是StreamHandler的子类，另外Handler还有一个MemoryHandler的子类，它有特殊的用处，我们在后面将会看到。在程序启动时默认的Handler是ConsoleHandler，不过这个是可以配置的，下面会谈到logging配置文件的问题。
    此外用户还可以定制自己输出控制器，继承Handler即可，通常只需要实现Handler中三个未定义的抽象方法：

publish：主要方法，把日志记录写入你需要的媒介。 flush：清除缓冲区并保存数据。 close：关闭控制器。

    通过重写以上三个方法我们可以很容易就实现一个把日志写入数据库的控制器。

3. 自定义输出格式：Formatter
    除了可以指定输出媒介之外，我们可能还希望有多种输出格式，譬如可以是普通文本、HTML表格、XML等等，以满足不同的查看需求。Logging API中的Formatter就是这样一个提供日志记录格式化方法接口的类。默认提供了两种Formatter：

SimpleFormatter：标准日志格式，就是我们通常在启动一些诸如Tomcat、JBoss之类的服务器的时候经常能在控制台下看到的那种形式，就像这样：

2004-12-20 23:08:52 org.apache.coyote.http11.Http11Protocol init 信息: Initializing Coyote HTTP/1.1 on http-8080 2004-12-20 23:08:56 org.apache.coyote.http11.Http11Protocol init 信息: Initializing Coyote HTTP/1.1 on http-8443

XMLFormatter：XML形式的日志格式，你的Logger如果add了一个new XMLFormatter()，那么在控制台下就会看到下面这样的形式，不过更常用的是使用上面介绍的FileHandler输出到XML文件中：

<?xml version="1.0" encoding="GBK" standalone="no"?> <!DOCTYPE log SYSTEM "logger.dtd"> <log> <record>   <date>2004-12-20T23:47:56</date>   <millis>1103557676224</millis>   <sequence>0</sequence>   <logger>Test</logger>   <level>WARNING</level>   <class>Test</class>   <method>main</method>   <thread>10</thread>   <message>warning message</message> </record>

    与Handler类似，我们也可以编写自己的格式化处理器，譬如API里没有将日志输出为我们可通过浏览器查看的HTML表格形式的Formatter，我们只需要重写3个方法：

format：格式化LogRecord中包含的信息。 getHead：输出信息的头部。 getTail：输出信息的尾部。

4. 定义日志级别：Level
    大家可能都知道Windows的“事件查看器”，里面有三种事件类型：“信息”、“警告”、“错误”。这其实就是日志级别的一种描述。Java日志级别用Level类表示，一个日志级别对应的是一个整数值，范围和整型值的范围是一致的，该整数值愈大，说明警戒级别愈高。Level有9个内置的级别，分别是：

类型	对应的整数
OFF	最大整数（Integer.MAX_VALUE）
SEVERE	1000
WARNING	900
INFO	800
CONFIG	700
FINE	500
FINER	400
FINEST	300
ALL	最小整数（Integer.MIN_VALUE）

    你也可以定义自己的日志级别，但要注意的是，不是直接创建Level的对象（因为它的构造函数是protected的），而是通过继承Level的方式，譬如：

class AlertLevel extends java.util.logging.Level {   public AlertLevel()   {     super("ALERT", 950);   } } ... Logger logger = Logger.getAnonymousLogger(); logger.log(new AlertLevel(), "A dangerous action!");

    上面定义了一个高于WARNING但低于SEVERE的日志级别。
    于是可能有朋友会兴冲冲地用以下的语句来记录一个事件：

Logger logger = Logger.getAnonymousLogger(); logger.fine("Everything seems ok."); //或者是 //logger.log(Level.FINE, "Everything seems ok.");

    但是一程序运行，奇怪了，怎么没有打印出任何消息呢？下一小节我们就来谈这个问题。

5. 日志过滤器：Filter
    所谓过滤器是控制哪些日志该输出哪些不该输出的一种组件。上面你写的那条日志没有能在控制台显示出来，是因为logging API预先设定的缺省级别是INFO，也就是说只有级别不低于INFO（即其整数值不小于800）的日志才会被输出，这个就是Filter的功能。所以我们可以看到SEVERE、WARNING、INFO以及上面我们定义的ALERT消息，但看不到FINE、FINER和FINEST消息。当然，你尽可以用Logger的setLevel方法或者修改配置文件的方法（什么是配置文件，我们后面将会看到）来重新定义Logger输出的最低级别。
    Filter不仅仅可以按日志级别过滤，你也可以定义自己的Filter，实现其中的isLoggable方法，随便按照LogRecord携带的任何信息进行过滤，譬如（顺便复习一下匿名类，呵呵）：

Logger logger = Logger.getAnonymousLogger(); logger.setFilter(new Filter() {   public boolean isLoggable(LogRecord rec)   {     //从LogRecord里得到过滤信息   } });

6. 预定义参数
    LogManager是一个实现了Singleton模式的全局对象（由于是一个唯一的对象，LogManager需要是线程安全的），它管理着程序启动以后所有已注册（包层次）或匿名的Logger，以及相关配置信息。这里的配置信息通常是从<JAVA_HOME>\jre\lib\logging.properties文件得到的。logging.properties对于logging API来说是一个很重要的文件，它的内容一般是：

############################################################ # Default Logging Configuration File # # You can use a different file by specifying a filename # with the java.util.logging.config.file system property. # For example java -Djava.util.logging.config.file=myfile ############################################################ ############################################################ # Global properties ############################################################ # "handlers" specifies a comma separated list of log Handler # classes. These handlers will be installed during VM startup. # Note that these classes must be on the system classpath. # By default we only configure a ConsoleHandler, which will only # show messages at the INFO and above levels. handlers= java.util.logging.ConsoleHandler # To also add the FileHandler, use the following line instead. #handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler # Default global logging level. # This specifies which kinds of events are logged across # all loggers. For any given facility this global level # can be overriden by a facility specific level # Note that the ConsoleHandler also has a separate level # setting to limit messages printed to the console. .level= INFO ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ # default file output is in user's home directory. java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter # Limit the message that are printed on the console to INFO and above. java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter ############################################################ # Facility specific properties. # Provides extra control for each logger. ############################################################ # For example, set the com.xyz.foo logger to only log SEVERE # messages: com.xyz.foo.level = SEVERE

    你可以通过修改这个配置文件来改变运行时Logger的行为，譬如：.level定义的是上面所说的默认输出的最低日志级别；XXXHandler相关属性定义了各种输出媒介等等。
    这里比较有意思的是关于日志文件，也就是FileHandler，当然，你可以在程序中创建一个FileHandler，然后添加到logger中：

FileHandler fhd = new FileHandler("%h/java%u.log", 5000, 1, true); fhd.setLevel(Level.ALL); fhd.setFormatter(new XMLFormatter()); logger.addHandler(fhd);

    这段代码等价于上面logging.properties中的文字段：

java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter

    这里的pattern代表用转义字符定义的一个日志文件名：

转义字符串	含义
%t	临时目录
%h	用户目录，即系统属性“user.home”对应的值
%g	一个随机生成的数字，可以重复
%u	一个随机生成的非重复数字

    以上面的“%h/java%u.log”为例，在Windows 2000下代表日志文件可能就是：C:\Documents and Settings\Administrator\javax.log。这里x代表一个不重复的数字，如果是第一次，那么就是java0.log；如果在该目录下已经存在了一个java0.log的文件，那么logger就产生一个java1.log的新的日志文件。
    当然，你可以在别的地方使用自己写的配置文件，不过在启动程序时候需要指定java.logging.config.file属性：

java -Djava.logging.config.file=...

7. 资源与本地化
    Logger里还有个方法叫logrb，可能初学者不太会用到。如果你安装的JDK是国际版的，那么你将会看到在中文Windows平台下日志输出的INFO、WARNING显示的是“信息”、“警告”等中文字样。因为logrb是一个和Java i18n/l10n相关的方法，你可以定义自己的“资源包”（Resource Bundle），然后在logrb方法中指定相应的资源名称，那么在输出日志中你就能看到用自己定义的本地语言、时间等显示的信息。如果你对i18n/l10n感兴趣，可以参考Java Localization文档。


    了解以上组件后，我们回顾一个完整的日志处理的工作过程：
    程序启动日志服务，创建Logger对象，LogManager按照namespace的层次结构组织Logger，在同一个namespace里子Logger将继承父Logger的属性；同时，LogManager从logging.properties中读取相应的属性对Logger进行初始化，如果在程序中设置了属性则使用新的配置。当应用程序产生一条日志，Logger将创建一个LogRecord对象，该对象封装了一条日志的全部信息。Logger需要根据当前设置的Filter来判断这条日志是否需要输出，并将有用的日志传给相应的Handler处理，而Handler根据当前设置的Formatter和Resource Bundle将日志消息转换成一定的显示格式，然后输出到预定的媒介（控制台、文件等）中去。整个过程大致如图1所示：

图1

    前面我们在介绍Handler的时候提到过一个特殊的类叫MemoryHandler，这里我们要了解一下“Handler链”的概念，日志在输出之前可能经过多个Handler的处理，MemoryHandler在这种情况下就是一个中间角色，它维持一个内存中的日志缓冲区，当日志没有填满缓冲区时就将全部日志送到下一个Handler，否则新进来的日志将会覆盖最老的那些日志，因此，使用MemoryHandler可以维护一定容量的日志，另外，MemoryHandler也可以不需要使用Formatter来进行格式化，从而具有较高的效率。一个使用Handler链的例子如图2所示：

图2

青出于蓝：Apache Jakarta log4j日志工具包

    应付日常的日志需求，J2SE的Logging API可以说已经做得相当出色了，但追求完美的开发人员可能需要可扩展性更好的专业日志处理工具，log4j正是当前比较流行的一个工具包，它提供更多的输出媒介、输出格式和配置选择，你会发现原来在J2SE里一些仍需要自己手工构建的功能在log4j当中都已经为你实现了。关于log4j我可能谈得不会太多，可以看看文后所附的“参考资料”，网上也有很详细的介绍，我在这里做的是一个对比，因为log4j和J2SE 1.4 Logging API的用法是很相似的，一些名称不同的组件你会发现他们所处的地位其实是一样的：

	J2SE 1.4中的类	log4j中的类
日志记录器	Logger	Logger
日志管理器	LogManager	LogManager
日志对象	LogRecord	LoggingEvent
输出媒介控制	Handler	Appender
格式化	Formatter	Layout
级别	Level	Level
过滤器	Filter	Filter

    log4j可以做到更精细更完善的控制，譬如J2SE里没有现成向数据库里写日志的方法，但log4j却有JDBCAppender，它甚至还能向GUI图形界面（LF5Appender，一种以JTree方式显示的层次结构）、Windows NT事件查看器（NTEventLogAppender）、UNIX的syslogd服务（SyslogAppender）、电子邮箱（SMTPAppender）、Telnet终端（TelnetAppender）、JMS消息（JMSAppender）输出日志，牛吧；J2SE里默认只能用%JAVA_HOME%\jre\lib\logging.properties做配置文件，但log4j却可以在代码中设置其它路径下的properties文件或XML格式的配置文件。log4j的其它方面同样很丰富，总之，log4j的最大的特点就是“灵活”，无论是Appender、Layout还是Configurator，你可以把日志轻松地弄成几乎任何你想要的形式。

框架与标准：JSR议案

    从时间顺序上讲，log4j要比J2SE Logging API来得早，很多概念都是log4j先有的，但成为一个标准，则是在JSR 47的形成。可能有人还不太了解JSR，这还要谈到JCP，即“Java Community Process”，它是一个于1998年成立的旨在为Java技术制定民间标准的开放组织，你可以通过http://www.jcp.org/en/participation/membership申请成为它的付费或免费会员，JCP的主要工作就是制定和发布JSR（Java Specification Requests），JSR对于Java的意义就相当于RFC对于网络技术的意义，由于JCP会员们的集思广益，使得JSR成为Java界的一个重要标准。JSR 47即“Logging API Specification”，制定了调试和日志框架，J2SE Logging API正是该框架的一个实现。由于种种原因，在JSR 47出来以前，log4j就已经成为一项成熟的技术，使得log4j在选择上占据了一定的优势，但不能因此就说JSR 47是过时的规范，标准总是在发展的嘛！

并不是全部：其它日志处理工具

    除了J2SE Logging API和log4j，日志处理方面还有别的技术：Jakarta的commons组件项目中的JCL（Jakarta Commons Logging）是一个不错的选择，它有点类似于GSS-API（通用安全服务接口）中的思想，其日志服务机制是可以替换的，也就是说既可以用J2SE Logging API也可以用log4j，但JCL对开发人员提供一致的接口，这一点相当重要，组件可重用正是Jakarta Commons项目追求的一个目标；IBM的JLog也是在J2SE Logging API之前推出的一个工具包，但JLog是一个商业产品。
    至于日志API的应用那可就多了，现在哪个大一点的工具或平台不用到日志模块呢？Tomcat、JBoss……

    说了这么多，我们无非需要知道的一件事就是，“调试”也是一门学问。在我们一个劲地用System.out.println(...)而且用得很爽的时候，也应该想想看，如何让这样一条菜鸟语句也能变得人性化和丰富多彩。

参考资料

• Java Logging Documentation
• Java Logging APIs
• J2SE进阶, by www.javaresearch.org
• Short introduction to log4j, by Ceki Gülcü
• log4j APIs
• FAQ about log4j

问题的源头

• 集合：对象的容器与数据结构

• 无序集、有序集、映射

JCF的全家福

    好啦好啦，这些我们都知道，又不是在上数学课，说了这么多废话，怎么还没扯到正题上来？JCF的影子我还没看见呢！列位看官别急，这就给您道来。其实上面的概念对理解JCF非常重要。
    JCF是个颇有点规模的家族，看看它的类层次关系图就知道了，下面这张图（图1）摘自著名的Thinking in Java：

                                         图1 JCF层次结构

    哇，这么多接口和类，真有点让人无从下手的感觉。其实我们真正需要记住的只是这么一个超超easy的结构（图2）：


                                        图2

    这张图看起来舒服多了吧？但它又能说明什么问题呢？它怎么就能够把握整个JCF呢？我们把Collection接口置于最顶上，意思是想说：Collection其实是整个JCF家族中的“祖宗”，几乎所有的JCF成员都源自该接口，或者和它有密切的关系，Collection提供关于集合的一些通用操作的接口，包括插入（add()方法）、删除（remove()方法）、判断一个元素是不是其成员（contains()方法）、遍历（iterator()方法）等等。注意了，前面的“废话”在这里将得到体现：Set接口体现的是“无序集”的概念，它是不允许有重复元素出现的；List接口代表“有序集”；而Map接口则是“映射”（在早期的Java版本中并不叫Map，我们在后面会看到），其实Map.Entry接口就是代表一个“元素对”我们可以通过Map的entrySet()方法得到这样一个由“元素对”组成的Set对象。我们注意到Set和List都是从“祖宗”Collection派生的，而Map不是，毕竟对一对元素的操作与对单个元素的操作还是有区别的，但是如果你仔细对照一下Collection和Map的源代码，以及它们的直接后代AbstractCollection和AbstractMap的源代码，你将会发现很多相似的地方，所以我们仍然可以把Map看成是和Collection有着血缘关系的接口，而和Set，List一起处于并列的位置。
    有了“无序集”，“有序集”和“映射”，我们就可以定义各种各样的抽象数据结构了，譬如图1所示的向量，链表，堆栈，哈希表，平衡二叉树等。但我们需要记住的，仅仅是图2，置于其它的成员，在用到的时候查一下API手册不就行了？不过一般初学者还是比较容易用到一些类，像Vector、ArrayList、HashMap，我在这里列了一张表，显示了常见的JCF成员及其关系：

集合框架的祖宗： Collection					历史集合	新集合
无序集： Set		有序集： List			映射：Dictionary	映射：Map
AbstractSet	SortedSet	AbstractList		AbstractSequentialList	Hashtable	AbstractMap			SortedMap
		历史集合	新集合	LinkedList		WeakHashMap	IdentityHashMap	HashMap	TreeMap
HashSet	TreeSet	Vector	ArrayList
LinkedHashSet		Stack			Properties			LinkedHashMap

    可能有的概念您还不是太了解，譬如什么叫“历史集合”，Hashtable、HashMap、TreeMap三者之间有什么区别和联系，怎样实现对一个特定集合的快速遍历、元素查找或者排序，没关系，我们在下面将逐一进行研究。

细节考虑：目标与效率

    有了JCF的层次还不够，重要的是对集合所容纳的对象的具体操作，以前我们学数据结构的时候可能老师总会让你计算一个算法的时间复杂度，可能你会对这个O(f(n))很不耐烦，但事实上算法效率是一个重要的因素。

1. 侧重点：遍历 vs. 查找

    对集合的有两个主要的应用：我需要知道集合有哪些元素；根据条件找到一个特定的元素。在算法上通常称为“遍历”和“查找”。不要以为我们生活中不常用哦！譬如CCTV的“幸运52”里面，李咏让参赛者报出一款PDA的准确价位，他会怎么做？“2000”“高了”“1000”“低了”“1500”“低了”……直到答对为止。可能有很多人都会选择这个策略，无论他是不是计算机专业出身的，也不知道他是不是了解“数据结构”和“折半查找”，更不用说他是不是知道还有比在无初始代价下O(log n)的时间复杂度更快的算法了，但我们经常会自然而然地用这样的方法，这和一个人的行业无关，除非这个人的rp超强，呵呵……
    又讲了一堆题外话了，遍历和修改似乎是一对矛盾，一个可以高效率插入删除元素的数据结构通常遍历的性能并不是最优。于是JCF在这里根据用户的目标实现了两种定制的数据结构：哈希表（包括HashSet和HashMap）和平衡二叉树（包括TreeSet和TreeMap）。由于可排序性是一种独特的要求，所以引入了SortedSet和SortedMap，它们分别是AbstractSet和AbstractMap的子接口，而TreeSet和TreeMap又分别是他们的一种实现。熟悉数据结构的人可能比较了解，哈希表在进行插入、删除、查找这样的操作是很快的，其时间复杂度是常数级O(1)；平衡二叉树虽然插入、删除操作比较麻烦（需要O(log n)的代价），但进行遍历和排序却很快。选择完全在于用户的侧重点，但由于类型转换的方便性，通常我们用哈希表构造一个集合以后，再把它转换成相应的树集进行遍历，以获得较好的效果。

Set set1 = new HashSet(); set1.add(elem1);// 通过插入元素构造集合 set1.add(elem2); set1.add(elem3); Set set2 = new TreeSet(set); Iterator all = set2.iterator(); while (all.hasNext()) {// 遍历集合 all.next(); ... }

2. 历史实现 vs. 新实现

3. 同步 vs. 不同步

4. 容易遗忘的工具：Collections和Arrays

5. 泛型

小结

    我这里走马观花一样把JCF的一些主要概念罗嗦了一下，Java的老手们可能比较厌烦，新手们可能更觉得像回顾了一下高中的数学课和大学的数据结构，呵呵。这只是一个小小的例子，可见基础知识对现实当中的应用还是蛮有指导意义的。大师们看数学，觉得那是很唯美很艺术的一样东西，西方一直都把数学区别于其它自然科学，而认为它更靠近于哲学，像我等这样整天还在为找工作烦得要死的俗人还是没法入道啊，sigh……

参考资料

• IBM developerWorks教程： Java 集合框架
• J2SE Documentation: The Collections Framework
• The Java Tutorial
• JCF API

=====================================================================

       J2SE中的类大致可以划分为以下的各个包：
       java.*，javax.*，org.*，sun.*
       除了“sun”包，其它各个包都是Java平台的标准实现，并且今后也将被继续支持。一般说来，“sun”之类的包并不包含在Java平台的标准中，它与操作系统相关，在不同的操作系统（如Solaris，Windows，Linux，Mac等等）中的实现也各不相同，并且可能随着J2SE版本不定期变化。因此，直接调用“sun”包的程序代码并不是100％的Java实现。也就是说：
“java.*”包，“javax.*”包，“org.*”包是作为J2SE的API公开接口的一部分，如果程序直接调用这些包中的API，那么程序是可以运行在所有Java平台上，而与操作系统无关；但“sun.*”包并不是API公开接口的一部分，调用“sun”包的程序并不能确保工作在所有Java平台上，事实上，这样的程序并不能工作在今后的Java平台上。
       正因为如此，“sun.*”包中的类并没有提供API文档。平台无关性是Java语言最大的优势之一，此外，SUN和Java许可证确保维持了今后API的向上兼容性（以后修改的那些有严重bug的代码除外）。这种兼容性意味着你写好的程序编译成的cl ass文件仍然可以工作在将来的版本当中。
每家实现Java平台的厂商都可以使用他们自己的方式。“sun.*”包中的类是SUN 对Java平台的实现方式，它们工作在Java 2 SDK的下层，这些类未必被其它Java 平台开发商支持。比如你的Java程序如果调用了一个名为“sun.package.Foo”的类，将有可能产生“ClassNotFoundError”的错误，同时你也将失去利用Java的一个主要的优点。
       从技术上讲，并不能防止你的程序调用“sun.*”包中的类。在版本的变迁当中，这些类可能会被删除或转移到其它包路径下，而且它的接口（包括名称、标签等）也很有可能发生变化，（根据SUN的观点，我们应当能够通过对“sun.*”包的修改来提高Java平台的性能。）在这种情况下，即便你希望程序仅仅运行在SUN的实现平台下，你仍将承受新的版本给你的系统带来破坏的风险。总之，编写依赖于“sun.*”包的Java程序是不安全的，他们将变得无法移植，无法被很好地支持。