今天翻了util包，發(fā)現(xiàn)自己對(duì)float的匱乏知識(shí)，好在有偉大的wiki百科：
http://en.wikipedia.org/wiki/IEEE_754
很清楚得解釋了IEEE 754規(guī)范

可惜看不懂lucene對(duì)small float的結(jié)構(gòu)定義。
如果按我的理解，似乎類SmallFloat的函數(shù)byteToFloat()和byte315ToFloat()有bug，通過編寫測試代碼：
SmallFloat.byte315ToFloat(Byte.parseByte("01111000", 2)得到的float值為0.5f，

但按照byte315ToFloat()函數(shù)的說明，"01111000"的mantissaBits尾數(shù)長度為3, zeroExponent為15，無負(fù)數(shù)，
而01111按IEEE 754規(guī)范，應(yīng)該理解為1，所以01111000表達(dá)的數(shù)值應(yīng)該為1.0×2^0=1，而不是0.5f
非常之tricky。

通過讀byte315ToFloat()函數(shù)實(shí)現(xiàn)，發(fā)現(xiàn)"01111000"轉(zhuǎn)換為32位值0,01111110,00000000000000000000000,
該值按IEEE 754規(guī)范的確為0.5f， 其中正負(fù)位為1位，指數(shù)(exponent)位為8位，尾數(shù)(mantissa)位為23位。

而在byteToFloat()和byte315ToFloat()的實(shí)現(xiàn)中，我們可以常看到作者將尾數(shù)位偏移24-mantissa位，
也就是說，他理解的IEEE 754規(guī)范中尾數(shù)位不是23位而是24位。

以上僅為我的猜測，因?yàn)檫€沒有看到byteToFloat()的具體使用環(huán)境。

而且通過測試代碼，發(fā)現(xiàn)byte和float對(duì)應(yīng)關(guān)系：
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的結(jié)構(gòu)，tricky!!!

swt中，默認(rèn)只有用戶線程被允許訪問UI圖形控件和一些圖形API，其他非用戶線程如果直接訪問這類資源時(shí)，SWTException直接被拋出。
如果真有這種需求，必須使用*.widget.Display類中的兩個(gè)線程同步方法：syncExec(Runnable)和asyncExec(Runnable)。方法syncExec()和asyncExec()的區(qū)別在于前者要在指定的線程執(zhí)行結(jié)束后才返回，而后者則無論指定的線程是否執(zhí)行都會(huì)立即返回到當(dāng)前線程。

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

以下載自某論壇（sorry,忘記了出處），關(guān)于內(nèi)存釋放：

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)

當(dāng)使用構(gòu)造函數(shù)來創(chuàng)建小窗口或圖形對(duì)象時(shí)，使用完時(shí)必須用手工來除掉它。
如果沒有使用構(gòu)造函數(shù)就獲取小窗口或圖形對(duì)象，則一定不能用手工來除掉它，因?yàn)槟捶峙渌?
如果將對(duì)小窗口或圖形對(duì)象的引用傳送至另一個(gè)對(duì)象，則一定要小心，仍在使用它時(shí)一定不要除掉它。與在使用圖像的插件模式中所描述的規(guī)則相似。）
當(dāng)用戶關(guān)閉Shell時(shí)，將遞歸地銷毀 shell 及其所有子代小窗口。在此情況下，不需要除掉小窗口本身。然而，必須釋放與那些小窗口一起分配的所有圖形資源。
如果創(chuàng)建圖形對(duì)象以便在其中一個(gè)小窗口的生命周期內(nèi)使用它，則在除掉小窗口時(shí)必須除掉圖形對(duì)象。這可以通過向小窗口注冊(cè)銷毀偵聽器，并在接收到銷毀事件時(shí)釋放圖形對(duì)象來實(shí)現(xiàn)。

這些規(guī)則有一個(gè)例外。簡單的數(shù)據(jù)對(duì)象（例如，矩形和點(diǎn)）不使用操作系統(tǒng)資源。它們沒有 dispose() 方法，您也不需要釋放它們。如果有疑問，則檢查特定類的 javadoc。

?

第一種方式，zkjbeyond的文章中有很詳細(xì)的說明http://www.aygfsteel.com/zkjbeyond/archive/2006/05/05/44676.html
簡單說，就是利用Ajax讀取包的.js文件后，直接使用eval()運(yùn)行代碼。

除此外，dojo還有另一種加載方式，用在調(diào)試階段（例如使用firebug活Venkman調(diào)試dojo時(shí)都需要用到，不過我沒試過使用MSE7或Visual Studio時(shí)是否需要使用這種加載方式）。

你在加載包前，將djConfig.debugAtAllCosts設(shè)置為true，那么包的加載方式會(huì)有所變化，采用第二種方式。例如：

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

此時(shí)，dojo會(huì)使用加載brower_debug.js文件，
brower_debug.js重載了函數(shù)dojo.hostenv.loadUri，這兒，不再直接使用eval()運(yùn)行，而只是把需要的包push到dojo.hostenv.loadedUris數(shù)組中。實(shí)現(xiàn)代碼：

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

從代碼可以看出，dojo為了保證加載的順序，使用dojo.hostenv.getRequiresAndProvides函數(shù)將提前依賴的包摳出來，用遞歸提前push到dojo.hostenv.loadedUris中。
而后，在代碼最后，我們只要主動(dòng)使用dojo.hostenv.writeIncludes();函數(shù)，就可一次性將被依賴的包利用document.write包含進(jìn)來。

btw:
當(dāng)然，這種方法有不少缺陷：
1、使用document.write方式加載包，會(huì)有延遲效應(yīng)，會(huì)等待本頁面中代碼都執(zhí)行完才執(zhí)行包中的代碼，自己編碼時(shí)有點(diǎn)繞，影響可讀性；
2、從上面代碼中看出，dojo會(huì)有更多的IO操作，第一dojo已經(jīng)完整讀取了包代碼，但是不馬上執(zhí)行，只是用來分析依賴關(guān)系；之后，瀏覽器又要加載一次包代碼。
3、包絕對(duì)不允許循環(huán)引用。當(dāng)然，從OO角度，不循環(huán)引用是好的方式

所以，這種方式只能用在調(diào)試期間