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