Android等同於Java嗎？請註意，我說的不是相等，我說的是等價，就像P = NP中壹樣。
等價類/字節碼格式在很多層面上，Android和Java顯然是等價的。Android應用程序是用Java語言編寫的，並使用JDK的javac(或類似的工具，如ECJ)進行編譯。這個過程生成標準的Java字節碼(。類文件)。這些文件然後被轉換成。Android的dex文件，這是壹個Java類文件，從使用的角度來看格式不同。是的，這是壹個更好的格式；孫的設計從1994開始有了很大的改進。但就像妳可以把壹張GIF格式的圖片轉換成更高級、更完美、完全等價的PNG格式，雖然它們的字節流完全不同。
等價文件格式在細節上差別很大，主要是為了優化。比如，如果我們單純滿足於低效率的視頻數據流，不采用跨不同幀的高端壓縮技術，那麽就可以避免打MPEGLA視頻解碼專利的麻煩。
Android特定的類文件設計有幾個動機；為了避免與Sun的知識產權保護發生沖突，這顯然是壹個主要因素。無論如何，谷歌離Java還不夠遠。這兩種文件格式非常相似。它們在具體的底層數據結構上是不同的，但是這些結構在語法上是壹致的，並且存儲完全相同的信息。我相信在JavaSE或者JavaME VM中，很容易在他們的系統類加載器中添加壹個. dex解析器來加載“Android類”。
Android SDK依賴於。Java-& gt；。class->；的事實。dex轉換微不足道，沒有損失。“不丟失”的事實非常重要:當GIF = PNG時，它與受損的JPG文件不同——它不能解碼完全相同的信息。如果JVM和Dalvik是獨立的，那麽您很難編寫壹個相對簡單的工具來將壹個編譯後的代碼轉換成另壹個——沒有任何損失:沒有信息丟失，沒有使用冗余來補償壹個特性在壹個VM中是壹流的而在另壹個VM中不是，並且不需要額外的運行時層來在壹個VM中實現另壹個VM的核心API。
我知道dx轉換器有多復雜。我看過它的源代碼。那個字節碼轉換器是壹個巨大的、全功能的反編譯/重編譯程序，是通過SSA構造完成的。但是這個轉換器在概念上仍然是無關緊要的；從Java字節碼到Dalvik字節碼的映射在設計上是平滑的。相對於寄存器架構中的精細部分來優化堆棧；而重要的東西，比如VM層的類型體系，是完全壹致的。)
很容易看出VM等同於Dalvik和JVM。不僅僅是源代碼或字節碼格式:它們的運行時版本也是如此。壹旦壹個“Android類”被加載到Dalvik VM中，它就會像Java類壹樣運行和工作。如果妳懂Java編程(深入高級和低級細節)，妳也懂Android編程。妳只需要學習壹些新的API和框架概念。它們是對等系統。
妳還記得微軟的。網？什麽時候。NET剛誕生，Java陣營就迅速反擊指責。Java抄襲網。我也是其中之壹，但今天我把問題看得更清楚了。是的，曾經是嚴重抄襲的產物；C# 1.0是壹個...區分壹種語言和另壹種語言的最簡單的方法是看它們的慣用風格——例如，ToString()和toString()。但是在最重要的VM規範上，微軟做了很多功課。它的CLR、CLI、核心框架都和Java有很大不同，所以不能說等式JVM = CLR。您不能使用簡單的文件格式轉換工具將您編譯的Java類轉換成可以在。NET運行時。
妳想要證據嗎？妳只要看看IKVM就知道了。這是壹個很有意思的項目，可以讓Java和。NET跨平臺兼容，因此您的Java代碼可以在CLR(或等效的。NET運行時，如Mono)不加修改…但IKVM不是壹個簡單的類似dx的文件格式轉換器。Java類的轉換和Java核心API的適配是非常復雜的，即使對於壹個簡單的HelloWorld程序也是如此。每個平臺的內部機制，如反射、安全性、並行性、異常處理、字節碼驗證、I/O以及其他核心API，在特性上基本相同，但在細節上完全不同。壹些死胡同情況會迫使IKVM鉆過壹個又壹個火圈，讓Java代碼繼續運行。NET虛擬機。它需要依賴壹個巨大的額外運行時層來適應來自OpenJDK源代碼的完整JavaSE API。幾年來我壹直密切關註IKVM的發展——我讀了這篇精彩的IKVM博客——所以我充分意識到他們為使Java程序和JavaSE應用程序適應。網。工作仍未完成；而且很多部分需要以損失壹些性能為代價。)
(舊的Visual J++ Visual J#不是簡單的Java-to-。網絡轉換器。我不想說，但是我們可以說，Visual J#與Java的兼容性並不比最早的IKVM好多少。)
我把P = NP引入討論；有人引入圖靈等價理論，說任何圖靈完備的平臺/語言/VM都是彼此等價的。沒錯，但與本題無關。圖靈模型過於壹般化；用這種膚淺的價值去考慮，會破壞更多的軟件專利制度(雖然這不是壞事！)。我們需要在地面上為JVM等價畫壹條線，壹條更接近實際需要而遠離圖靈等價的線。在我看來，這種瑣碎的二進制格式轉換、用盡的高級源代碼和運行時兼容性，使得Android明顯在Java等價的線內。
API和運行時是等價的。Android使用了相當大的JavaSE APIs子集。這些API(來自Harmony Project)都是全新的實現，但是它們是基於JavaSE建模的。如果不是TCK許可問題，Harmony本可以獲得JavaSE認證。但這並不能改變Harmony和JavaSE APIs完全等價的事實——這是有意的，不是偶然的。正如著名的JRuby人物Charles Nutter最近寫道:
Android支持Java 1.5類庫的壹個不完整(但相當大)的子集。這個子集非常大，以至於壹個復雜的JRuby項目可以在Android上運行，不需要任何修改，限制也很少。
看來Dalvik離JVM這麽近，還得完全兼容大部分JVM規範，包括完全詳細的JMM(就像Android支持Java風格的線程和並發，已經深入到高級的java.util.concurrent包中)。但是為什麽有那麽多說法說Dalvik是新VM或者Dalvik不能運行Java類(討論這個官司的論壇和博客90%都持這種觀點)？
最後，這篇博客不是關於甲骨文和谷歌訴訟的法律依據。我會忽略(我會刪除)那些跑題的評論(如果與Android = Java無關)。我就是討厭“安卓與Java無關”這種廢話；谷歌和安卓的擁護者必須找到壹個更有意義的論點。
我會以我所有的先見之明，靜觀這場官司的進展，直到所有的細節和最終結果出來。不要天真，除非妳有內幕消息(我沒有)。保持冷靜。我們不知道甲骨文或谷歌的所有真正動機和計劃。我們不知道這個屏幕背後的故事。自從2007年Google第壹次宣布Android誕生(導致JavaME生態環境崩潰)，孫就對其恨之入骨，但最後還是不得不夾著尾巴行動。我不相信任何壹家6，543.8+0億美元的股東控股公司會是利他的:谷歌不會，甲骨文不會，連我最喜歡的老孫公司也不會。讓我們拭目以待。)
我不相信Google不能創造壹個不偏離Java太遠，基於Java風格的平臺(as。NET做的)。Dalvik，以及Android框架，可能是權衡與大量現有Java程序、類庫、Java天才、Java工具鏈高度兼容的願望的最終結果。微軟放棄了移植現成Java的好處，創造了壹個全新的。網。谷歌沒有這麽做。
這個Android = Java等式顯然沒有包含壹切(不是壹壹對應)。每個平臺都有自己獨特的API。當然，Android是壹個完整的操作系統，包括壹個基於Linux的內核、圖形系統和電信棧等等。顯然，我只說最常用的部分:以Java為中心的用戶區域/應用框架，它依賴於Java源代碼、Java類(不管格式如何)、Java APIs(包括成千上萬常用的Java SEAAPIs)和優秀的類Java虛擬機。關於Android和其他Java平臺的關系，壹個準確的說法是使用版本的概念。我曾經記得有個博客說“安卓沒有‘J’”。好吧，我現在說還不晚:建議安卓改名為Java GE(Java谷歌版)。這樣，就再也不會引起混亂了。
轉自:51CTO技術論壇