JRuby should provide couterparts of MRI Ruby bundled Gems

Ahh, interesting. I did not know those libraries were actually pulled out into gems.

It's probably possible for us to move our version of the libs into gems, but it's something we have not previously attempted. We would also still need to ship bigdecimal built in for 1.8 mode, since there it is not a gem and RubyGems is not loaded by default.

I have started a thread on ruby-core about this. I think the best option might be to have -java versions of the gems pushed that are empty and just there to fulfill the dependency.

Removing BigDecimal from JRuby is not a trivial matter, since we reference it directly from other pieces of code (specifically, from Java integration code in a few places). That's not to say we couldn't potentially do it, but it requires more than just moving the binary bits into a gem.

Marked for pre2. We need to at least have a direction by then.

Thank you Charles!

• Shipping for 1.8 mode is absolutely ok - MRI Ruby 1.8 doesn't work with the bigdecimal gem either, so no problem on this side.
• I'm not familiar with Java loading mechanisms, but I think that it would still be possible to move the file into their own directory alongside other gems, right? (Until it is completely unbundled, this can be easily done by distribution packagers, I think.)

I'll keep an eye on the discussion on Ruby core and try to participate and make some suggestions.

For discussion on ruby-core, see https://bugs.ruby-lang.org/issues/6590.

I think our best bet is getting a stub gem released under the -java platform. We will need to coordinate with ruby-core about this, since they hold the keys to the "bigdecimal" and other unbundled gems.

I would like to put together a patch to submit to ruby-core. Is there a test I can use?

Perhaps something as simple as attempting to activate the gem? Or will that always pass on MRI regardless of whether the gem is present or not?

Well, on the standard MRI Ruby installation, bigdecimal is bundled, so it is always "present" in the sense, that you can use both "gem 'bigdecimal'" and "require 'bigdecimal'". But I think that if "gem 'bigdecimal'" passes on JRuby too, it is exactly the behaviour we are looking for right now (so that it can be used both in gemspecs and Gemfiles).

Is anything failing now? Or is this ticket just theoretical?

Apart from what I have mentioned in the initial comment of this bugreport, you can see https://bugs.ruby-lang.org/issues/6590 (Charles's report on ruby-core). I don't want to to summarize it in this comment, because it would be too long. Just one quick problem that this causes:

1) You have an app, that relies on a fake gem, let's say it's bigdecimal. You use bundler and you want the app to run on both mri ruby and jruby, so you don't place bigdecimal in the Gemfile.
2) New version of bigdecimal gets released and you want to use the new functionality provided in it.
3) Since bigdecimal is not in the Gemfile, it doesn't get loaded as a Gem. The bundled (old) version from MRI ruby gets in play.
4) You have no way to use the new bigdecimal Gem on MRI ruby, while keeping the ability to run the app on jruby too
5) Also, there is no way you can tell that the currently used bigdecimal in MRI provides the same functionality as the jruby implementation, as you can't specify the version in Gemfile (so effectively you have no way of telling what codebase your app is using).

TLDR: It's not theoretical, although it hasn't yet caused any significant problems

OK, so placing bigdecimal in Gemfile is bad (or bigdecimal gem can't be installed on JRuby).

Yes, it is bad, but it shouldn't

It looks like the MRI issue has been assigned, but there doesn't appear to be any action yet. We are largely waiting on them to either give us access to release -java versions of these gems, or to do that themselves.

Still no action from ruby-core. Grumble.