今天翻了util包，发现自己对float的匮乏知识，好在有伟大的wiki百科：
http://en.wikipedia.org/wiki/IEEE_754
很清楚得解释了IEEE 754规范

可惜看不懂lucene对small float的结构定义。
如果按我的理解，似乎类SmallFloat的函数byteToFloat()和byte315ToFloat()有bug，通过编写测试代码：
SmallFloat.byte315ToFloat(Byte.parseByte("01111000", 2)得到的float值为0.5f，

但按照byte315ToFloat()函数的说明，"01111000"的mantissaBits尾数长度为3, zeroExponent为15，无负数，
而01111按IEEE 754规范，应该理解为1，所以01111000表达的数值应该为1.0×2^0=1，而不是0.5f
非常之tricky。

通过读byte315ToFloat()函数实现，发现"01111000"转换为32位值0,01111110,00000000000000000000000,
该值按IEEE 754规范的确为0.5f， 其中正负位为1位，指数(exponent)位为8位，尾数(mantissa)位为23位。

而在byteToFloat()和byte315ToFloat()的实现中，我们可以常看到作者将尾数位偏移24-mantissa位，
也就是说，他理解的IEEE 754规范中尾数位不是23位而是24位。

以上仅为我的猜测，因为还没有看到byteToFloat()的具体使用环境。

而且通过测试代码，发现byte和float对应关系：
10000,000==2.0f= 1*2^1
10001,000==8.0f=1*2^3
10010,000==32.0f=1*2^5
01111,000 = 0.5f = 1*2^-1
01110,000==0.125f= 1* 2^-3
完全看不出合理的small float的结构，tricky!!!

swt中，默认只有用户线程被允许访问UI图形控件和一些图形API，其他非用户线程如果直接访问这类资源时，SWTException直接被抛出。
如果真有这种需求，必须使用*.widget.Display类中的两个线程同步方法：syncExec(Runnable)和asyncExec(Runnable)。方法syncExec()和asyncExec()的区别在于前者要在指定的线程执行结束后才返回，而后者则无论指定的线程是否执行都会立即返回到当前线程。

例子:
Display.getCurrent().asyncExec(new Runnable() {
　public void run() {
　　butt.setText("Push");
　}
});

以下载自某论坛（sorry,忘记了出处），关于内存释放：

Rule 1: If you created it, you dispose it.
Rule 2: Disposing the parent disposes the children.
(from http://www.eclipse.org/articles/swt-design-2/swt-design-2.html)

当使用构造函数来创建小窗口或图形对象时，使用完时必须用手工来除掉它。
如果没有使用构造函数就获取小窗口或图形对象，则一定不能用手工来除掉它，因为您未分配它。
如果将对小窗口或图形对象的引用传送至另一个对象，则一定要小心，仍在使用它时一定不要除掉它。与在使用图像的插件模式中所描述的规则相似。）
当用户关闭Shell时，将递归地销毁 shell 及其所有子代小窗口。在此情况下，不需要除掉小窗口本身。然而，必须释放与那些小窗口一起分配的所有图形资源。
如果创建图形对象以便在其中一个小窗口的生命周期内使用它，则在除掉小窗口时必须除掉图形对象。这可以通过向小窗口注册销毁侦听器，并在接收到销毁事件时释放图形对象来实现。

这些规则有一个例外。简单的数据对象（例如，矩形和点）不使用操作系统资源。它们没有 dispose() 方法，您也不需要释放它们。如果有疑问，则检查特定类的 javadoc。

第一种方式，zkjbeyond的文章中有很详细的说明http://www.blogjava.net/zkjbeyond/archive/2006/05/05/44676.html
简单说，就是利用Ajax读取包的.js文件后，直接使用eval()运行代码。

除此外，dojo还有另一种加载方式，用在调试阶段（例如使用firebug活Venkman调试dojo时都需要用到，不过我没试过使用MSE7或Visual Studio时是否需要使用这种加载方式）。

你在加载包前，将djConfig.debugAtAllCosts设置为true，那么包的加载方式会有所变化，采用第二种方式。例如：

   djConfig.debugAtAllCosts=true;
    dojo.require("dojo.widget.TimBar");
    dojo.hostenv.writeIncludes();

此时，dojo会使用加载brower_debug.js文件，
brower_debug.js重载了函数dojo.hostenv.loadUri，这儿，不再直接使用eval()运行，而只是把需要的包push到dojo.hostenv.loadedUris数组中。实现代码：

                var text = this.getText(uri, null, true);
		var requires = dojo.hostenv.getRequiresAndProvides(text);
		eval(requires.join(";"));
		dojo.hostenv.loadedUris.push(uri);  //push要加载的包到loadedUris数组中
		dojo.hostenv.loadedUris[uri] = true;
		var delayRequires = dojo.hostenv.getDelayRequiresAndProvides(text);
		eval(delayRequires.join(";"));

从代码可以看出，dojo为了保证加载的顺序，使用dojo.hostenv.getRequiresAndProvides函数将提前依赖的包抠出来，用递归提前push到dojo.hostenv.loadedUris中。
而后，在代码最后，我们只要主动使用dojo.hostenv.writeIncludes();函数，就可一次性将被依赖的包利用document.write包含进来。

btw:
当然，这种方法有不少缺陷：
1、使用document.write方式加载包，会有延迟效应，会等待本页面中代码都执行完才执行包中的代码，自己编码时有点绕，影响可读性；
2、从上面代码中看出，dojo会有更多的IO操作，第一dojo已经完整读取了包代码，但是不马上执行，只是用来分析依赖关系；之后，浏览器又要加载一次包代码。
3、包绝对不允许循环引用。当然，从OO角度，不循环引用是好的方式

所以，这种方式只能用在调试期间