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