Rails正迅速成為輕量級Web應用開發方面的領頭羊。有了JRuby， Rails就有望獲得Java庫和JVM具有的功能、效率及業界認可度。
JRuby是面向Ruby、基於Java虛擬機（JVM）的一種解釋程序，它結合了Ruby語言的簡易性和功能強大的JVM的執行機制，包括與Java庫全面集成。Rails徹底加快及簡化了Web應用的開發，不過它讓人覺得不夠成熟，特別是在高端企業級功能方面。另一方面，Java平台及其虛擬機、庫和應用服務器的速度、穩定性和功能方面卻一直在提升，現在已被公認為是開發高端服務器應用的領先平台。不過如果Java平台不與Ruby等新興語言聯系在一起，就有可能落後於流行趨勢。
JRuby結合了所有這些技術互為補充的優點，有望提高Ruby和Rails的知名度，同時為Java平台在運行非Java語言方面賦予新角色。
Rails: Java框架的發展方向
對Java開發人員而言，Rails就像是自然代表了諸多Java Web框架的發展趨勢：減少不必要的代碼、采更多的抽象和動態機制，以及更全面的即開即用功能。
約定優於配置
早期版本的Java平台企業版（Java EE）每個組件需要有大量的配置和代碼。譬如說，Enterprise JavaBeans的每個bean要有多個源代碼和XML配置文件。這種復雜性使得EJB成了重量級開發的代名詞，最終導致EJB 3出現了180度大轉變: 力求普通Java對象（POJO）bean的冗余和配置最小。即使如此，重型Java EE應用程序仍需要開發人員開發代碼來表示多個軟件層（包括GUI、業務邏輯和持久層）上的同一業務對象。然後，盡管層與層之間存在冗余性和相似性，開發人員仍必須用配置文件把這些層粘合起來。相比之下，像Seam和Spring這些比較新的Java Web框架使用極少的配置和代碼，就可以發布業務對象。
Java框架也一直在向跨Web應用程序的多個層對堆棧進行標准化和集成邁進。在早期，Java Web應用開發人員手工編寫代碼，從服務器小程序獲得HTML輸出；創建自己的模型－視圖－控制器（MCV）架構，並使用SQL而不是Java數據庫連接（JDBC）來訪問數據庫。後來，他們聚集了執行大部分通用功能的組件，譬如標記庫、Struts和Hibernate。最近，Spring將大部分功能集成到了單一、自上而下的輕型堆棧。
從一開始，Rails就體現了這些簡潔性原則，這些原則在Rails社區中稱為“不要重復自己”和“約定優於配置”（避免冗余和有意義的默認值是軟件工程領域中的兩條古老原則）。該框架可以根據簡明的約定，猜出不同層的連接關系。Rails甚至可以顯式、動態添加屬性從而反射數據庫列: last_name列會自動使last_name屬性出現。
在約定不能滿足要求的特殊情況下，仍可以使用純Ruby代碼或者類似Ruby的輕型YAML格式來添加配置，這兩種格式都刪去了XML的冗余方括號和結束標記。
動態和反射機制
Java框架也一直在向反射和元編程機制使用更廣泛而邁進。譬如說，Spring使用反射機制，利用依賴注入把各部分連接起來；標准的Java EE服務器系列則通常采用靜態方法。Hibernate這種流行的對象關系映射框架利用動態元編程進行映射，在運行時更新字節碼，而不像早期的數據訪問框架需要在開發時生成大量的源代碼或者字節碼。
Hibernate的開發人員之前只好采用一些高級技術來實現這項功能。而在Ruby中，元編程卻是這種語言的一個有機部分，結果Rails在運行時不但能動態生成映射，還能生成訪問及顯示底層數據庫所需的業務層類定義，從而盡量減少了這種需要。
支持開發過程
上世紀90年代末前後，Java開發人員大量使用JUnit框架的測試方法，但為服務器端應用程序編寫測試用例總是有難度的。如今Spring在生成Web應用程序的同時還能生成測試。Rails具有同樣功能，充分利用了動態機制和元編程技術來支持多種測試: 單元測試、功能測試以及集成測試。
為什麼在JVM上運行Rails
如果你現在正在使用Spring和Hibernate等Java框架，那就用不著改變。但如果可以靈活地為下一個項目選擇新的開發方法，不妨考慮Rails。
遺憾的是，改用一種新語言一般被認為是危險舉措，管理人員對風險有顧慮。JRuby能夠讓Rails更容易被管理人員所接受。在JVM上，Rails成了一種Java框架。譬如說，“Java”Web框架中的非Java語言實際上同樣用於JavaServer Pages中。
就像通常用C/C++編寫的操作系統為使用比較抽象的語言編寫的應用程序提供了基礎架構一樣，Java平台也為Ruby等動態語言扮演“系統軟件”的角色，提供了基礎架構層面的支持。如今可以通過Java訪問眾多的功能。JDBC和Java消息服務（JMS）等API是同類中最佳的，而許多不可替代的內部或者獨立軟件開發商的企業信息系統可以通過Java API來訪問。Rails應用程序通過使用JRuby，可以像調用Java代碼那樣調用現有的Java庫。
有了JRuby，Rails應用程序可與Java Web應用程序在現有的Java EE應用服務器上一起運行。這種應用服務器擁有強大的技術基礎架構。在人員和培訓方面，通常不缺乏教育計劃以及有經驗的開發和支持人員。另外只要運行在JVM上，這種應用服務器就能夠獲得最近十年在JVM方面投入的許多優化項目所帶來的好處。
JVM擁有比Ruby復雜得多的安全模型，為JRuby on Rails提供了處理Web應用程序的常見安全難題的工具，包括控制從各個來源獲得的Ruby腳本。它還包含了內部支持國際化的功能。
向動態語言邁進，這是在抽象機制方面向更高級語言發展的一個方面。在JVM的管理環境下而不是在操作系統層面上運行Ruby解釋程序又是向更高抽象層邁出的一步。使用Rails作為Web應用程序層的標准實現機制也是如此，只把針對特定應用程序的功能留給了開發人員。
鏈接：JRuby面臨的難題
正如版本號所示，JRuby 0.9.2還沒有准備好運行生產應用程序。一些錯誤有待解決；另外，目前JRuby的速度不如MRI。與Rails一起使用Java應用服務器需要非標准的適配器服務器小程序，而構建war文件需要特殊的Ant腳本，這兩者還不是JRuby發行版的標准部分。
Rails在處理遺留組件方面的功能特別弱。雖然Rails為解決大多數常見問題提供了很好的支持，但缺少支持替代方案的靈活性。譬如說，活動記錄假定每個表都有一個名為id的單一主鍵列。雖然可以用鍵列代替另一個名稱，要是不使用特殊插件，就無法定義多列鍵。相比之下，Hibernate等Java框架雖然在簡單（且常見）的情況下開發速度比較慢，但處理極端狀況和遺留代碼的效果比Rails好得多。
最終，采用Rails面臨的主要難題在於，是否渴望現有語言和框架方面統一標准。Rails適用於這種渴望比較強烈的新項目和新組織。
