Netbeans Top Ten APIs

這兒記錄了 Netbeans Top Ten APIs 的影片中的重點：

1. Run time container由五個 APIs 構成：Bootstrap、Startup、Module System、File System、Utility。最小的 Netbeans platform application 只依賴這五個 APIs。
2. Starup API 提供了 Main。
3. Module System API ： Module 可以有個 ModuleInstaller class 來管理 Module 的生命周期。
4. Utility API：Utility API 中最重要的是 Lookup API。扮演 ServiceLoader 的角色。也使用 JDK 6.0 的 ServiceLoader 實現。Service Provider packages 在 src/META-INF/services Folder 中列出提供的 Services。
5. Window System API：TopComponent 取代了 Swing 的 JFrame 的功能。Editor、View及Mode的概念。可使用 layer.xml 及相關的檔案來建造新的 Mode。在 project.properties 中可以以 run.args.extrac=--nosplash 來抑制 splash 畫面。可以在 Properties中的 Window System API 來限制使用者的對 Window 的操作。
6. File System API：介紹了 layer.xml，以及 File System API 中的 Repository、FileUtil、FileObject。FileObject 包裝了 java.io.File，提供更強大的功能。FileObject 和 java.io.File 的轉換可由 File.Util 內的函式實現。Netbeans 提供許多 File Systems，例如 layer.xml 對應的 System File System，磁碟上的 File System，以及可以 FileUtil 建立的 memory file system。
7. 
   

學習 Netbeans Platform 時閱讀的文獻

以下列出我學習 Netbeans Platform 時閱讀的文獻。

• Top Ten Netbeans APIs

以上文獻是英文的 Videos，有時聽來有點困難，因此我還閱讀以下的文獻。

和 Runtime Container 有關的文獻：

和 Lookup API 有關的文獻：

• Creating Extensible Applications With the Java Platform
• Class ServiceLoader

同時為 VisualStudio/Eclipse/Netbeans 開發，可能嗎？

和朋友談及某些公司有同時為 VisualStudio/Eclipse 開發產品的需求。可能嗎？

今日偶然從 Eclipse E4 的 forum 讀到 eFace ，顯然就是針對這樣的需求。

iPad 的出現象徵 Intel 覇權的結束嗎？

前幾天 Apple 發佈 iPad 時，我注意到 iPad 使用的 CPU A4 竟然不是 Intel 的 CPU，而是 ARM 。為此我瞭解了一下原因：這和 ARM 精簡的指令集有關。ARM 的指令集使得 CPU 不必花費太多的電路於指令解碼，這使得 ARM 能以低耗能的方式執行程式，因此被廣泛用於智慧型手機之中。

剛才讀了一篇有趣的文章。

Is the iPad the beginning of the end for intel

文章說 iPad 的出現是否代表 Intel 的沒落？作者作出了以下的觀察：

1. Intel 保証 80x86 指令集的相容性的同時不可能滿足低耗能 CPU 市場的需求。
2. 智慧型手機市場是低耗能 CPU 的市場。
3. 提供雲端運算的這些大公司如 Google 、Amazon 愈來愈關心伺服器的耗能問題。因此伺服器也是低耗能 CPU 的市場。
4. iPad 證明低耗能 CPU 有潛力侵入 Intel 的 PC 市場。
5. GCC 的發展使得原本為 Intel 平台寫的 C 程式可以容易重新編譯後在其他平台上執行。

作者因此質疑是否 iPad 的出現代表了 Intel 世代的結束以及 ARM 覇權的來臨。這的確是很有趣的想法。但是我們不能忘了微軟的存在。除非微軟放棄了 Intel 平台，否則 Intel 還有很多年可以存活。畢竟主宰 PC 市場的不是 Intel 而是 Wintel，是微軟和 Intel 兩大覇權的結盟。

Swing vs. SWT (II)

接續之前的文章，SWT有以下的優缺點：

SWT 的優點：

1. 和底下平台一致的風格(Look and Feel)。
2. 和 Eclipse 的整合。
3. 雖然同樣不是 thread-save。但誤用時會發出異警，在這點上容易除錯。 

SWT 的缺點：

1. 不內建於 JRE 中，因此必須下載特別的函式庫才能執行。
2. 因為使用底下作業系統提供的元件，無法以 java 的 Garbage collector 管理，必須自行管理元件的記憶體，因此容易有 Memory leak。當元件之間的關係是靜態時，只要釋放最上層的元件的記憶體就好，問題會輕些。如果元件之間的關係是動態的，就比較會有 Memory leak了。
3. 不容易製作客製化元件，因為要客製化時常必須瞭解底層作業系統的 API。

有關 SWT 的迷思：

1. 在比較 SWT 和 Swing 時，常誤以為 Swing 的功能比 SWT 強大。但是真正該比較的常是 SWT+JFace 和 Swing，甚至是 Eclipse 對 Netbeans。

Swing vs. SWT (I)

最近基於工作需要閱讀有關 Swing 和 SWT 的比較。以下是我的心得。

Swing 的優點：

1. 內建於 Java JRE 中，只要有 java JRE 就能執行。不必另行下載函式庫。跨平台特性勝過　SWT。
2. 能以 Garbage Collector 管理元件，因此減少了 Memory leak 的風險。
3. 容易對元件客製化，不必瞭解底層作業系統提供的元件。這些客製化的元件馬上具有跨平台的特性。
4. 可以做出完全不同於底層作業系統風格(Look and Feel)的 GUI。

Swing 的缺點：

1. 建造 Swing 元件的程式都必須在 Event-dispatching thread 或是 Worker thread 中執行，而且必須選對 thread，否則會有 GUI 反應太慢、或是顯示出狀況的情形。當沒有使用 thread 或是該用 worker thread 時沒使用 worker thread 的情形下，程式不會發出任何警告，這類的錯誤很難診斷。目前有些輔助的工具，但尚未和 IDE 整合。
2. 主要的 IDE 是 Netbeans。Netbeans 多用於個人私下的開發案。大多數的企業使用 Eclipse，因此選擇 SWT。
3. 如果想使用 Eclipse RCP。就不適何用 Swing。
4. 因為 Oracle 併購了 Sun，使得許多人對 Netbeans 的前途感到疑慮。連帶也對 Swing 感到疑慮。
5. 因為 Sun 在過去幾年力推 JavaFX，使得許多人對 Swing 的前途感到疑慮。

有關 Swing 的迷思：

1. Swing 的速度比 SWT 慢：在 SWT 當推出時猛烈攻擊 Swing 速度慢的弱點。但這幾年 Swing 的速度已經追上，除非該用 Worker thread 的地方未使用 worker thread，否則速度已經沒有明顯的差距。
2. Swing 不支援底層作業系統的風格(Look and Feel)：這也是當年 SWT 攻擊的重點。但是如今 Swing 可以支援各種風格，包括底層作業系統的風格。