候選結果有：
對Strings 轉換狀態的支持：
對於最求靈活多變喜好Strings的Java開發者，這可說的上是壹個莫大的福音了，這個特性可以幫助他們避免較長的if-then-else造成的擁堵。但是，從我個人的角度，認為既然我們最求的是靈活性，那麽Strings的性能將遠遠優於Emuns,所以沒有必要尋找特別的轉換裝置。正因此，我並不十分推崇這個特性。
多異常捕獲機制：
能夠壹次捕獲多個相關異常縱然是很方便，但介於非檢查異常和在框架多層結構中捕獲異常時，這個功能有時反而會越幫越忙，所以我也不十分推薦這個特性。
對集合的方括號標記：
這項特性可以讓集合像數列壹般變得井井有條。但也有人爭辯，正是因為集合的語法更加方便和自由才讓大家更喜歡使用，這樣把它和數列的語法同化，只會磨滅它原本的特性。因此，這項我也不很推薦。
帶有類型推導的簡潔構造器：
這個特性可以通過基於實例化對象數據類型的構造器，讓編譯器了解泛型，而不需要目再重新定義泛型。但是很多人認為，這是個很糟糕的主意，因為這意味著磨滅了Java語言原本的有點。我個人雖然不介意，但是也不推薦。
月份: 2011 年 3 月
企業級Windows 7遷移不可缺少的利器
在為企業環境列舉出XP到Windows7的遷移工具名單前，我們先來看看那些可用的壹站式工具和企業環境遷移工具的區別是什麽。解決方案供應商都應該知道，企業在進行遷移時壹般會有很多危險。
這意味著，在遷移過程之前、之中和之後，在為大量用戶和壹般應用庫的大小來維持工作中的桌面環境到達企業必須保留的有用訪問時並沒有太多空間犯錯。
對大部分個來來說，最大的問題來自於企業壹般會為用戶基礎維護的大型應用庫，它也是人力、程序資源和大型Windows XP到Windows 7遷移計劃中最大的消耗者。個人和企業應用程序的區別主要在於企業用戶的授權是批量授權。大多數臺式機上安裝的應用程序壹般都少於200個，而企業應用程序則有1000到5000個，所有這些應用程序都安裝在企業網絡的計算機中。
處理應用程序是遷移過程的壹部分。首先，需要確定哪些應用程序在遷移過程中可以不用擔心，哪些應用程序需要壹些額外修復。這對於關鍵應用、自主開發或定制的桌面應用程序尤其如此。修復往往需要大量時間和精力編程來確保在Windows XP下的應用程序能夠在Windows7上運行。這也有可用的替代辦法，如Windows XP模式為基礎的環境中，這種環境下不需要編程，而且可以讓舊代碼在標準的原生Windows7環境中運行。
成功遷移的關鍵是如何處理這些應用程序的問題，這就是為什麽對它們進行分析和自動化的補救措施非常重要。表1列舉了具有這些功能的產品，但它取決於妳對客戶環境的深刻理解和對風險的全面識別。
不要忘記，分析和修復只是第壹步。下壹步是進行測試和部署。這往往涉及不同的工具。因此，在下表中的某些選項必須看成是互補關系而不是競爭關系。價格估算取決於客戶端的總數和其它授權問題。壹般來說，客戶端數量越多，單價越低。
如何搭建Oracle SOA Suite
搭建壹個從開發到部署的完整的Oracle SOA環境，需要以下三個產品：
Oracle數據庫
支持版本有：9i、10g、olite和XE。
JDeveloper（IDE）
JDeveloper是壹款開發利器，裏面不僅集成了Oracle自己的J2EE開發框架還提供了便捷的單元測試、Oracle數據庫客戶端和部署應用程序等功能。除了Oracle自己還有許多開源團隊在不斷奉獻著精彩的plugin。但是坦白的說，Jdeveloper的性能不是十分理想，比較耗費內存，有時會發生窗口“白化”。我曾經問過幾個Developer，他們給我的回答是：“壹個東西功能太強大了，包含太多的東西，有時會…”，我知道這不是壹個滿意的答案，但是我清楚的知道，如果妳將來的工作都是與Oracle的產品相關的話，JDeveloper絕對是正確的選擇。這裏我給出的，呵呵，應該Oracle官方給出的推薦的最小內存是512M。
SOA Suite
請關註“hot-pluggable”，我給它的解釋就是“熱插拔”，因為包括BPEL、ESB、RULES和EM等在內的component（組件）都是作為應用程序部署在OC4J上的，妳可以隨意的start、stop、deploy或deploy。