Allow installation on JRuby

[headius]

JRuby has its own bigdecimal library based on the JDK's built-in BigDecimal. We also do not support C extensions, which means this gem can't be installed at all on JRuby.

This leads to issues when users add bigdecimal gem to their applications and try to migrate to JRuby. This will become more of a problem if downstream libraries also start adding bigdecimal, since there's no way to swap in our implementation.

There are two possible ways forward:

• Modify the gem so it does not attempt to build an extension on JRuby and just falls back on JRuby's built-in bigdecimal support.
• Release a separate gem for JRuby that contains our BigDecimal extension.

Of these, the first is clearly the least amount of work. The second would require us to remove all references from JRuby's core classes to the bigdecimal library, which might break some of our public APIs surrounding converting Java BigDecimal to Ruby and back again.

This is the cause of noahgibbs/rsb#12 and that issue would be resolved if this one is resolved.

[jodosha]

👍

[hsbt]

@headius Can we add the empty extension for Java platform same with date gem? And can we add JRuby specific logic to https://github.com/ruby/bigdecimal/blob/master/lib/bigdecimal.rb?

[headius]

@hsbt We would still like to get our implementations of these gems moved into the same repository and released together, but yes for now it would be best if we had some no-op versions that would skip installing the C extension.

At least bigdecimal and openssl need this treatment now. The -java version of openssl should skip installing the extension and depend on our jruby-openssl gem.

[hsbt]

The -java version of openssl should skip installing the extension and depend on our jruby-openssl gem.

This proposal seems good first step. Can you file this to ruby/openssl repo?

[headius]

Is it posible to start releasing the -java stub gem, please? This has now caused sequel to break on JRuby, as it depends on the bigdecimal gem and the CRuby extension is not supported.

jeremyevans/sequel#2076

[headius]

bigdecimal-java 3.1.4 has been released, so I believe this is resolved! We just need the -java version released for each version of bigdecimal going forward.

[headius]

I understand that @mrkn does not want to maintain the JRuby version in this repository, but we still want to spin our code off as a gem.

The best option I can think of today would be for us to create a jruby-bigdecimal gem that contains all of our java.math.BigDecimal wrapper code. At that time, we would update the bigdecimal-java gem to depend on that one. This is similar to how we will need to handle openssl at some point.

[mrkn]

@headius Thank you for understanding my side. Yes, I don't want to maintain the JRuby version when I develop bigdecimal, but also I don't want to cause trouble in JRuby's ecosystem. If you can maintain the JRuby version in this repo without any side effects on the development of the C extension, I want you to do it (I think you already have commit permission in this repo). I want to add you to the gem maintainers if you want to do it. What do you think about this?

[hsbt]

+1

@headius I've shared psych case to @mrkn. I'll support this migration if you interest it.

[headius]

@mrkn I definitely understand your concern! I would not want to be responsible for maintaining C code in a JRuby project either.

For other cases like this, we take ownership of the Java version of the library and make sure it passes appropriate tests for each release. In the case of bigdecimal, we already don't pass all the tests so anything we add to your CI would only be to make sure we don't regress further. That should prevent failing tests from breaking your build, and we would try to pass more tests going forward.

In general i don't expect to have to make many changes over time. We are limited by the features of the Java bigdecimal implementation, so most fixes will be limited to minor API changes. I wish there were a better way, but unless the gem has a Java version, nobody can depend upon it in JRuby. Since it is being moved to a bundled gem in 3.4, I needed the gem to be available now.

I have it on my list to try to move our code out to a separate library. Once I'm able to do that we can talk about integrating it into this repository, either by importing the code or by depending on a JRuby specific gem.

[headius]

Let's call this one resolved with the -java stub! I will open a separate issue for the ongoing questions about maintaining the two implementations together.