John Jiang

a cup of Java, cheers!
https://github.com/johnshajiang/blog

:: 首頁 :: :: 聯(lián)系 :: 聚合

:: 管理 ::

131 隨筆 :: 1 文章 :: 530 評論 :: 0 Trackbacks

<

2010年8月

>

日

一

二

三

四

五

六

25

26

27

28

29

30

31

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

1

2

3

4

留言簿(3)

隨筆分類(415)

隨筆檔案(130)

文章分類

Attach

搜索

積分與排名

積分 - 522764
排名 - 95

閱讀排行榜

評論排行榜

Android = Java(譯)

Android = Java

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

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

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

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

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

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

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

posted on 2010-08-22 19:49 John Jiang 閱讀(1988) 評論(0) 編輯收藏所屬分類: Java 、翻譯、Mobile 、Android

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發(fā)表評論。




網(wǎng)站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: 探索HTTP/2: 初試HTTP/2(原) Play OpenJDK: 允許你的包名以"java."開頭(原) Play OpenJDK: 構建你自己的JDK(原) 利用Java SE 8流處理數(shù)據(jù)II(譯) 利用Java SE 8流處理數(shù)據(jù)(I)(譯) Java 8的語言變化(譯) Java流的8個特性(譯) 使用Gradle構建Java Web應用(譯) Java并發(fā)基礎實踐--死鎖(原) Java Concurrent Animated(譯)