本来java虚拟机是这么运行的
D:\java -classpath D:\hibernate-3.0\eg org.hibernate.auction.Main

这个命令行将告诉java虚拟机的类装载器从D:\hibernate-3.0\eg\org\hibernate\auction处装载Main.class。
如果省略"-classpath D:\hibernate-3.0\eg"，即D:\java org.hibernate.auction.Main 则类装载器将会从系统环境变量CLASSPATH指定的位置寻找符合条件的Main.class。

如果CLASSPATH为.;D:\jdk150\lib\tools.jar;D:\jdk150\jre\lib\rt.jar;D:\hibernate-3.0\eg
则类装载器先查找当前运行目录(.表示当前目录)，此处为D:\，如果D:\下面有D:\org\hibernate\auction\Main.class，则装载这个文件。如果没有，继续在D:\jdk150\lib\tools.jar文件中寻找是否有路径为org\hibernate\auction\Main.class的文件,如果没有则寻找D:\hibernate-3.0\eg\org\hibernate\auction\Main.class。如果在这些路径中都没找到，就会提示一个鸟错误。注意D:\hibernate-3.0\eg只表示将在此路径下寻找D:\hibernate-3.0\eg\org\hibernate\auction\Main.class文件，不会在此路径下的.jar文件中继续寻找。

据说很多开发环境往往不去读系统路径，直接就java -classpath .....，这也就是在外面运行的东东挺溜的进了开发环境就死菜的原因喽。

在和hibernate亲密接触之后,我想按照自己的想法来设计组织机构.对于Organ,Department,Post和Stuff.我希望这样设计主键的ID,类型都是char,格式为:
Organ0000000001
Dept0000000001
Post0000000001
Stuff0000000002

修改middlegen产生的.hbm.xml文件:

......
<class
    name="com.abcdefg.hibernate.Organ"
    table="Organ"
>
    <id
        name="organId"
        type="java.lang.String"
        column="OrganId"
    >
        <generator class="hbtest.PkGenerator">
            <param name="table">PKGenerator_table</param>
            <param name="column">NextOrganId</param>
            <param name="max_lo">0</param>
 </generator>
    </id>
......
</class>

找到的资料说:"如果需要采用定制的主键产生算法，则在此处配置主键生成器，主键生成器必须实现net.sf.hibernate.id.IdentifierGenerator 接口".我找了半天都没找到net.sf.hibernate.id.IdentifierGenerator.其实只要从hibernate自身提供的一些主键生成器继承就可以,从hibernate的源文件可以看到这些主键生成器实现的接口是org.hibernate.id

我的PkGenerator.java文件:
package hbtest;

import org.hibernate.id.TableHiLoGenerator;
import java.io.Serializable;
import java.util.Properties;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.hibernate.HibernateException;
import org.hibernate.dialect.Dialect;
import org.hibernate.engine.SessionImplementor;
import org.hibernate.type.Type;
import org.hibernate.type.IntegerType;
import org.hibernate.util.PropertiesHelper;

public class PkGenerator
    extends TableHiLoGenerator {

  private String columnName;

  public void configure(Type type, Properties params, Dialect d) {
    super.configure(new IntegerType(), params, d);
    this.columnName = PropertiesHelper.getString(COLUMN, params,
                                                 DEFAULT_COLUMN_NAME);
  }

  public synchronized Serializable generate(SessionImplementor session,
                                            Object obj) throws
      HibernateException {
    Object result = super.generate(session, obj);
    String strNumber = result.toString();
    StringBuffer strResult = new StringBuffer("");
    if (columnName.compareToIgnoreCase("NextOrganId") == 0) {
      strResult.append("Organ");
    }
    else if(columnName.compareToIgnoreCase("NextDeptId") == 0){
      strResult.append("Dept");
    }
    ......

    if (strNumber.length() > 10)
      throw new HibernateException("The generated " + strResult +
                                   "Id is too long!");
    else if (strNumber.length() == 10) {
      strResult.append(strNumber);
    }
    else {
        int count = 10 - strNumber.length();
        while (count > 0) {
        strResult.append("0");
        count--;
      }
      strResult.append(strNumber);
    }
    return strResult.toString();
  }
}

实现了以后发现在这些主键前面添加"Organ","Dept"之类的并不是特别有用,而且我开始的出发点还是错的.也许我应该建立更多的映射表...?

Hibernate的初级指南

hibernate贴心的地方：

俺用了三个批处理来自动生成hibernate的文件。
 
execant.bat:
d:
cd D:\hibernate-3.0\middlegen-2.1\samples\
rem 打开build.xml修改middlegen配置
editplus.exe build.xml
ant
 
myant.bat:
call execant.bat
pause
rem 复制hbm和java文件到工程目录
xcopy .\build\gen-src\com\glacierbbs\hibernate\*.java E:\eclipse\workspace\JGlacier\src\com\glacierbbs\hibernate\ /Y /D
xcopy .\build\gen-src\com\glacierbbs\hibernate\*.xml E:\eclipse\workspace\JGlacier\src\ /Y /D
rem 替换掉hbm中的字符串
call E:\eclipse\workspace\JGlacier\cutter.bat
pause
 
cutter.bat:
e:
cd E:\eclipse\workspace\JGlacier\src
dir *.xml /d /b /a-d >hbmfiles.txt
rem 将版本2.0改成3.0
for /f %%i in (hbmfiles.txt) do strrpc /s:%%i 2.0 3.0 /c
rem 将hi/lo的max_lo由100改成0...我只需要简单的数字
for /f %%i in (hbmfiles.txt) do strrpc /s:%%i 100 0 /c
del hbmfiles.txt>nul
rem 所有hi/lo算法读的是同一个表中的不同字段
strrpc /s:Board.hbm.xml next_value next_boardid /c
strrpc /s:Post.hbm.xml next_value next_postid /c
strrpc /s:Topic.hbm.xml next_value next_topicid /c
strrpc /s:UserBasic.hbm.xml next_value next_userid /c
strrpc /s:Vote.hbm.xml next_value next_voteid /c
strrpc /s:VoteOption.hbm.xml next_value next_voteoptionid /c
strrpc /s:VoteParticipant.hbm.xml next_value next_voteparticipantid /c
cd ..
pause
 
然后，为每个hibernate生成的java类写个Adapter类...从此世界就安静了....

errorpage路径设置错误产生异常:
java.lang.NullPointerException
org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:690)
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:657)
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:805)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:778)
org.apache.jsp.index_jsp._jspSer...

从文件路径错误到NullPointerException...需要很强的想象力

书籍memo:《Tomcat 与 Java Web 开发技术详解》

怎么写一个CA程序和想写怎样的一个CA程序有关。刚看完《上帝与新物理学》，我按照书上的规则和图案写了一个世界只有20*20大小的CA，细胞的运算是一个个计算的，计算一代就刷新显示一次，一个细胞用一个字节来保存，可以原谅的是我当时连规则都不清楚，目的只是验证一下规则。

看了Alan Hensel的代码后，可能大部分写过CA程序的人都会觉得汗颜。-_-|||。体验过Alan Hensel 的LifeApplet的人就会看到:他的世界真大，实际上有2^20 * 2^20个像素；速度真快，可以设置fps(每秒刷新次数)，Generations/Frame(每次刷新间隔生产多少代)，如果设置为warp，CPU就会撒开腿跑起来...还可以设置规则，CA的规则不止Conway的那个，其它的也很有趣。

数据结构：
LifeCell:
Alan Hensel将世界分成一个个16*16的单元，用LifeCell类表示。每个LifeCell包含两个数组表示 p[]，q[] = new short[16]，总共16*16 bits，表示16*16个细胞。并且在这个数组中按照一种奇怪的方式来排列，比如LifeCell中坐标为(1,1)的点在数组中的位置是65(见LifeCell文件)，代表这个点的bit就在p[6](和q[6])的左起第5位。为什么要这么表示？我想是作者为了以后unroll算法的方便。他究竟怎么得出这个方法的，我不知道。。

每个LifeCell需要两个数组是因为CA的算法要求的运算必须是并行的。所以只能p生成q,q生成p，没什么好说的。

每个LifeCell保存了相邻的东、西、南、北、东南、东北、西南、西北的LifeCell的指针。
保存了上一个，下一个LifeCell的指针。所有LifeCell保存在一个链表中。
保存了上一个，下一个需要显示的LifeCell的指针，用于显示。
保存了一个Down的LifeCell的指针，用于hash查找。
保存了坐标x,y。
保存了一些状态，qstate,pstate,flags为运算和优化用的。

LifeHash:
因为所有LifeCell都放置于一个链表。而经常要用LifeCell的坐标来查找LifeCell，比如修改某个点的状态：为了在某个点放置一个细胞，需要通过点的坐标运算出LifeCell的坐标，再通过LifeCell的坐标找到LifeCell对象。
在链表中查找一个对象的运算复杂度是o(n)。n在此处最大可达2^16 * 2^16(把整个世界都占满，这也相当不容易)，所以对于一些超大的CA来说，查找起来会很浪费时间。。。所以有了LifeHash类。

LifeHash中保存了一个2^HASHSIZE * 2^HASHSIZE的LifeCell对象指针数组，数组中每个对象维护一个链表，坐标x,y中低HASHSIZE位的值一样的LifeCell放在这个链表中。通过x,y可以快速找到这个链表，然后用上面说到的Down指针，比较(x,y)来找到具体的LifeCell。这样理论上来讲减少了查找时间...(我算不出来，哈)。究竟用多大的HASHSIZE才好？作者的值是6，就是占用了2^12 * sizeof(int) = 16k bytes内存。

LifeRules：
LifeRules的目的在于把用字符串表示的规则转化成一个bool[512]。
比如"23/3"表示有2个或3个相邻细胞的细胞继续存活，如果一个位置旁边刚好有3个细胞，这个位置在下一步就要长出一个细胞。
由于一个位置有8个相邻的位置，加上自身为9位。把9个位置排序得到一个数，总共512个。比如对于0xC8，表示西北、西有细胞，自身有细胞，根据"23/3" bool[0xC8]的值应该为true。

算法：
为了提高效率，Alan Hensel把LifeCell中每个4*4的运算都unroll了。所以在LifeGen文件中可以看到进一步的setRules(boolean[] Rule)函数，这个函数设置了了crunch(和munch)= new short[65536]。原理和LifeRules中类似，就是不知道这个运算过程怎么得出的，作者数学肯定非常好。。

因为细胞的运算是以LifeCell为单元来运算的，一个单元的细胞会影响到相邻的单元。如果每次运算的时候都考虑相邻8个LifeCell的话，会造成CPU的浪费。所以在LifeGen中可以看到运算p状态和q状态时，LifeCell的位置是不一样的。从p状态生成q状态时，检查了东、南、东南方向相邻的LifeCell，生成的q状态的位置为p状态往东南各偏移一个细胞。所以如果p状态起始坐标为16x,16y，那么q状态时，起始坐标是16x+1, 16y+1(注意坐标系映射为MM，x在往东方向为正，y在往南方向为正)。在从q状态到p状态时，检查西、北、西北方向相邻的LifeCell，回到p状态的位置。

其中具体的运算就算了吧，反正我没看明白。看明白的地方也不知道为什么。。作者太强悍了。

线程：
这种程序当然至少要两个线程了，一个UI线程，一个Work线程。UI线程在LifeFrame中，没做什么事，就是把事件发送给Life对象(见Life.Java)，Life收到事件后并没有马上处理，而是放到一个队列中LifeQueue。
UI线程一启动，就启动了work线程。
在Life的run()中，处理细胞的繁衍LifeGen.generate()，显示，然后处理LifeQueue中的事件。
在LifeGen.generate()中控制生成繁衍的次数和显示的速度。
为什么两个线程同时对LifeQueue操作却没有声明synchronous呢？对java不熟，不敢妄言。

有空还可以继续研究。先到此为止。反正作业就这么稀里糊涂交上去了。

原文:http://www.ibiblio.org/lifepatterns/lifeapplet.html

 当前版本0.41d，更新时间2001-1-31，比0.41c版(199-1-22)上提高了些性能。新版本在计划中，只要我的空余时间允许。
 作者:Alan Hensel,

简介：
认识我的人都知道我为什么写这个程序。不是为了学习Java，不是为了提高我的网站的访问量，原因很简单：
我收集Life patterns，而且我喜欢展示它们

当然，这些patterns中的大部分是别人发现的。没人想要从这些Life patterns中获利，所以据我所知这些patterns将留给后代并被赏识，就象国际象棋一样。

请不要给我写信说：我喜欢你的程序，却忘记提起这些patterns。这听起来会象是恭维集邮爱好者他的邮册如何漂亮，对邮票却只字不提。我的程序只是做了它们该做的事情而已。

计算机软件和硬件只是使用者和他的数据之间的工具。

这些patterns让人赞叹。如果不信，你可以自己去做一个试试。(我希望这个挑战能促成一些发现。)

给那些写Life程序的学生：
我没有可以给你的源代码。这里没有你找的东西。我提供了这个程序的源代码，但它们超出了计算机课程的范围。它们之所以这么复杂是因为速度优化(这样我才能运行"Breeder"或者其它更大的patterns)。当然，你可以试着读读源代码，但不要强迫自己。你写的作业应该比这个程序简单一百倍。

给来这里学习Java applets的读者:
这是我第一个真正意义上的applet。最好别打算把我的代码拷贝到你的程序中。源代码就在这一页的底部，你可以免费下载，当然，你必须为它付出些东西。若非如此，这将会是一个让人相当有学习动力的applet程序。

你怎么做到这么快的？
好的。没有留心的话也许你不会发现我的程序闪电一样的快。你也许没看到"Warp Speed"按钮，或者你还没用过它，或者你觉得这无所谓。这样的话你可以跳过这个部分。
有人问，你究竟是怎么让它跑得这么快的？！对于这些好奇者，或者那些打算写自己的超级细胞自动机程序的人，我会解释的。

我倾向于把细胞自动机的优化和数据压缩联系起来。这也是一个简单的概念却需要复杂的方法。究竟什么才是最好的方案取决于数据本身。对于康威的Life，倾向于出现点状的图案。

对于点状分布的世界，我们应该考虑把它分割成近似大小的块。对于Life来说，4x4和8x8都是可取的。我选择了8x8，因为:刚好8比特1字节，我曾经考虑过4x4，但运行起来效果不大好。

并且请注意：如果pattern长大并超过了块的范围，需要引入新的块。你可以简单的线性搜索，也可折半查找，或者维护某种映射。我的方法是哈希表。这个表只是用来查找一个新块的邻居。每个已存在的块已经有它的邻居的指针，并且会被多次使用。

必须有高效的算法来处理这些块内部的数据，我选择一次处理块中的所有数据。在处理完整个块之前不需要跳转语句。换句话来说：所有内部循环都被unroll了，并使用了高速的查询表。

注意：CA(细胞自动机)程序一般性的包含了两个主要循环(加上一个显示循环)，因为CA规则要求对细胞进行并行处理，但微处理器是线性的。这意味着必须有世界的两分拷贝，这样创建下一代的时候本身的信息才不会被破坏掉。通常这两个拷贝是不对称的。这对我来说相当麻烦，因为每次我从这边取出些东西进行优化，不得不在另一边加点别的什么！几乎每次，例外的情况导致了最好的优化。特别的,需要在位操作：位移，屏蔽和重组之间折中来找一个最好的查找表。

有时块中的细胞会出现稳定的情况，不需要进一步处理。你可以把块从队列中移出，把它设置成“冬眠”状态，只有当邻近的块影响到它。这些块不需要占用处理器的时间，象空白的区域一样。

检测周期为2的振荡器并把它移出处理队列并不难。这对于Life程序是值得的，因为blinker是最常见的随机的残余物。更复杂的振荡器相对比较少见。检测并模拟滑翔机也是可能的。这些方面的优化会得到递减的效果，除非你做到极致。(如HasLife)。

同样，死亡状态：空的块不必马上释放并从哈希表中移走。那样会占用更多的处理器时间，尤其是当振荡器在一定空间内移进移出的时候。仅当可用内存已经很少的时候，才从死亡队列中移除最老的死亡的块。

当程序快到一定程度，必须考虑刷新显示的速度不需要超过人眼可以感知的速度，或者最少不需要超过显示器的刷新频率。特别是在视窗环境，显示时间会是效率的瓶颈。

源代码
以下是我的超级快速的Game of Life applet源代码。
很抱歉这些不是百分百面向对象的。Game of Life并不适合面向对象技术。面向对象适用于你碰到的大多数问题，除了那些效率第一而且相当复杂的项目，康威的Game of Life正好属于这种情况。

以下是16个源文件:

LifeButton.java
LifeFrame.java
Life.java
LifeGUI.java
LifeGen.java
LifeCell.java
LifeHash.java
LifeCoordinate.java
LifeRules.java
LoadBox.java
RuleBox.java
SpeedBox.java
OptionsBox.java
LifeQueue.java
LifeCallback.java
DescribeBox.java