沒有原生數據類型，Java會更好嗎？
Gilad Bracha在博客中寫道：“我經常說，Java的原罪在于它不是一個純面向對象的語言（一切皆對象的語言）。”文中討論的主要內容不是純面向對象語言的優點，而是提出了一個問題：Java如果沒有原生數據類型，是否能保持高性能？答案是肯定的。
Gilad首先拿類型變化舉了一個簡單例子。Java語言的char類型最初用16位二進制表示（符合當時的Unicode標準）。但是當標準改變之后，“人們用Java處理unicode時不得不自己處理編碼格式”。至于性能的問題，他提供了幾個例子演示如何在不影響效率的情況下處理對象。其中一個例子：
那么我們如何避免使用原生數據類型而又不損失性能呢？
Java有一套強制靜態類型機制，它被編譯成靜態類型的匯編語言（Java字節碼，即JVML）。它支持靜態類。我不建議使用這些特性，但是我們需要知道。我們唯一需要做的就是根除原生數據類型。
假設我們存在一個靜態類Int表示32位整數。編譯器能夠把該靜態類轉換為int類型。因此，我們就可以編寫標準的Java代碼而無需損失任何性能。
更有趣的例子包括：以操作符命名的方法、==操作符、實例鎖定和數組協變等等。
原生數據討論結論：
總之，Java原本可以完全面向對象而不受明顯的性能影響。但是它過去不是，現在不是，可能未來也不是。光榮易逝啊（Sic Transit Gloria Mundi）。
文章的讀者回復大多數都同意Gilad的觀點。
摘選如下：
◆Daniel Speiwak——事實上，聽起來很像Scala。Odersky和朋友們提出了一種有關協變數組和消除原生的解決辦法：泛型特化。
◆abies ——可能并非如此簡單。盡管我也認為將原生類型編碼為對象可以非常高效，但是總會有損失的。Smalltalk就是一個例子——大多數實現都把小/大整數區別對待，小整數被存放在非環形指針里。這意味著整數在不同大小轉換時表現出巨大的性能差異——對每一個整數的處理都有一些影響。我非常高興Java在數學運算法方面有可能和C++/Fortran一樣快。
◆Osvaldo Doederlein——有關面向對象vs原生數據類型的討論首先面臨一個挑戰：舉出至少一個純面向對象語言相比擁有原生數據類型和數組的語言沒有顯著的性能損失。不要拿高層次的應用基準來糊弄我。我要的是數學運算/數組的微基準，或者是現實世界低層次的運算，如數據壓縮、視頻編碼、網絡棧等等。
討論也包括一些技術上的例子以說明兩者之間的鴻溝。
也許有關“OO爭論”最有趣的一些方面在這次討論中并沒有提到。比如：
效率vs面向對象純度是80年代和90年初期（Java誕生之前）Smalltalk和C++語言之爭的焦點，其實這是一個完全不相關的辯論，因為它忽視 了OO語言誕生的原因。當時最純正的OO語言是 Smalltalk和Self，兩者都明確的以Simula（不是Simula I）為榜樣以建立一種支持領域專家簡單直接的表達問題和解決方案的語言。影響性能是完全可以理解的！
文章作者認為 Smalltalk在嵌入式、毫秒時間計時、切換的程序和實時的圖形顯示系統（應用于噴氣式飛機）中優于C++應用。這是因為Smalltalk應用了很多編程技巧（比如預編譯的方法和Smalltalk對象可以直接與硬件打交道而不依賴操作系統）以獲得性能優勢。關鍵在于，編寫相同的C++程序所花費的開發時間縮短了1/3。
Java從來沒有真正想成為一個面向對象語言。如果Sun在獲取Smalltalk授權時沒有受到阻礙（ParcPlace的純粹商業錯誤），Java可能根本不會存在。Oak將繼續沿著“智能烤面包機”的道路進化，而不會成為Java的基礎。 Java的目的就是融合Samlltalk和C++的各自最佳特性，而不是成為一種純OO語言。
從代碼和語言“特征”的角度談論OO純度是絕對錯誤的。對象是一種隱喻工具，開發人員可以借此更好的理解問題域，并獲得完全不同的、更加簡單和富有效率的設計和架構。如果一門語言是純面向對象，“一切皆對象”，僅僅意味著你可以直接表達你的設計而無需考慮這些這些設計在機器層面如何實現和執行。
如果基于為何編程語言這樣設計、在機器執行效率不是關鍵因素時對象是否真的提供了一種建立設計的好辦法等問題來看待純OO/效率的爭論，還是非常有趣的。
【編輯推薦】
