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