Android = Java

近期Java社區正熱議Oracle對Google的侵權訴訟，恰巧前幾日在java.net中看到一篇博文，文章作者也借此事件表達了Android=Java的觀點。由於我對Java移動開發、Android都沒太關注過，文章細細讀來，有些許進益，譯在此處，可能對大家也有幫助。(2010.08.22最後更新)

    Java社區正忙於討論Orace針對Google Android平台的專利訴訟。我已在多個場合道出了我的觀點，但還是需要一個評論性的文章來重復一下我在每個場合中都作出的相同評論...所以，本博文會將我的想法竹筒倒豆子般地和盤托出。

第八個千禧年問題：Android=Java？
    幾日前，有聲明稱有研究者已證明了P!=NP，這導致了編程社區中的極大熱忱--至少是直到兩天前，當第一個評閱者指出了該證據中幾處錯誤時。在我的計算機科學專業中我已學過這門課，但不能否認地是，我不懂高等數據以至於不能理解這些證明(P=NP?是克雷數學研究所的千禧年問題之一就是一個很好的理由)。所以，讓我們談談一個更為簡單的等式：Android是否等價於Java？注意，我說的不是等於，而是等價，就如同P=NP那樣。

等價的類/字節碼格式
    在許多層面上，Android = Java是明顯正確的。Android應用使用Java語言編寫，使用JDK中的javac編譯器(或其等價品，如ECJ)進行編譯。這就產生了標准的 Java字節碼(.class文件)。然後，這些文件被轉化成Android的.dex文件，實際上就是Java類的另一種不同格式的文件罷了。但你也能將GIF圖像轉化成優質的PNG格式，盡管這兩種圖像文件的字節碼流完全不同，但它們都同樣的優秀。
    等價的文件格式有大量的實現細節，常常是為了優化。例如，如果我們不需要復雜且不同的跨框架壓縮技術，僅僅是滿足於低效率的視頻流，我們就能避免所有違反MPEGLA視頻編碼專利的麻煩了。
    Android設計不同的類文件出於多種動機；但繞開Sun的知識產權肯定是主因。不管怎樣，Google不能遠離Java。這兩種類文件格式非常等價。它們只是在低層次的數據結構方面不同，但它們的語法是一致的，也存儲完全相同的信息。我可以肯定JavaSE或JavaME的VM能很容易地在它的系統類加載器中加入一個.dex解析器去加載"Android類"。
    Android SDK依賴於.java -> .class -> .dex轉換，這一轉換精於細節且是無損的。"無損"是非常重要：雖然GIF=PNG，但有損的JPG文件則不能完全相等--它不能解碼出完全相同的信息。如果 JVM和Dalvik真是完全獨立的，你就很難寫出一個相對簡單的工具無妥協的去將編譯後的代碼從一種形式轉換到另一種形式：沒有信息丟失；當為了補償在一個VM所擁有而在另一個VM卻沒有的重要特性時；轉換後的文件不會變大；當按照一個VM的核心API去實現另一個VM的核心API時，不需要額外的運行時層。
    (我知道dx翻譯器有多麼的復雜。我已看過它的源代碼。字節碼翻譯器很大，它是一個完整的反編譯/重編譯器，完全使用SSA構建。但這種翻譯只是在理論上比較細微；但在設計上，從Java到Dalvik字節碼的影射還是平滑的。棧相對於寄存器架構只是在優化細節方面有所不同；而在關鍵方面，如VM層的類型系統，則是一致的。)

等價的虛擬機
    也能很容易的證明Dalvik=JVM。不僅僅是在源代碼或字節碼格式方面：它們的運行時對應部分也是如此。一旦Dalvik VM加載了一個"Android類"，它走起來像Java類，叫起來也像Java類。如果你懂Java編程(能了解其高級和底層細節)，你就懂 Android編程。只是一個學習新API和框架理論的問題罷了。它們是等價的系統。
    還記得Microsoft的.NET嗎？當.NET被介紹出來時，Java社區很快就公開抨擊.NET只是Java的翻版。當時我也在那群抨擊的人群中，但現在我知道這麼做會更好些。然而.NET是一個龐大的翻版；C# 1.0語言。區別任一語言程序的最方便方法就是風格規范--如，toString()相對於ToString()。但在更關鍵的VM規范方面，Microsoft做了很好的功課。CLR，CLI和核心框架都完全不同於Java，所以我們不能說JVM=CLR。你不能使用一個簡單的文件格式轉換器工具作用於被編譯的Java類，然後將獲得信息直接運行在純粹的.NET運行時環境上。
    想要證據嗎？只要看看IKVM。這是一個非常有趣的項目，它能使Java跨越編譯運行在.NET環境中，所以你的Java代碼可不經過修改運行在CLR之上(或其它同等的.NET運行時環境，如Mono)...但IKVM並不是一個簡單的類dx文件轉換器。對於任何超過HelloWorld的應用程序，將 Java類及其核心API適配轉換到.NET是非常復雜的。每個平台的內在特性，像反射，安全，並發，異常處理，字節碼規范，I/O及其它核心API，在特性上都非常相似，但在細枝末節處則完全不同--強行讓IKVM......，則Java代碼能運行在.NET VM上。這也需要一個非常龐大的額外的運行時層，基本上要把全部的OpenJDK源代碼適配到JavaSE API。我追蹤IKVM的開發已有多年了--通過閱讀極棒的IKVM Blog--所以我有一個需要作出大量努力的好主意去將Java代碼和JavaSE應用適配到.NET。(該工作還沒全完成；已完成的部分則常有些性能問題。)
    (舊有的Visual J++ Visula J#並不是一個簡單的Java-.NET解釋器。我不會討論它，但完全可以說Visual J#對Java的兼容要大大劣於哪怕是非常早期的IKVM版本。)
    在討論中我引入了P=NP的例子；有些人可能會引入圖靈等價，並說任何圖靈完備的平台/語言/VM都是相互等價的。確實如此，但和我們要討論的問題並不相干。圖靈模型過於通用；如果僅按表面意思來使用它將會摧毀整個軟件專利系統(盡管這不是壞事！)。我們需要先在沙盤中勾勒出JVM等價的輪廓，與圖靈等價相比，這更接近於實際需要。依我的觀點，無論是細微的二進制格式翻譯，甚至於上層的源代碼和運行時兼容，都可以明確地將Android置於Java等價的陣線中。

等價的API與運行時環境
    Android使用了許多JavaSE API的子集。這些(來自於Harmony的)API是全新的實現，但它們將JavaSE作為模型。如果不是由於TCK協議的問題，Harmony甚至會獲得JavaSE認證。並不能改變Harmony與JavaSE API是完全等價的這一事實--這是故意為之，並非偶然。正如JRuby名人Charles Nutter最近寫到的：
    Android支持一個粗糙(但龐大的)Java 1.5類庫子集。這個子集足夠的大，只需要很少的限制，就能使得如JRuby這般復雜的項目基本上無需修改就可運行在Android上。
    看起來，Dalvik足夠接近JVM，它應該就完全遵從大部分JVM的規范，包括完整及非常細節的JMM(Android支持Java風格的線程與並發，直至高級的java.util.concurrent包)。有太多"Dalvik是一個新的VM"或"Dalvik不能運行Java類"的話(在討論該問題的90%的博客和論壇中都會發現這樣的言論)。

最後的思考
    本篇並不是關於Oracle針對Google訴訟的是非曲直。我將會忽略(可能會刪除)任何跑題的評論(不在Android=Java這一論題之內)。對於"Android與Java完全不相干"這一無意義的言論我只能表示厭惡；Google和Android的擁趸們必須找到比這更好的論證。
    (當訴訟的全部細節和結果出來之前，對這一訴訟的將來我保留自己的全部判斷。除非你有內部消息(我沒有)，請不要太天真。保持冷靜！我們真的不知道 Oracle或Google的全部意圖和計劃。自從2007年Google首次發布Android(這導致了JavaME生態系統的極大分裂)，雖然 Sun十分憤怒但仍不得不夾著尾巴，我們不知道這幕後的故事。我不會認同任何價值數以十億計，且由股東控制的公司所持的利己主義的動機。)
    我不認為Google創建一個基於Java但偏離Java甚遠的平台(如.NET所做的那樣)是無競爭力的。在保持對已有Java代碼和類庫巨大兼容性，Java人才及Java工具鏈之間的平衡性的意願時，Dalvik和Android框架會讓你獲得盡可能多的好處。
    顯然，Android=Java不能在雙方面都包含進來(不是雙射)。每個平台都有一些獨一無二的 API，當然，Android是一個完整的操作系統，它包括一個基於Linux的內核，圖形和電話棧，等等。我顯然只談及普通的部分：基於Java的用戶空間/應用框架要依賴Java源代碼和類(無論是哪種格式的)，API(包含數以千計的通用JavaSE API)，以及非常引人注目的類Java的虛擬機。對Android與其它Java平台關系的准確描述可能要使用到版本或測評的概念。我記得一個博客說過像"Android沒有'J'"這樣的話。好的，還不晚：我的建議是將Android的名稱修改為Java GE(Java Google Edition)。這就能一勞永逸地消除困惑;-)