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具有同样功能，充分利用了动态机制和元编程技术来支持多种测试: 单元测试、功能测试以及集成测试。

　　如果你现在正在使用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适用于这种渴望比较强烈的新项目和新组织。