Hello friends! I work on the JRuby project, and have recently (a couple times in the past year) attempted to get Discourse running. It would mean you can run a single Discourse process for a whole site, and probably use less memory and CPU at the same time. I think it’s worth getting it to run. As with most existing Ruby apps, there are a few missing C extensions. The good news is that most of these extensions appear to have alternatives for JRuby, or they’re trivial enough that it should be easy to just make a JRuby version. I wanted to start a discussion here so we can talk about some of the exts and possible replacements. Any interest in Discourse on JRuby?

Here’s the diff I have at the moment. This is not an exhaustive list of extensions with no JRuby support but it’s most of them. https://gist.github.com/headius/99f7a177b67d635d4783e7f7b164a3c9 Some replacements I know of: fast_xor has been superceded by xorcist, which has JRuby support. pg has a JRuby equivalent in pg_jruby. It lags behind pg a lot (lack of resources). oj may have JRuby support soon; Tom Enebo has a partial port. cppjieba_rb might be extended to support JRuby using the jieba-analysis Java library. I have started a dialog with the author here: JRuby support using jieba-analysis library for Java · Issue #1 · erickguan/cppjieba_rb · GitHub fast_blank (transitive dependency of onebox) was trivial to port to JRuby. My PR is here: JRuby support by headius · Pull Request #21 · SamSaffron/fast_blank · GitHub Presumably unicorn can just be replaced with puma. Both are in the Gemfile. Other exts will have to be discussed.

[image] headius: Presumably unicorn can just be replaced with puma. Both are in the Gemfile. Yes this is totally safe, puma is supported. If we really want to conserve memory here though it may be interesting to run sidekiq inside puma. [image] headius: fast_blank (transitive dependency of onebox) Oh … fast_blank should not be a dependency for onebox, I just removed it, next release will not have it. I think it probably makes sense just to not depend on fast_blank for jruby and set the fast_blank dependency in Discourse to MRI only. String @match? does matching without needing to set globals so it should in theory be fast enough for jRuby. [image] headius: oj may have JRuby support soon; Tom Enebo has a partial port. Happy to make this MRI dependency only for now. [image] headius: fast_xor has been superceded by xorcist, Oh, we should bench this if perf is the same we can move to xorcist

[image] sam: Oh, we should bench this if perf is the same we can move to xorcist The fast_xor README actually says to use xorcist. I believe the code was simply moved there and expanded to support JRuby. Here’s the complete list of exts with status as I know it today. bootsnap: JRuby support · Issue #129 · rails/bootsnap · GitHub fast_blank: Should no longer be transitive dep of onebox, could be MRI-only in Gemfile, or could support JRuby. JRuby support by headius · Pull Request #21 · SamSaffron/fast_blank · GitHub fast_xor: Switch to xorcist. GitHub - fny/xorcist: Blazing-fast-cross-platform-monkey-patch-free string XOR · GitHub fast_xs: This would be an easy port, or could possibly be omitted. JRuby support · Issue #6 · brianmario/fast_xs · GitHub cppjieba_rb: JRuby support using jieba-analysis library for Java · Issue #1 · fantasticfears/cppjieba_rb · GitHub libv8: Transitive dependency of mini_racer. Replace with therubyrhino or the Nashorn equivalent? nokogumbo: Transitive dependency of sanitize. Library wrapper for Gumbo HTML5 parser. Probably could use FFI effectively…it’s very small. JRuby support · Issue #24 · rubys/nokogumbo · GitHub oj: Get Tom Enebo (or help him) to finish his port: GitHub - enebo/oj: Optimized JSON · GitHub pg: Use pg_jruby and improve it as needed. rinku: JRuby support · Issue #75 · vmg/rinku · GitHub unicorn: Only needed on MRI. I updated the gist I linked above, now excluding or replacing all the gems above. With these changes, bundle install completes. I have no idea if Discourse actually works yet though :slight_smile:

@sam any of the easy / obvious replacements we should do next week just to get more obstacles out of the way of this happening.

I just did this. https://github.com/discourse/discourse/commit/79e0cd7f529c14d482b2c5dc1394bc90d6070d56 and https://github.com/discourse/discourse/commit/b301c9f6c12f517ee64e15599d7cac6ed2b9d7d8 and https://github.com/discourse/discourse/commit/c234a14f0de458168adb5100cb7fd9d21a362d7d This leaves, cppjieba, libv8 / mini_racer, nokogumbo, oj, pg and rinku Regarding Rhino, you got to make sure the ruby rhino with latest GitHub - mozilla/rhino: Rhino is an open-source implementation of JavaScript written entirely in Java · GitHub It looks pretty silent there Commits · rubyjs/therubyrhino · GitHub . Ideally I would prefer v8, but at a minimum we would want latest Rhino.

[image] sam: Regarding Rhino, you got to make sure the ruby rhino with latest GitHub - mozilla/rhino: Rhino is an open-source implementation of JavaScript written entirely in Java It looks pretty silent there Commits · cowboyd/therubyrhino · GitHub . Ideally I would prefer v8, but at a minimum we would want latest Rhino. therubyrhino should just work, if not there’s a pretty solid attempt to use the engine provided with Java 8, which is kind of a (direct) successor of Rhino, gem 'dienashorner', platform: :jruby … really depends what the JS engine is used for - if mostly for compiling with the asset pipeline than both are expected to work fine. have also looked into xorcist, managed to run into one issue - not failing properly on frozen strings, but its pretty edge case that is easy to work-around + PR submitted.

[image] sam: We really want to work with JRuby Aside: can y’all share with those of us on the sidelines a little bit about why? Is the notion that JRuby would replace MRI as the default implementation for Discourse in the future if you get this working?

That certainly isn’t my goal! JRuby would always be an alternative, and in some cases it may be a better choice than MRI for larger deployments. A single JRuby instance can handle an entire server load, maxing out all cores. If you are getting to the point of running 3 or 4 or 5 MRI instances, there may be a good case to try JRuby. We also usually perform better, but that may take some tweaking early on.

Getting Discourse running on JRuby

Development

sam (Sam Saffron) February 23, 2018, 12:23am 2

Yes absolutely.

We really want to work with JRuby, what are the current stumbling blocks?

Topic		Replies	Views
Discourse on Truffleruby Development	14	1521	May 16, 2025
Update Gemfile fast_xor platform to :ruby Development	5	1274	August 21, 2022
Why hasn't Discourse been rewritten in Rust? Development	22	1500	July 23, 2024
Which Regex Implementation Does Discourse Use? Development	5	973	April 29, 2020
Is Discourse using Ruby 2.0? Howto use Ruby 2.2 Self-hosting	11	2698	May 19, 2016

Getting Discourse running on JRuby

Related topics