I really admire the work of Charles et. al. and we have a couple of Rails apps on top of Jruby in production. Unfortunately, while the language implementation is itself is developed constantly, the ecosystem has stalled.
The activercord jdbc driver implementation is particularly problematic because it effectively keeps us from upgrading to Rails 5 (we use SQL Server as backend). There is also a lack of app server options. The Jruby app servers like Trinidad or Torquebox are not maintained. Warbler has issues, too.
Charles and the other devs can, of course, spend their time however they want, but from my perspective, having a well maintained software stack for production deployments is far more important than a further speed optimization.
I'm not sure if you've looked recently, but we support the big three databases up through Rails 5.0, with sqlite3 support available for 5.1 and mysql and pgsql coming very soon. We need help keeping up, but we're not that far behind anymore after making a big push for Rails compatibility this past year.
SQL Server support still exists in our codebase but it has not been updated due to lack of resources. We want to continue to support it, but there's only three of us working on this stuff at all, and only two do this as our jobs!
As far as app servers...we recommend deploying like other Ruby folks do, using Puma as a server in multithreaded mode. Torquebox has unfortunately been put on hold because there are no resources to maintain it...but Puma works very well.
The activercord jdbc driver implementation is particularly problematic because it effectively keeps us from upgrading to Rails 5 (we use SQL Server as backend). There is also a lack of app server options. The Jruby app servers like Trinidad or Torquebox are not maintained. Warbler has issues, too.
Charles and the other devs can, of course, spend their time however they want, but from my perspective, having a well maintained software stack for production deployments is far more important than a further speed optimization.