在學習
java 1.5
的過程中,我使用了
sun
公布的
tutorial
,這份文檔寫的比較詳盡易明,但是對于想快速了解
tiger
而且具有較好
java
基礎的人來說,大篇幅的英文文檔是比較耗時間和非必需的,所以我將會歸納這份文檔的主要內容,在保證理解的底線上,盡力減少閱讀者需要的時間。
在以下地址可以進入各新增語言特色介紹以及下載相關文檔(若有)。
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html
?
2006
年
8
月
15
日
星期二
第三道虎紋:自動包裝機制
?
我們知道容器類不能放基本類型的,放進放出都要先包裝和解包,所有的這些工作都是繁瑣而無聊的,它早就該有自動機制了,終于在 1.5 里得到了實現。

































java Frequency if it is to be it is up to me to do the watusi
{be=1, do=1, if=1, is=2, it=2, me=1, the=1, to=3, up=1, watusi=1}
注意到 freq 如果為空,那么 put 的第二個參數就是 int 類型的 1 ,這個時候就出現了自動的包裝,而如果 freq 不為空,那么 freq + 1 就是自動解包后運算,再自動包裝,放入 Map 中。
現在你基本上可以忽略 Integer 和 int (或者這一類的對應)之間的區別了,除了要注意幾點警告: Integer 是可以為 null 的,如果程序試圖自動解包一個 null ,會拋出 NullPointerException 。
==用于 Integer 時比的是引用,用于 int 的時候比的是值。最后,還有一點就是即使現在是自動解包打包,它們的運行損耗并沒消失,你依然為這些動作付出了 cpu 的計算時間。
這里還有一個相關的例子:





































?
通過自動的包裝機制,提供了數組與 List 的靈活轉換,但是它的運行效率是比較低的,每個 get , set 操作,都進行了解包或者打包,偶爾使用這個方法還湊合,如果是用于核心代碼的循環里,那就是夠傻的了。
那我們什么時候該用自動的包裝機制呢?僅僅是用于消除這類所謂的“阻抗不匹配”,就是基本類型與包裝類的差異,例如要把數值放入容器類的時候。如果在進行科學計算的代碼或者其他講究效率的代碼中使用,則是不恰當的。一個 Integer 不是一個 int ,自動包裝機制僅僅模糊了它們的區別,而沒有消除之。