iT老爸碎碎唸

Nespresso PIXIE C60 開箱

喝咖啡已經變成了每天的習慣，但每天去外面買好貴，我的星巴克隨行卡有13點紅利，你就知道我花了多少錢在星巴克上，還不算其它像是全家或是-4買的咖啡。可是自己家裡搞台傳統的咖啡機也蠻麻煩的，主要是喝的量沒有那麼大，咖啡豆放在機子裡，太久味道也會變。如果要現磨現泡，又太搞工了(台語)，沒那種美國時間。

自從小舅子他家看過Nespresso這麼方便的咖啡機後，加上看到網路上網友分享的Nespresso 咖啡機，心裡就很癢，網路上查了一下資料，雖然台灣也有代理 Nespresso (信義誠品美食街那有攤位)，不過機型不多, 網路上大家都還是去日本或是香港買。剛好這週出差到深圳，趁週末時殺到香港中環 IFC Mall裡面的 Nespresso 專賣站，狠下心來，給它敗下去了！

妹子生日送把拔的禮物是什麼呢？(咦)…

哇!! 是大銘鼎鼎的 Nespresso 咖啡機耶！而且是台灣買不到的 PIXIE 機型喔!!

來看看它的廬山真面目

登登!! 是漂亮的橘色！真是美啊~~

正面照來一張

上空照(哈~)

把水箱加水，準備來煮咖啡囉~

把水箱掛上

全機只有三個按鈕，後面中間的電源開關(黑)，另外兩個發亮的是大杯、小杯按鈕

前面也會發光喔~~

隨機附贈的全16種口味的咖啡膠囊, 目前市面上買得到的就這16種啦! 不過聽說還有限量的口味

喝哪一種好呢？

先最咖啡因最低的 Decaffeinato (Fruity and delicate Intensity 2)

打開彈匣

投彈

膠囊在彈匣中了

看了說明圖示，是要泡小杯的，所以就按下小杯的按鈕....

泡好了耶! 呃...水量好像不太對，看起來不是 40ml, 而是更小的25ml, 而且好酸啊~~

退彈後，用過的膠囊會掉到下方的盒子裡，抽出來就可以看到了

把膠囊拿出來瞧瞧(好燙)，正面被搓了好多個小孔(5x5)

背後只有三個孔

真的是很方便，不過要先16種口味全試過，才知道自己偏好哪幾種啊！因為去店裡買膠囊，每種口味一條就是10個，買到不喜歡喝的，就很痛苦啦!!

另外還有一件比較麻煩的事就是電壓的問題，香港買的話，電壓是220V；日本買的話，電壓是100V。網路上分享的說是日本的好像直接用台灣的110V也還好，但香港的220V就要想辦法啦...總不能在冷氣機下泡咖啡吧 :P

有朋友是請水電再從總開關那裡拉另一個220的插座，看來這是唯一的方法了。

來看看操作的影片吧！

Flash

Nespresso

未完．待續~

終於!! 拿到了六萬塊的得獎資格！不過這屆大家都好強啊，好多人分享了不少比我更好的知識和文章，看來重金之下，真的能引出勇夫們來做很棒的分享。也因為有這樣的動力，才能完成整個 Java SE 7 新功能的研究。

最後三個主題， NIO2，Concurrency Updates(JSR-166y) 還有 Da Vinci Machine (JSR-292)，都還沒完整深入的介紹，雖然已經滿三十篇文章了，但在比賽結束前的這幾天，我會找時間把它們給補上，讓這個系例的文章能完整！

最後，請大家期待最新改版的 Java 全方位學習 (Java SE 7增修版)~ 不過要等到明年了吧 :P

NIO2

Java SE 在 1.4 時加入了 NIO (New I/O) 的新API，事隔多年後，在 Java SE 7 裡加入了第二代 NIO - NIO2 (JSR-203)。

第二代的 NIO2 新增了三個主要的功能：

1. File System API 的增強

2. Asynchronous IO

3. 其它

[b]**********[/b]

File System API 從 Java 1.0 開始，十幾年來一點都沒改進，而且功能少的可以！這次的 NIO2 總算增強、補齊了這塊拼圖。主要的改進有：

[b]* 不同平台的完整支援[/b]

早期的 File System API 不論是對 Windows 或是 Linux 平台的檔案系統都不友善，你只能用它來做基本的檔案存取，沒有辦法做進階地處理，像是檔案的權限等…。而新的 File System API 則是依各個平台的不同，而有不同的實作，能完整地支援各個平台其檔案系統的特色。而且程式開發者可以透過標準且統一的介面，來操作檔案系統，不需要擔心底層到底是什麼平台。

[b]* 完整的檔案操作[/b]

舊的 File System API 只能簡單地刪除檔案，想要拷備或是搬移檔案，都得自己處理。而新的 File System API 提供了完整的拷備(copy)、搬移(move)和刪除(delete)的方法，讓你能輕易地操作這個檔案。

[b]* 檔案捷徑(symbolic link)的支援[/b]

檔案捷徑不是一個完整的檔案，而是某一個實體檔案的替身，因為它不是一個完整的檔案，所以舊的 File System API 並沒有辦法正確的處理它，現在透過新的 File System API 就沒這個困擾了。

[b]* 完整檔案屬性的存取[/b]

一個檔案有許多不同的屬性(attribute)，例如是誰建立了這個檔案？哪些人有這個檔案的存取權限等…而不同的平台上會有一些該平台特別的屬性，像是隱藏檔案的屬性，在Windows 和 Linux 平台上就不一樣。新的 File System API 提供了完整存取不同平台檔案屬性的方法。

[b]* 其它 [/b]

其它新的 File System API 功能有，像是能走訪整個目錄(包含目錄下的檔案及其子目錄)的 File tree walk API；還有檔案系統的監看API (WatchService)，你可以用它來監看檔案系統裡有哪些檔案被新增、修改或刪除了。還有像是檔案過濾器(Glob)，你可以在讀取檔案列表時，設定你要的過濾條件，只列出你想要的檔案，例如所有的 .java 檔案或是 .jpg 案。新的 File System API 真的是大大補完了原本所欠缺的功能，應該能滿足你絕大部份的檔案操作需求。

[b]**********[/b]

在 Java SE 7之前，所有的 I/O 操作都是同步的(synchronous)，所謂的同步操作是指檔案存取時，程式必需等在那裡，一直到檔案資料都讀完/存完後，才會執行下一行程式碼。而 asynchronous 是非同步的意思，跟同步最大的差別在於，例如我要把一張很大的圖片存起來，我只要執行了存檔的程式碼後，程式就可以去執行別的程式碼，當存好後，Java 會自動通知你存好了，然後你再回來處理下一個動作。非同步 I/O 對於大量的檔案處理是巨大的檔案處理時，非常地有效率，程式不會因為長時間的檔案存取，而整個程式像當機一樣卡在那裡。

[b]**********[/b]

其它新的 NIO2 的功能還有支援 GB 級的存取緩衝區(buffer)、網路廣播(Multicasting)等。

NIO2 的東西實在太多了，在這裡只能給大家一個簡單的介紹，有興趣的讀者可以進一步查閱 NIO2 的相關文件，筆者也會慢慢地把相關的範例程式給補上，敬請期待~

JDBC 4.1

JDBC 是 Java Database Connectivity 的縮寫，它是讓你的 Java 程式跟資料庫溝通的一組 API，透過這個統一的 API 介面，你可以連接各式不同的資料庫系統，對資料庫裡的資料做新增、刪除、修改、查詢等動作。

Java SE 7 裡支援 JDBC 4.1 的規格，跟JDBC 4.0 版比較起來，有兩個主要的改進。第一個就是前面也介紹過的 try-with-resource 語法的支援，第二就是新的 RowSetFactory 這個新的 API。

前面在介紹(第21到24天) try-with-resource 語法時，我們只介紹了 java.io 的部份(還有自創的類別)，而 JDBC 4.1 裡的 [b]java.sql.Connection[\b]、[b]java.sql.ResultSet[\b]、[b]java.sql.Statement[\b] 這三個介面(interface) 也都繼承了 [b]java.lang.AutoCloseable[/b] 介面，所以當你用到實作這三個介面的 SQL 物件時，也能將宣告這些物件的陳述式寫在 try-with-resource 的陳述式裡，這樣就不怕忘記關閉資料庫資源了。

範例：

[code]

package idv.jacky.ironman4.day29;

import java.sql.Connection;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

public class Day29Example1 {

public static void sampleQueryProcessing(Connection sampleCon) throws SQLException {

String sampleQuery = "select * from STUDENT";

try (Statement sampleStmt = sampleCon.createStatement()) {

ResultSet rs = sampleStmt.executeQuery(sampleQuery);

while (rs.next()) {

String studentName = rs.getString("NAME");

String studentAge = rs.getString("AGE");

System.out.printf(" NAME: %S, AGE: %s%n", studentName, studentAge);

}

[/code]

RowSetFactory 是一組新的 API，早期沒有 RowSetFactory 時，我們必需把實作 RowSet 的類刟名稱寫死在程式碼裡(因為各家的資料庫都會提供自己的類別)。現在則可以透過 RowSetFactory 這個 API 來統一產生 RowSet 物件，而不需要去管到底是什麼類別實作的。這樣一來，你的程式就更有彈性，只需要更改系統的參數，例如在執行 Java 程式前，用命令列參數來設定：

[b]java -Djavax.sql.rowset.RowSetFactory=com.sun.rowset.RowSetFactoryImpl[/b]

如此你就可以隨時抽換使用不同的實作類別，相當的方便。而當你不指定時，Java 會預設使用 com.sun.rowset.RowSetFactoryImpl。

範例：

[code]

package idv.jacky.ironman4.day29;

import java.sql.SQLException;

import javax.sql.rowset.JdbcRowSet;

import javax.sql.rowset.RowSetFactory;

import javax.sql.rowset.RowSetProvider;

public class Day29Example2 {

public void sampleMethod(String sampleUserName, String samplePassword) throws SQLException {

RowSetFactory sampleRowSetFactory = null;

JdbcRowSet sampleRowSet = null;

try {

sampleRowSetFactory = RowSetProvider.newFactory();

sampleRowSet = sampleRowSetFactory.createJdbcRowSet();

sampleRowSet.setUrl("jdbc:sampleDriver:sampleAttribute");

sampleRowSet.setUsername(sampleUserName);

sampleRowSet.setPassword(samplePassword);

sampleRowSet.setCommand("select * from STUDENT");

sampleRowSet.execute();

} catch(Exception e) {

e.printStackTrace();

}

[/code]

Unicode 6.0 簡介

介紹完了 Project Coin，接著我們來看看 Java SE 7 裡其它的新功能。首先我們要看的新功能是 Unicode 6.0 的支援！

Unicode 是一種文字編碼的方式，什麼是文字編碼？簡單的說就是把我們用的文字，例如中文、日文、英文等…轉換成電腦看得種的符號，基本上電腦只認得 0 和 1，早期美國發明電腦時，電腦只認得英文字母和一些基本的符號，後來隨著作業系統的發展，漸漸地也能顯示各種不同語言的文字，但電腦還是只認得 0 和 1 啊！所以我們要將一個個的文字對應到 0 和 1 的表示方式，而這種對應我們就稱之為文字編碼，為了人類容易閱讀，我們將 0 和 1 的數值用 16 進位的方式來表示。

不同的語言，不同人整理文字順序的方式，也就產生了各式各樣不同的編碼方式，像英文常用的是 ISO 8859-1，繁體中文常用的是 Big5，簡體中文常用的是 GB2312等…。可是不同的文字編碼所造成的困擾是，當我們在交換文書檔案時，如果用錯了編碼方式，那麼那份文件輕則內容變成亂碼，重則可能會損毀檔案無法開敵。所以一定要有一種統一的編碼方式讓大家可以遵循，以降低不同語言的系統在交換檔案時的困擾。因此就誕生了 Unicode！

Unicode 從1987年發想，到1991年10月，Unicode 1.0 版公佈，到1993 年6月的 1.1 版開始支援中文字。一直到去年(2010)10月的 6.0 版，已經支援世界上大部份語言的文字，共109,449個字。Unicode 的特點就是，不管什麼語言的文字和符號，都有一個唯一的編號，所以不會重覆。只要是原生支援 Uicode 的系統，像是Mac OS X、iPhone，就能直接顯示各式個樣不同的文字，不需另外安裝 patch。

Unicode 6.0 除了加入了一些印度、中東的方言外，還加入了撲克牌(playing card)、交通(transport)、地圖(map)符號，而最精彩的是加入了表情符號(emoticon)和繪文字(emoji)

表情符號就是我們平常在 MSN 裡使用的那些基本的表情：

http://www.unicode.org/charts/PDF/U1F600.pdf

繪文字是日本電信商們專有的圖示符號，可以表現的表情圖示比表情符號還多，日系的手機都有支援，其它的手機，可以透過特定的方法，來開啟它的輸入法，例如iPhone。

http://www.unicode.org/charts/PDF/U1F300.pdf

真的很難想像幾年後的 Unicode 7.0 要加入什麼文字！火星文？克林貢文？呵呵….

Project Coin - 簡化變動參數方法的呼叫 (Simplified varargs method invocation)

Project Coin 裡的最後一個新功能叫簡化變動參數方法的呼叫 (Simplified varargs method invocation)，從名稱上看不出個所以然，它又跟昨天提到的 Heap Pollution 有什麼關係呢？

變動參數也是在 Java 1.5 中新增的功能，而它特殊的 [b]…[/b] 語法，實際上就是轉換成陣列使用，再配合泛型的不特定型別的宣告，在某些情況下，也是會造成 Heap Pollution。請看下面這個例子：

[code]

package idv.jacky.ironman4.day26;

public class Day26Example1 {

public static void main(String[] args) {

System.out.printf("Sum = %d%n", Util2.sum(args));

}

[/code]

[code]

package idv.jacky.ironman4.day26;

public class Util2 {

public static <T> int sum(T...numbers) {

int sum = 0;

for(T i : numbers)

sum += ((Number)i).intValue();

return sum;

}

[/code]

我們把 sum 方法的參數，改成使用 varargs 的語法，我們大譫地假設呼叫 sum 方法的人，所傳進來的物件，都是 Number 類別的物件，或其子類別物件，例如 Integer, Double等…然後呼叫 Number 的 intValue 方法，再把它們通通加起來。

問題就出在我們的「大膽假設」上，[b]T[/b] 指的是不定型別，也就是說我們不把 sum 方法的參數型別給寫死，完全在執行時期時，才去動態的傳入。問題就在於如果傳入的不是 Number 或其子類別物件的話，那就會遇到 Heap Pollution 的問題。

上面的範例，在編譯時加上 [b]XIint:unchecked[/b] 的參數的話，就會看到 Java 所丟出來的警告訊息：

[b]

/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/javac -Xlint:unchecked Util2.java

Util2.java:6: warning: [unchecked] Possible heap pollution from parameterized vararg type T

public static <T> int sum(T...numbers) {

^ where T is a type-variable:

T extends Object declared in method <T>sum(T...)

1 warning

[b]

這次 Java 就很明確的告訴你，Util2.sum 方法可能會有 Heap Pollution 的問題！

如果我們真的非常肯定，Util2.sum 方法只有我們自己會用，且一定會傳入正確型別的變數進去，例如：

[code]

package idv.jacky.ironman4.day26;
import java.util.ArrayList;import java.util.List;

public class Day26Example2 { public static void main(String[] args) { List<Double> numbers = new ArrayList<>(); for(String str : args) numbers.add(Double.parseDouble(str)); System.out.printf("Sum = %d%n", Util2.sum(numbers)); }}

[/code]

我們不想在編譯時看到剛剛的警告訊息的話，在 Java SE 7 之前，我們可以用一個 Annotation - [b]@SuppressWarings("unchecked")[/b] 來壓制這個警告。在 Java SE 7 裡則多了一個新的 Annotation 特別設計給 varrags 用的，就是 [b]@SafeVarargs[/b]。效果跟 [b]@SuppressWarings("unchecked")[/b] 一樣，我們在 sum 方法宣告的的上一行加上 [b]@SafeVarargs[/b]，

[code]

@SafeVarargs

//@SuppressWarnings("unchecked")

public static <T> int sum(T...numbers) {

[/code]

這樣編譯器就會認為你已經知道 Heap Pollution 的風險，而略過對這個方法提出警告。

不過，這只是把警告給壓制下來，實際上 Heap Pollution 的問題並沒有消失，所以在呼叫這類的方法時，還是得特別地注意。

Philips 氣炸鍋初體驗

自從敗家天王 486 在部落格上介紹 Philips 氣炸鍋之後，它應該是2011年末詢問度最高的家電商品吧！上週三團購一開始，短短的三小時內，800台搶購一！是誰說景氣不好的 :P

朋友們看我在臉書上 po 了一堆氣炸鍋相關的訊息，都保持著高度的興趣！不過團購一下就結束了，有位朋友聽說百貨公司的專櫃也已經開賣了，趁著週年慶有優惠，一組人馬殺到百貨公司，搶走了最後一台！哈哈哈~~

因為週年慶的關係，價格不會比團購還差，再加上團購要等到12月才會到貨，拿現貨的感覺爽度有差！可惜團購不能退貨，不然我們也在百貨公司買了！百貨公司訂價8450, 特價 7988, 遠百寶慶店週年慶, 滿五千送500, 現抵! 再送西提牛排卷一張! 但特價只到今晚(11/06)! :P

朋友阿莎力的刷卡帶走後，我們迫不及待地衝到朋友家去試用囉~~

Philips 氣炸鍋好大一個啊~

在百貨公司搶到的最後一組，當然要小心點拆.

露出面貌了~

初次見面，請多指教~

主角登場~~

真的好大一鍋啊!!

拿底鍋來跟我們家妹妹的頭比較一下

氣炸鍋本身只有兩個旋鈕，上方的是溫度旋紐，下方的是時間旋鈕。

第一次就先找最容易的下手吧，說明書上說可以薯條和雞塊一起炸，用隨機附的檔板，把兩種食材隔開

機身上有貼了六種基本食材炸的溫度和時間，薯條和雞塊一起炸的話是180度, 18~25分鐘...給它開下去。機身面版上還有兩個燈號，上面的綠燈是電源燈，下面的橘燈是加熱燈。

在加熱的同時，來看看附贈的食譜吧~ 有中文的一本(10道菜)，英文的一本(沒數幾道菜，但比中文的厚上一倍)。

炸魚

鹽酥雞好像不錯，下次來試試

說明書上說，量多的話, 炸到一半可以拿出來拌一下，受熱均勻一點。直接拉出來就好了! 沒有什麼暫停鍵之類的~

噹! 炸好囉~~

顏色看起來炸的不錯喔~~

真的把一堆油都炸出來了耶!

豪邁地整個倒在盤子上

失敗！炸太久了，已經乾掉了~~ 後來反覆試了三遍，薯條其實十分鐘就夠了，而且我們也偷懶沒拿出來攪拌 :P 雞塊也15分鐘就很夠了~

這次換炸牛排!!

牛排就很成功！又嫩又好吃~~(頂好買的美國牛肉)

換筊白筍

沒有油脂的食材，其實就像烤的一樣，不要看表皮焦焦的，咬一口下去，汁很多呢! 好吃~

結論：

連贈品的價值加加起來，七千左右的價格來說，算是蠻超值的！而且真的很好用，只需要調好度、設定時間，就搞定了！雖然火候上還是需要經驗值來拿捏一下，但整體來說算是簡單易用，又能做出好吃料理的好家電！

我們一群人四大兩小，兩個小時就喀掉了一大袋的薯條(剛買時，還以為買太多了，看來下次要去 Costco 買了)，一袋雞塊、一小份牛排和筊白筍，真的是很有效率的家電！趁百貨公司週年慶有特價，想買的人快去敗家吧，你不會失望的！

複習 - Heap Pollution

Java 從1.5 版加入泛型的功能後，一直有個潛在的使用問題，那就是 [b]Heap Pollution[/b]。

我們先來看看下面這個範例：

[code]

package idv.jacky.ironman4.day25;
import java.util.Arrays;import java.util.List;
public class Day25Example1 {
public static void main(String[] args) { List numbers = Arrays.asList(args); System.out.printf("Sum = %d%n", Util.sum(numbers)); }}

[/code]

[code]

package idv.jacky.ironman4.day25;

import java.util.List;

public class Util {

public static int sum(List<Integer> ls) {

int sum = 0;

for(Integer i : ls)

sum += i;

return sum;

}

[/code]

你應該一眼就能看出來上面這個範例程式哪兒出了問題，問題就在於 Util.sum 方法只能接受 List<Integer> 的參數，但我們卻在第10行把一個 List 物件傳進去，而 List 物件則是透過 Arrays.asList 的方法，把 main 方法的參數 args 字串陣列，轉成 List 物件。

程式在編譯時，Java 編譯器會丟出一個警告訊息：

[b]

javac Day25Example1.java

Note: Day25Example1.java uses unchecked or unsafe operations.

Note: Recompile with -Xlint:unchecked for details.

[/b]

意思是說程式裡有個未受檢查或不安全的程式碼，建議你在編譯時加上 [b]-Xlint:unchecked[/b] 來看詳細的資料。

[b]

javac -Xlint:unchecked Day25Example1.java

Day25Example1.java:10: warning: [unchecked] unchecked conversion

found : java.util.List

required: java.util.List<java.lang.Integer>

System.out.printf("Sum = %d%n", sum(numbers));

1 warning

[/b]

Java 編譯器有檢查到，sum 方法的參數型別應該是 List<Integer>，但你給的是 List。

程式依然可以編譯成功，但執行時就會有例外出現：

所以 [b]Heap Pollution[/b] 指的就是將一個未定參數型別的 Collection 物件，指定給一個有指定參數型別的 Collection 物件後，所隱藏的潛在問題。

既然知道這樣會有潛在的危險，因為我們不能確定所有呼叫 sum 方法的人，傳進來的都是 List<Integer> 物件，那為什麼不能在編譯時就給個錯誤，不讓程式編譯成功呢？主要的原因是，Java 無法知道誰會呼叫 sum 方法。我們的範例很簡單，你一下就看出來哪邊有問題，但今天如果 Util 類別是要給別人使用的，你並沒有辦法知道別人會不會正確的使用它。而 Java 程式裡變數的型別檢查，都是在編譯時其做的，在執行時期，是完全沒有型別資料的。一直要到發生例外時，我們才知道問題出在哪。

所以當你在編譯 Java 程式碼時，如果要你使用 [b]-Xlint:unchecked[/b] 來察看詳細的警告資料時，請花點時間看一下，修正可能會發生錯的程式碼，這樣能確保你的程式能更安全、穩固地執行。

https://sites.google.com/a/prever.co.kr/josh/java/whatisheappollution

Project Coin - try-with-resource 語法完

除了後開先關的規則之外，在使用 try-with-resource 語法時，還有一點要注意的，就是 [b]例外的壓制(Exception Suppressed)[/b]。

我們已經知道 close 方法有可能會丟出例外，那如果在 try 區塊裡也不小心丟出例外時，Java 會怎麼處理這兩個例外呢？我們先宣設計另一個可關閉的類別：

[code]

package idv.jacky.ironman4.day24;

public class MyResource3 implements AutoCloseable{

@Override

public void close() throws Exception {

System.out.println("Close resource 3.");

throw new Exception("MyResource3 Close Exception");

}

[/code]

在 MyResource3.close 方法裡，我們它丟出一個 Exception 例外。然後我們這樣來測試一下：

[code]

package idv.jacky.ironman4.day24;

public class Day24Example1 {

public static void main(String[] args) {

try {

foo();

} catch (Exception e) {

System.out.println(e);

}

public static void foo() throws Exception {

try (MyResource3 r3 = new MyResource3()) {

System.out.println("Do something...");

throw new Exception("Something error!");

}

[/code]

我們有個 foo 的方法，方法裡會產生 MyResource3 的物件，然後在 foo 方法的 try 區塊裡也丟出一個例外。而呼叫 foo 的 main 方法裡，用個try-catch 區塊來補捉 foo 方法所丟出來的例外。最後你猜猜在程式的第9行會印出什麼？

很意外嗎？在 close 方法裡的 "MyResource3 Close Exception" 跑哪去？因為 catch 陳述式裡一次只能補捉一個例外，try 區塊中已經丟出一個例外了，Java 會優先補捉它。一般來說 try 區塊的程式碼是主要的，所以有例外發生時，通常會需要特地去處理；而 close 所丟出來的例外是次要的，你可以依情況進一步處理。

close 方法丟出的例外並沒有不見，只是被壓制(Suppressed)了，Java SE 7 的 Throwable 介面裡(所有的 Exception 都實作這個介面)有個 [b]getSuppressed[/b] 的方法，它就是用來取出所有被壓制的例外！我們來改寫一下剛剛的例子：

[code]

package idv.jacky.ironman4.day24;

public class Day24Example2 {

public static void main(String[] args) {

try {

foo();

} catch (Exception e) {

System.out.println(e);

System.out.println("Suppressed Exceptions: ");

Throwable[] th = e.getSuppressed();

for(Throwable t : th)

System.out.println(t);

}

public static void foo() throws Exception {

try (MyResource3 r3 = new MyResource3()) {

System.out.println("Do something...");

throw new Exception("Something error!");

}

[/code]

我們在 main 方法裡補捉到例外後(第21行丟出來的)，呼叫 getSuppressed 方法來取得被壓制的例外，也就是 MyResource3 裡第8行所丟出來的。getSuppressed 會回傳一個 Throwable 物件陣列，因為 try-with-resource 陳述式裡可以有多個可關閉物件的宣告。然後我們再用個 for 迴圈把這裡被壓制的例外也印出來(本範例中只有一個)，程式執行結果如下：

現在你知道 MyResource3.close 方法丟出的例外跑哪去了吧！

Project Coin - try-with-resource 語法續2

在 Java SE 7 裡，還有另一個繼承 java.lang.AutoCloseable 的介面，所有 java.io package 裡的資料串流類別其實是實作這個介面，反而不是直接實作 java.lang.AutoCloseable 介面。這個介面就是 java.io.Closeable！

就兩個介面的宣告上來說，幾乎沒什麼差別，唯一的差別就是 java.io.Closeable 的 close 方法宣告會丟出 IOException 例外，而 java.lang.AutoCloseable 的 close 方法宣告會丟出 Exception 例外。當然每個資料串流類別實作 close 方法的細節不同，介面的好處就是，不管底層類別如何實作，介面的方法呼叫還是一樣。

我們再來設計一個實作 java.io.Closeable 介面的類別：

[code]

package idv.jacky.ironman4.day23;

import java.io.Closeable;import java.io.IOException;
public class MyResource2 implements Closeable{
public void close() throws IOException { System.out.println("Close resource 2."); }
}

[/code]

MyResource2 類別跟昨天的 MyResource1 類別差不多，只差實作的介面不同。

有時因為程式的需要，我們可以在 try-with-resource 陳述式裡，宣告多個可關閉的物件嗎？答案當然是可以的，你就把 try-with-resource 的小括號當成一般的程式碼區塊，把要宣告的可關閉物件寫在裡面，每個物件的宣告用分號(；)隔開，例如：

[code]

package idv.jacky.ironman4.day23;

import idv.jacky.ironman4.day22.MyResource1;

public class Day23Example {

public static void main (String[] args) throws Exception {

try (MyResource1 r1 = new MyResource1();

MyResource2 r2 = new MyResource2()) {

System.out.println("Do something...");

}

[/code]

現在要考考大家，這個範例程式會印出三個字串，請問順序會如何？毫無疑問的，"Do something…" 一定會是第一個，那接下來呢？ MyResource1 和 MyResource2 哪個物件會先被關閉呢？規則是，後產生的物件會先被關閉，所以執行的結果會是：

為什麼會後宣告的先關閉呢？因為有可能你會在後宣告的物件裡，使用前面宣告的物件，例如：

[code]

package idv.jacky.ironman4.day23;

import java.io.BufferedReader;

import java.io.FileReader;

public class Day23Example2 {

public static void main(String[] args) throws Exception {

try (FileReader f = new FileReader("c:\\temp.txt");

BufferedReader b = new BufferedReader(f);) {

String line = b.readLine();

}

[/code]

如果我們先關閉了第一個物件，有可能會讓第二個物件無法順利操作！所以在使用 tr-with-resource 陳述式時，請記得 [b]後開先關/b] 的原則！

iT老爸碎碎唸

Nespresso PIXIE C60 開箱

未完．待續~

NIO2

JDBC 4.1

Unicode 6.0 簡介

Project Coin - 簡化變動參數方法的呼叫 (Simplified varargs method invocation)

Philips 氣炸鍋初體驗

複習 - Heap Pollution

Project Coin - try-with-resource 語法 完

Project Coin - try-with-resource 語法 續2

Project Coin - try-with-resource 語法完

Project Coin - try-with-resource 語法續2