大家都是对软件充满无限激情的人，大家都致力于能开发出能被大家所广泛接受和使用的软件。可是激情归激情，我们还得脚踏实地。项目遇到了障碍，我们需要改变思路。

从04年的12月末到现在，大家好像都不约而同地沉寂了下来，好像大家都累了或者都在反思着某些事情，大家好像都有一个感觉就是我们对我们所要做的并不是那么的熟悉和了解。我们并不能详细而又清晰的勾勒出我们要做的东西的轮廓。想象一下一个没有吃过“葱烧海参”的厨师做出的“葱烧海参”会是个什么样子呢？也许可以吃，但最大的可能是变了味儿。在Dreamhead的题为“Dominoo的方向”的mail中也提到“创新的前提是什么？绝不是凭空制造。了解已有的东西，在此基础之上找到不足之处，再图改进。”的确我们了解的太少，我坚信我们要做的东西会是一个“innovation”，但是想归想，真正做起来我们还是要考虑方法的，还是那句话“脚踏实地，厚积而勃发”。

针对以上项目出现的问题，我们改变了思路。Dreamhead语“对于Dominoo而言，对于现在的我们而言，我们面对的是一大片开阔地，虽然那里已有人迹，但我们尚未过去。”我们要走过去看看，看看人家的做法，做到知己知彼。

我们决定从下列角度切入：
* 了解工具：现有的开源UML工具、MDA工具
* 了解新技术理论：AOP、DSL、LOP等
* 了解基础技术：语言特性、编译器技术。

在一个朋友的书架上发现王森著的《Java深度历险》一书，看了书的前言了解该书是关于Java底层技术内幕的。怀着好奇心浏览了一下，谈不上有太多收获，但也记下了一些自认为有益的两点。

* Java xxx

我们在命令行下敲入：“java xxx”后会发生什么呢？

流程如下：
1.找到JRE；
2.找到JVM.dll；
3.启动JVM，并进行初始化；
4.产生Bootstrap Loader；
5.载入ExtClassLoader；（Ext – Extended）
6.载入AppClassLoader；
7.加载xxx类。

书中提到Bootstrap Loader、ExtClassLoader和AppClassLoader构成了Java的“类加载器继承体系–class loader hierarchy”,其中Bootstrap Loader是由C++编写的，其他两个是由Java写的。之所以成为“继承体系”是因为这三个loader之间是有联系的。Bootstrap Loader负责加载ExtClassLoader，后者ExtClassLoader就将其parent置为Bootstrap Loader。AppClassLoader较为特殊，虽然由Bootstrap载入，但是其parent却置为ExtClassLoader。其原因是为了实现“委托模型”。简述“委托模型”就是当类加载器有加载类的需求时，会先请求其parent使用其搜索路径帮助加载，如果其parent找不到，才使用自己的搜索路径进行加载。如上述所说当ExtClassLoader想载入AppClassLoader类时它首先请求其parent “Bootstrap Loader”帮忙，Bootstrap Loader将AppClassLoader载入后，由于这个载入是ExtClassLoader请求的，所以AppClassLoader的parent还是置为ExtClassLoader而不是Bootstrap Loader。

* 类的加载流程
类加载的时候遵循一个原则：“类加载器会依类的继承体系从上至下依次加载”。举个例子：“如果C继承了B并实现了接口I，而B有继承自A”，则类加载器在加载C时，加载的次序会是A->B->I->C，（注：interface会如同class一样被Java编译器编译为独立的.class文件）

其实我对底层的东西并未给与太多的关注，如果在哪个项目中需要我去了解底层的话，我会去很好的学习。