去年，我们将大型Rails应用程序移植到了JRuby，这是一项令人惊讶的工作.当然，它的部分原因与应用程序的编写不当以及具有许多旧代码有关，但仍然如此.如果您想知道:我们的大多数问题都来自我们使用的宝石，那么有时取决于例如当时在JRuby中无法正常使用的FFI.我后来去Rubinius的一个港口似乎没有那么多痛苦，但是为了支持MRI而被放弃了.

We ported a large Rails application to JRuby last year and it was a surprising amount of work. Granted, part of it had to do with the app being rather badly written and having lots of legacy code, but still. In case you wonder: most of our problems came from gems we used, which then sometimes depended on e.g. FFI that didn't properly work with JRuby at that time. A port to Rubinius I did a little later seemed a lot less painful, but was abandoned in favor of staying with MRI.

对于Gemfile，有一个platform选项可以使用.这是Bundler文档中的一个示例:

For the Gemfile, there's a platform option you can use. Here's an example from the Bundler docs:

gem "weakling",   :platforms => :jruby
gem "ruby-debug", :platforms => :mri_18
gem "nokogiri",   :platforms => [:mri_18, :jruby]

它也具有块形式:

platforms :jruby do
  gem "foo"
end

自

涉及组的所有操作(捆绑安装，Bundler.setup， Bundler.require)的行为与任何不匹配的组完全相同 当前平台已被明确排除.

All operations involving groups (bundle install, Bundler.setup, Bundler.require) behave exactly the same as if any groups not matching the current platform were explicitly excluded.

作为MySQL的瑰宝，我将使用恰当地命名为mysql的JRuby.

As a gem for MySQL I'd use the aptly named mysql, there seems to be a jdbc-mysql for JRuby.