“Java虛擬機”令程序員迷失？
Java目前不可謂不火，但是由于JVM虛擬機帶來的一些問題隱患，不得不引起我們的注意。虛擬機甚至可能將Java帶入萬劫不復的境地。
在Java出現之前我一直是Smalltalk(注：Smalltalk被公認為歷史上第二個面向對象的程序設計語言，和第一個真正的集成開發環境。)的愛好者。從Smalltalk轉向Java的經歷，到現在依然讓我記憶猶新，從一門語言轉向另一門語言并不是一件輕松的事情。我依然記得當你真正掌握這門新語言時所到達的臨界狀態，掌握一門新語言往往需要花費數月甚至數年的時間，經過這段時間的歷練，你才能做出真正優秀的設計，以及知道如何最好的應用它的哪一個模式，如何避免錯誤發生，以及如何進行性能調優等等。
最近因為工作需要，我要回過頭來看一些以前的Smalltalk代碼，這時我發現，在經歷過這一段學習Java編程的階段后，我已經很難清晰的理解過去自己所編寫的Smalltalk代碼，很明顯，我肯定不能再稱自己是一個合格的Smalltalk程序員。
說這些只是為了表達我的一個觀點：我認為每個人只可能精通一門編程語言，換句話說，如果你什么都精通，其實也就說你什么都精通。我喜歡一個只有一門語言、漂亮簡單的“扁平結構”世界。在這樣一個世界中，程序員之間交流會變得更加輕松，每個人可以彼此分享共同的經驗，而且不也不用來回的在不同的語言之間跳來跳去。
當Java第一次面世的時候，曾經有些Java虛擬機方面的家伙進行一些沒有前途的嘗試：讓Java運行在Smalltalk虛擬機上。盡管他們擁有一個非?？岬慕凶鐾ㄓ锰摂M機(Universal Virtual Machine，UVM)的技術，但是歸根到底，這實際上還是一個保護Smalltalk地盤的反抗行為。從理論上說這可能是一個好的思路，人們不再用必須學習一種新的語法就可以體驗新語言的好處;但是實際上并非如此，使用Java本地接口JNI編程來使兩者聯系起來是一件令程序員非常痛苦的事情，這簡直就是一場噩夢，程序員在編程的時候要陷入很多麻煩，例如在不同語言類型之間存在很多數據類型轉化的問題。
要想在Java下進行Smalltalk編程，或者在Smalltalk下進行Java編程，你需要非常精通兩種語言，而且你需要擁有一個非常發達的大腦來調試虛擬機注冊表和大量設置DOS堆棧的個數。
數年以來，微軟的家伙一直在抨擊Java程序的速度慢，它們認為Java程序是解釋型字節碼，而不是完全編譯好的，這也是人們懷疑Java性能的一個主要借口，而多數微軟的語言則都被編譯為解釋好的p-code。然而現在微軟又開始鼓吹它的通用語言運行時(CLR)，將其稱為編程的圣杯。這一點和 Smalltalk/Java混合UVM非常相似。實際上，CLR上似乎只運行微軟的語言，自從其問世以來并沒有引起太多其他語言的程序員倒戈。
現在有一種現象令我感到非常憂慮，“Java虛擬機可以完成一切”的觀點正在逐漸復蘇。人們的精力不再集中在Java和這個語言向前發展所需要的改進上，人們把精力都投入到讓Java虛擬機JVM去運行Ruby、PHP或其它同類流行語言上，還有讓Java虛擬機支持Java FX這個幾乎和Java語法無關的技術上。如果這一切都實現了，留給我們的又是什么呢?
我們擁有了一個不僅僅可以運行Java還可以運行其它語言的虛擬機;我們擁有了很多不使用Java編寫但可以編譯為Java的語言;我們擁有一些失去了自身價值定位的東西。換言之，我們迷失了自己的方向，失去了準確的定位。
對于我們這些編程序的人來說，我依然認為熟練掌握多種語言實際上是行不通的，我們最終會變為二流程序員，只能編寫性能糟糕和設計惡劣的程序，更不用說隨著環境和語言的切換，調試方面的噩夢隨處可見。
那么為什么人們對虛擬機的熱情如此高漲呢?你或許會說，其它語言是動態的而Java是靜態的;或者其它語言像PHP、Ruby更適于Web編程;或者什么其它的原因?這些都是現實，不過我認為，我們應該去完善Java來解決這些問題，而不是增加復雜度朝著虛擬機使勁，讓其支持這些幾年前已經不存在的語言。對于Java來說，沒有什么錯誤和難題是不可以被解決的。我認為這才是人們應該關注的地方，而不是讓JVM變成一個雜而不精的東西，否者Java最終將面臨與Smalltalk相同的命運。
歷史總是在驚人的重復，如果我們不把Java看作一門語言，而僅僅看作是一些“Java技術”之類的東西的話，我們就正在讓它走向滅亡，使其相對于其它語言的優勢逐漸削弱，同時也讓編寫優秀軟件變為一件更難的事情。
【編輯推薦】
