最近我們收到一封電子郵件，咨詢 “什麼是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？語言還是虛擬機？”這個問題。
原文地址：http://blog.csdn.Net/futurelight/archive/2006/04/05/651195.ASPx
