轉：你知道的java和你不知的的java
阿新 • • 發佈：2019-02-04
最近我們收到一封電子郵件，諮詢 “什麼是Java？”條目的資訊。在2006年，難道還有人不知道“什麼是Java”嗎？十年來，有大量介紹Java的書籍、網站和會議，難道不是所有人都知道“什麼是Java”嗎？顯然答案是否定的。
畢竟，情況已經改變。
每個涉及applet和實時（Just-in-time）編譯器的含糊定義都有許多已固定下來併為許多人所瞭解的新說明和新事實，但它們並非全部都寫入文件中了。過去，Java常常意味著：
•Applet
•位元組碼解釋
•緩慢的效能
•等待Sun恩賜的“拜物教”
而如今，它意味著：
•Web應用程式、Web服務、SOA等等
•熱點動態編譯
•高效能
•一個日益獨立於Sun的開源社群
過去有個口號叫做“一次編寫，隨處執行”，這仍然是事實，但編寫的內容及其執行環境和方式正在改變。
Java程式語言
Java是一種面向物件的高階程式語言，它在許多方面受到C、C++和Smalltalk的影響，還借用了其他語言的概念。其語法的設計方式使得那些熟悉“大括號”語言（繼承自C）的人也會熟悉Java語法，但它具有比C++更強的面向物件性、物件的靜態型別轉換以及相當嚴格的異常系統，該系統要求呼叫堆疊中的每個方法要麼處理異常，要麼宣告其丟擲異常的能力。當然還有垃圾自動收集功能，這使開發人員不必釋放由廢棄物件佔用的記憶體。
Java的一個比較受爭議的方面（這些方面在釋出Java時被廣為接受，但現在正日益受到批評）是它的不完全的面向物件性。具體來說，Java基本型別（如int、char、boolean等等）都不是物件，並且開發人員需要以完全不同的方式來處理它們：由於int不是類，因此不能為其建立子類併為其宣告新方法，也不能將它傳遞給需要普通物件的方法，諸如此類。基本型別提高了Java的效能，但卻降低了程式碼的清晰度，這一點使用所謂的“包裝器類”（Integer、Character和Boolean）的人應該深有體會。Java 5.0引入了autoboxing（自動裝箱）模式，以消除許多使用包裝器類的用例，但在某些方面這使程式碼的功能不那麼明顯了。
從理論上講，Java是種“早期出錯”語言。由於它的語法約束，許多程式設計錯誤在Java中不可能出現。由於不能直接訪問指標，所以指標運算錯誤也就不存在了。使用物件時的型別如果與當初宣告它的型別不同，就會要求進行顯式的型別轉換，這使編譯器能夠拒絕不合邏輯的程式設計，如對一幅影象呼叫一個字串方法。
許多Java企業框架都要求使用配置檔案或者部署描述符（通常用XML編寫）來指定操作：哪個類處理特定的HTTP請求、在規則引擎中執行的步驟順序等等。實際上，要實現這些功能不能只用這種語言。評論人士指出，這會產生不當後果：不僅避開了Java編譯器的檢查，而且開發人員無法再（只）根據程式的原始碼就可確定它如何執行。Java 5.0為該語言添加了註釋（annotation）特性，它允許使用值為方法、欄位和類新增標籤，在執行時，通常可通過反射對這些值進行內省和操作。許多程式設計師喜歡註釋，因為它簡化了工作，否則就需要通過部署描述符或其他方法來解決問題。但是，註釋也有可能使Java程式碼難以理解，因為註釋的有無可能會影響程式碼的執行方式，而這從註釋中不太容易看出來。
儘管存在這麼多的批評意見，但Java通常還是被認為是當今最流行的通用計算語言。在企業程式設計領域，它是一個廣泛使用的標準，而且2005年它取代C++成為SourceForge專案使用最多的語言。使用Java有很多好處：免費的工具（適用於多種平臺：Linux、Windows、Solaris和Mac均可編譯和執行Java應用程式）、內容豐富的知識庫以及大量樂意提供幫助的開發人員。
Java語言已經達到了開發人員生產率與程式碼效能之間的一個特定平衡點：CPU週期成本持續降低，但開發人員的開發週期卻並未明顯縮短，因此在開發人員與CPU操作碼執行之間再出現一個抽象層也許是不可避免的了，它將使開發人員能夠更快地建立更好的軟體。實際上，Java生產率的批評者（如《Beyond Java》的Bruce Tate）可能正是觀察到了這種不斷推進Java使其達到新的平衡點，從而進一步犧牲效能去換取更高的開發人員生產率的趨勢。
Java平臺
通常有三種Java平臺：Standard Edition（標準版，SE）、Enterprise Edition（企業版，EE）和Micro Edition（微型版）。每個平臺都是一個包含某個語言版本、一組標準庫和執行程式碼的虛擬機器（見下文）的組合。EE是SE的超集，任何EE應用程式都可假定所有的SE庫都存在。EE平臺的語言使用與SE的一樣。
由於小型裝置（如：電話或機頂盒）的侷限性，Java Micro Edition與另兩個版本有很大區別。它並非SE的子集（像SE是EE的子集那樣），因為它的一些庫只存在於Micro Edition中。而且，ME取消了一些語言特性，如float型別和Float類，這反映了它的執行平臺的侷限性。ME需要與SE和EE不同的工具，而且裝置之間的巨大差異使ME領域程式碼的可移植性更加不現實，因此許多Java開發人員將ME視為異類。
Java虛擬機器
在某種程度上，Java原始碼需要成為平臺自帶的可執行程式碼。這個過程一般需要兩個步驟：開發人員將原始碼編譯成Java位元組碼，然後Java虛擬機器（JVM）將其轉換為主機平臺的原生代碼。第二步最初是通過解釋方式執行的：讀取每條JVM指令，然後動態地將其轉換為一條或多條本地指令。然後，在程式開始執行時，實時（just-in-time，JIT）編譯器將所有的Java程式從JVM位元組碼轉換為原生代碼。如今，該過程有多種實現方式。Sun的HotSpot編譯器在執行時解釋並分析程式碼，編譯並優化對程式的操作最為關鍵的那部分。IBM的JVM工作原理與此非常類似。這些方法避免了由於對整個程式進行實時編譯所導致的啟動時效能下降，隨著時間的推移，效能將會恢復，因為關鍵的程式碼部分已被定位並優化。長時間執行的伺服器程序很適合採用這種方法，但這對客戶機應用程式不太適用。
就像基本型別一樣，現在批評人士認為Java的這個兩步編譯週期是一種不成熟的優化方法。他們提出疑問：如果要等到執行時將Java位元組碼編譯為原生代碼，那麼為何不採用解釋Java原始碼（而非Java位元組碼）的方式，從而為開發人員節省一個步驟？正如Tate在《Beyond Java》一書中所說的那樣，“Java並不是最簡單的語言。它對很短的迭代也不友好……其他語言允許輕鬆地應用更改，而無需麻煩的編譯/部署週期。”
沒有Java的JVM
實際上，Tate在尋找秉承Java成功表現的後繼者的過程中抱有這樣的理念：“下一個在商業上取得成功的語言應該擁有在JVM上執行的版本。這將有助於該語言克服許多障礙，不管是在策略上還是在技術上。”他指出，虛擬機器方法可提供安全性（“如果能確保虛擬機器的安全性，則要確保語言的安全性就容易得多了”）、可移植性、互操作性和可擴充套件性。由於JVM已有效地解決了這些問題，因此如果新語言可執行在已安裝於數百萬臺計算機中的JVM上，那麼它就不需要自己的虛擬機器。
在許多方面，這種情況業已發生。用Java為指令碼語言編寫直譯器可有效地將這些語言移植到JVM上，如：用於JavaScript的Rhino、用於Python的Jython或者用於Ruby的JRuby。
但也可以完全繞過Java語言，而直接進入JVM級別。已經有一些將C轉換為JVM位元組碼的編譯器，如商業工具Axiomatic Multi-Platform C，它提供了ANSI C的子集。而且，Java位元組碼處理工具（如ASM和Apache BCEL）的發展允許Java應用程式在執行時建立可執行的類。這些類不再是Java語言，而是一種用於JVM程式設計的有效組合語言。
或許由於意識到了在JVM上執行非Java程式碼的需求，最近已提交了一項新的JSR（Java規範請求），即“Supporting Dynamically Typed Languages on the Java Platform（在Java平臺上支援動態型別化語言）”（JSR 292），它指定了一種新的位元組碼，將使JVM更適用於執行不含靜態型別資訊的語言。
沒有JVM的Java
也可以從另一個角度來看問題，即不使用JVM而執行Java。畢竟從某種意義上講，Java原始碼轉換為位元組碼，反過來位元組碼又轉換為原生代碼，沒人會說這些轉換不能一次完成。GNU Compiler for Java （GCJ）允許一次性地將Java原始碼編譯為一個平臺的可執行程式碼。不過它尚不完善，不支援Abstract Windowing Toolkit（抽象視窗操作工具包，AWT），因此它不適用於AWT或Swing GUI程式設計，但它的功能足以編譯伺服器端和命令列應用程式。
該流程有一個明顯缺陷：跨平臺的程式碼在一步中必須繫結到一個平臺。此外，靜態編譯並非是HotSpot的動態編譯所擅長的。筆者曾參與一個專案，結果發現，與HotSpot版本相比，GCJ帶來的效能提升不到5%。儘管如此，GCJ還是可以解決一些重要問題，如部署可執行的Java應用程式，而不必擔心JVM是否可用或者在執行特定的版本。
Java Community Process
Java領域除了語言、庫和虛擬機器外，還有一個Java社群。儘管有大量用Java編寫的開源軟體，但在整個Java社群與開源社群之間仍然存在著公開且明顯的矛盾。這在很大程度上可歸咎於Sun不願在適當的開源許可下發布它的Java實現，雖然這些原始碼可在各種Sun指定的許可下獲得。
有人說，這種衝突被大大地誤導了。開發人員Bruno Souza在O'Reilly最新一期的Distributing the Future播客中講到，這種反對Sun的爭論完全誤解了Java的性質，因為語言、庫和虛擬機器都是由開放且透明的Java Community Process制定的標準集：“其中的所有Java標準都被實現為開源軟體。至於Sun之外的組織是否執行Java標準，我認為這區別不大。最重要的是，JCP的規則非常清楚。JCP是非常開放的標準組織。當然，它並不完美。但我認為一個非常重要的事實是，JCP建立標準，而您可以實現這些Java標準的開源形式。這極為重要，因為這就是我們想要的組合.... ”。
有人會說Java不是開源的，這樣說毫無意義。因為說Java是或不是開源的並沒有什麼實際意義。這就像說HTTP是不是開源的一樣沒有實際意義。
實際上，Apache Harmony專案正在開發旨在成為“獲得全球認證”的J2SE實現，它可在Apache License V2許可下獲得，而且JCP允許並鼓勵所有這些工作。
JCP之外的社群
但是，仍然存在許多並未採用JCP標準的Java專案。如前所述，Java是開發SourceForge專案的首選語言，但在java.net、Apache Jakarta Project、Javalobby的Javaforge、OpenSymphony以及其它無數獨立站點上可找到更多的開源Java專案。在人們心目中，其中許多專案已經成熟，可與官方的JCP標準進行競爭，顯然其中大部分是輕量級企業框架，如Spring framework，它誘使許多開發人員對EJB 2.1之類的“官方”規範感到失望。獨立專案也快速適應了Java外部的變化，併產生了它們的最佳特性，如Rails，它就是改進後的Trails，或者如AJAX，它簡化了Direct Web Remoting （DWR）專案。
結束語
十年來，數百萬開發人員已使Java的面貌發生了巨大變化。現在需要推翻以往有關Java的假設了：語言與虛擬機器之間的耦合、它與開源領域對立的錯誤描述，以及常見的對其效能或缺點的批評。在未來十年內，Java將變得完全不同，且發生巨大變化的潛力不在語言本身，而在於關注點。屆時，許多開發人員將繼續在不同的環境中使用不斷髮展的Java語言，而其他人則將在虛擬機器上執行許多種不同的語言。不久以後，“什麼是Java”的問題就會轉變為“哪個Java？語言還是虛擬機器？”這個問題。
畢竟，情況已經改變。
每個涉及applet和實時（Just-in-time）編譯器的含糊定義都有許多已固定下來併為許多人所瞭解的新說明和新事實，但它們並非全部都寫入文件中了。過去，Java常常意味著：
•Applet
•位元組碼解釋
•緩慢的效能
•等待Sun恩賜的“拜物教”
而如今，它意味著：
•Web應用程式、Web服務、SOA等等
•熱點動態編譯
•高效能
•一個日益獨立於Sun的開源社群
過去有個口號叫做“一次編寫，隨處執行”，這仍然是事實，但編寫的內容及其執行環境和方式正在改變。
Java程式語言
Java是一種面向物件的高階程式語言，它在許多方面受到C、C++和Smalltalk的影響，還借用了其他語言的概念。其語法的設計方式使得那些熟悉“大括號”語言（繼承自C）的人也會熟悉Java語法，但它具有比C++更強的面向物件性、物件的靜態型別轉換以及相當嚴格的異常系統，該系統要求呼叫堆疊中的每個方法要麼處理異常，要麼宣告其丟擲異常的能力。當然還有垃圾自動收集功能，這使開發人員不必釋放由廢棄物件佔用的記憶體。
Java的一個比較受爭議的方面（這些方面在釋出Java時被廣為接受，但現在正日益受到批評）是它的不完全的面向物件性。具體來說，Java基本型別（如int、char、boolean等等）都不是物件，並且開發人員需要以完全不同的方式來處理它們：由於int不是類，因此不能為其建立子類併為其宣告新方法，也不能將它傳遞給需要普通物件的方法，諸如此類。基本型別提高了Java的效能，但卻降低了程式碼的清晰度，這一點使用所謂的“包裝器類”（Integer、Character和Boolean）的人應該深有體會。Java 5.0引入了autoboxing（自動裝箱）模式，以消除許多使用包裝器類的用例，但在某些方面這使程式碼的功能不那麼明顯了。
從理論上講，Java是種“早期出錯”語言。由於它的語法約束，許多程式設計錯誤在Java中不可能出現。由於不能直接訪問指標，所以指標運算錯誤也就不存在了。使用物件時的型別如果與當初宣告它的型別不同，就會要求進行顯式的型別轉換，這使編譯器能夠拒絕不合邏輯的程式設計，如對一幅影象呼叫一個字串方法。
許多Java企業框架都要求使用配置檔案或者部署描述符（通常用XML編寫）來指定操作：哪個類處理特定的HTTP請求、在規則引擎中執行的步驟順序等等。實際上，要實現這些功能不能只用這種語言。評論人士指出，這會產生不當後果：不僅避開了Java編譯器的檢查，而且開發人員無法再（只）根據程式的原始碼就可確定它如何執行。Java 5.0為該語言添加了註釋（annotation）特性，它允許使用值為方法、欄位和類新增標籤，在執行時，通常可通過反射對這些值進行內省和操作。許多程式設計師喜歡註釋，因為它簡化了工作，否則就需要通過部署描述符或其他方法來解決問題。但是，註釋也有可能使Java程式碼難以理解，因為註釋的有無可能會影響程式碼的執行方式，而這從註釋中不太容易看出來。
儘管存在這麼多的批評意見，但Java通常還是被認為是當今最流行的通用計算語言。在企業程式設計領域，它是一個廣泛使用的標準，而且2005年它取代C++成為SourceForge專案使用最多的語言。使用Java有很多好處：免費的工具（適用於多種平臺：Linux、Windows、Solaris和Mac均可編譯和執行Java應用程式）、內容豐富的知識庫以及大量樂意提供幫助的開發人員。
Java語言已經達到了開發人員生產率與程式碼效能之間的一個特定平衡點：CPU週期成本持續降低，但開發人員的開發週期卻並未明顯縮短，因此在開發人員與CPU操作碼執行之間再出現一個抽象層也許是不可避免的了，它將使開發人員能夠更快地建立更好的軟體。實際上，Java生產率的批評者（如《Beyond Java》的Bruce Tate）可能正是觀察到了這種不斷推進Java使其達到新的平衡點，從而進一步犧牲效能去換取更高的開發人員生產率的趨勢。
Java平臺
通常有三種Java平臺：Standard Edition（標準版，SE）、Enterprise Edition（企業版，EE）和Micro Edition（微型版）。每個平臺都是一個包含某個語言版本、一組標準庫和執行程式碼的虛擬機器（見下文）的組合。EE是SE的超集，任何EE應用程式都可假定所有的SE庫都存在。EE平臺的語言使用與SE的一樣。
由於小型裝置（如：電話或機頂盒）的侷限性，Java Micro Edition與另兩個版本有很大區別。它並非SE的子集（像SE是EE的子集那樣），因為它的一些庫只存在於Micro Edition中。而且，ME取消了一些語言特性，如float型別和Float類，這反映了它的執行平臺的侷限性。ME需要與SE和EE不同的工具，而且裝置之間的巨大差異使ME領域程式碼的可移植性更加不現實，因此許多Java開發人員將ME視為異類。
Java虛擬機器
在某種程度上，Java原始碼需要成為平臺自帶的可執行程式碼。這個過程一般需要兩個步驟：開發人員將原始碼編譯成Java位元組碼，然後Java虛擬機器（JVM）將其轉換為主機平臺的原生代碼。第二步最初是通過解釋方式執行的：讀取每條JVM指令，然後動態地將其轉換為一條或多條本地指令。然後，在程式開始執行時，實時（just-in-time，JIT）編譯器將所有的Java程式從JVM位元組碼轉換為原生代碼。如今，該過程有多種實現方式。Sun的HotSpot編譯器在執行時解釋並分析程式碼，編譯並優化對程式的操作最為關鍵的那部分。IBM的JVM工作原理與此非常類似。這些方法避免了由於對整個程式進行實時編譯所導致的啟動時效能下降，隨著時間的推移，效能將會恢復，因為關鍵的程式碼部分已被定位並優化。長時間執行的伺服器程序很適合採用這種方法，但這對客戶機應用程式不太適用。
就像基本型別一樣，現在批評人士認為Java的這個兩步編譯週期是一種不成熟的優化方法。他們提出疑問：如果要等到執行時將Java位元組碼編譯為原生代碼，那麼為何不採用解釋Java原始碼（而非Java位元組碼）的方式，從而為開發人員節省一個步驟？正如Tate在《Beyond Java》一書中所說的那樣，“Java並不是最簡單的語言。它對很短的迭代也不友好……其他語言允許輕鬆地應用更改，而無需麻煩的編譯/部署週期。”
沒有Java的JVM
實際上，Tate在尋找秉承Java成功表現的後繼者的過程中抱有這樣的理念：“下一個在商業上取得成功的語言應該擁有在JVM上執行的版本。這將有助於該語言克服許多障礙，不管是在策略上還是在技術上。”他指出，虛擬機器方法可提供安全性（“如果能確保虛擬機器的安全性，則要確保語言的安全性就容易得多了”）、可移植性、互操作性和可擴充套件性。由於JVM已有效地解決了這些問題，因此如果新語言可執行在已安裝於數百萬臺計算機中的JVM上，那麼它就不需要自己的虛擬機器。
在許多方面，這種情況業已發生。用Java為指令碼語言編寫直譯器可有效地將這些語言移植到JVM上，如：用於JavaScript的Rhino、用於Python的Jython或者用於Ruby的JRuby。
但也可以完全繞過Java語言，而直接進入JVM級別。已經有一些將C轉換為JVM位元組碼的編譯器，如商業工具Axiomatic Multi-Platform C，它提供了ANSI C的子集。而且，Java位元組碼處理工具（如ASM和Apache BCEL）的發展允許Java應用程式在執行時建立可執行的類。這些類不再是Java語言，而是一種用於JVM程式設計的有效組合語言。
或許由於意識到了在JVM上執行非Java程式碼的需求，最近已提交了一項新的JSR（Java規範請求），即“Supporting Dynamically Typed Languages on the Java Platform（在Java平臺上支援動態型別化語言）”（JSR 292），它指定了一種新的位元組碼，將使JVM更適用於執行不含靜態型別資訊的語言。
沒有JVM的Java
也可以從另一個角度來看問題，即不使用JVM而執行Java。畢竟從某種意義上講，Java原始碼轉換為位元組碼，反過來位元組碼又轉換為原生代碼，沒人會說這些轉換不能一次完成。GNU Compiler for Java （GCJ）允許一次性地將Java原始碼編譯為一個平臺的可執行程式碼。不過它尚不完善，不支援Abstract Windowing Toolkit（抽象視窗操作工具包，AWT），因此它不適用於AWT或Swing GUI程式設計，但它的功能足以編譯伺服器端和命令列應用程式。
該流程有一個明顯缺陷：跨平臺的程式碼在一步中必須繫結到一個平臺。此外，靜態編譯並非是HotSpot的動態編譯所擅長的。筆者曾參與一個專案，結果發現，與HotSpot版本相比，GCJ帶來的效能提升不到5%。儘管如此，GCJ還是可以解決一些重要問題，如部署可執行的Java應用程式，而不必擔心JVM是否可用或者在執行特定的版本。
Java Community Process
Java領域除了語言、庫和虛擬機器外，還有一個Java社群。儘管有大量用Java編寫的開源軟體，但在整個Java社群與開源社群之間仍然存在著公開且明顯的矛盾。這在很大程度上可歸咎於Sun不願在適當的開源許可下發布它的Java實現，雖然這些原始碼可在各種Sun指定的許可下獲得。
有人說，這種衝突被大大地誤導了。開發人員Bruno Souza在O'Reilly最新一期的Distributing the Future播客中講到，這種反對Sun的爭論完全誤解了Java的性質，因為語言、庫和虛擬機器都是由開放且透明的Java Community Process制定的標準集：“其中的所有Java標準都被實現為開源軟體。至於Sun之外的組織是否執行Java標準，我認為這區別不大。最重要的是，JCP的規則非常清楚。JCP是非常開放的標準組織。當然，它並不完美。但我認為一個非常重要的事實是，JCP建立標準，而您可以實現這些Java標準的開源形式。這極為重要，因為這就是我們想要的組合.... ”。
有人會說Java不是開源的，這樣說毫無意義。因為說Java是或不是開源的並沒有什麼實際意義。這就像說HTTP是不是開源的一樣沒有實際意義。
實際上，Apache Harmony專案正在開發旨在成為“獲得全球認證”的J2SE實現，它可在Apache License V2許可下獲得，而且JCP允許並鼓勵所有這些工作。
JCP之外的社群
但是，仍然存在許多並未採用JCP標準的Java專案。如前所述，Java是開發SourceForge專案的首選語言，但在java.net、Apache Jakarta Project、Javalobby的Javaforge、OpenSymphony以及其它無數獨立站點上可找到更多的開源Java專案。在人們心目中，其中許多專案已經成熟，可與官方的JCP標準進行競爭，顯然其中大部分是輕量級企業框架，如Spring framework，它誘使許多開發人員對EJB 2.1之類的“官方”規範感到失望。獨立專案也快速適應了Java外部的變化，併產生了它們的最佳特性，如Rails，它就是改進後的Trails，或者如AJAX，它簡化了Direct Web Remoting （DWR）專案。
結束語
十年來，數百萬開發人員已使Java的面貌發生了巨大變化。現在需要推翻以往有關Java的假設了：語言與虛擬機器之間的耦合、它與開源領域對立的錯誤描述，以及常見的對其效能或缺點的批評。在未來十年內，Java將變得完全不同，且發生巨大變化的潛力不在語言本身，而在於關注點。屆時，許多開發人員將繼續在不同的環境中使用不斷髮展的Java語言，而其他人則將在虛擬機器上執行許多種不同的語言。不久以後，“什麼是Java”的問題就會轉變為“哪個Java？語言還是虛擬機器？”這個問題。