Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
.to_d acts differently in jRuby 9.0.x than Ruby 2.2.x #3504
How to replicate
Open up IRB in jRuby 220.127.116.11:
require "bigdecimal"; nil.to_s.to_d => #<BigDecimal:4d6025c5,'0.0',1(4)>
Opening up IRB in Ruby 2.2.3:
require "bigdecimal"; nil.to_s.to_d NoMethodError: undefined method `to_d' for "":String from (irb):1 from /Users/ootoovak/.rubies/ruby-2.2.3/bin/irb:11:in `<main>'
Ah, so jRuby includes the
Hmmm. I wonder what is loading bigdecimal/util? It is something in our bootstrapping that needs it and we just happen to include it (and obviously MRI is not doing that). I guess if we knew what was loading it then perhaps we can try and do something else. However, in this case any foreign code you interact with might load this library (or over time you may end up inadvertently requiring it) so having any code which expects this to be undefined would end up being dicey...
In my mind it is unclear this is really an issue we should address.
[Actually having written all that I did a grep and I think we might have made some simpler ext mistake. I see in core/src/main/ruby/jruby/bigdecimal.rb we define BigMath in Ruby. This will force require bigdecimal/util (log and exp need .to_d). We must be requiring this file on boot. Do we really need to require this file for this iml? We could move requires into the log and exp methods but that will have a perf impact...hmm]
referenced this issue
Dec 9, 2015
I looked at this for a minute and realize that our kernel loads kernel/bigdecimal.rb for BigMath (which I think normally should only be included for bigdecimal/math but I am guessing isn't?). This file will unconditionally load bigdecimal/utils since it uses it for its impl.
I think the real issue now is determining whether we are unconditionally loading bigdecimal/math when we shouldn't be or something needs it.