Allow installation on JRuby #169
Comments
|
👍 |
These will eventually be sourced from the gem. ruby/bigdecimal#169
|
@headius Can we add the empty extension for Java platform same with |
|
@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 |
This proposal seems good first step. Can you file this to ruby/openssl repo? |
JRuby currently ships its own internal bigdecimal extension as part of the core libraries. In order for users to be able to add bigdecimal to their Gemfile or gem dependencies, we need to stub out the C extension and just load the extension shipped with JRuby. In the future we will try to move our BigDecimal implementation into the gem, but for now this is the simplest way to make it installable on JRuby. See ruby#169
JRuby currently ships its own internal bigdecimal extension as part of the core libraries. In order for users to be able to add bigdecimal to their Gemfile or gem dependencies, we need to stub out the C extension and just load the extension shipped with JRuby. In the future we will try to move our BigDecimal implementation into the gem, but for now this is the simplest way to make it installable on JRuby. See ruby#169
JRuby currently ships its own internal bigdecimal extension as part of the core libraries. In order for users to be able to add bigdecimal to their Gemfile or gem dependencies, we need to stub out the C extension and just load the extension shipped with JRuby. In the future we will try to move our BigDecimal implementation into the gem, but for now this is the simplest way to make it installable on JRuby. See ruby#169
JRuby currently ships its own internal bigdecimal extension as part of the core libraries. In order for users to be able to add bigdecimal to their Gemfile or gem dependencies, we need to stub out the C extension and just load the extension shipped with JRuby. In the future we will try to move our BigDecimal implementation into the gem, but for now this is the simplest way to make it installable on JRuby. See #169
|
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. |
Sequel 5.72.0 explicitly depends on the bigdecimal gem, causing JRuby to attempt to use the gem, install native extensions and fail. Pinning to < 5.72.0 until ruby/bigdecimal#169 is solved. Also related: jeremyevans/sequel#2076
Sequel 5.72.0 explicitly depends on the bigdecimal gem, causing JRuby to attempt to use the gem, install native extensions and fail. Pinning to < 5.72.0 until ruby/bigdecimal#169 is solved. Also related: jeremyevans/sequel#2076
|
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. |
|
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. |
The bigdecimal gem now releases a -java version that contains only the .rb files we also use. As a result, we can now depend on it and remove the Ruby sources from our repository. See ruby/bigdecimal#169
|
@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? |
|
@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. |
|
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. |
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:
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.
The text was updated successfully, but these errors were encountered: