.to_d is actually defined in bigdecimal/util - http://apidock.com/ruby/String/to_d

MRI

require 'bigdecimal'
require 'bigdecimal/util'

nil.to_s.to_d
=> #<BigDecimal:333b970,'0.0',9(9)>

Ah, so jRuby includes the 'bigdecimal/util' lib by default when requiring 'bigdecimal'? That's fine (as I said I prefer it, given those two options) but I still just wanted to note the difference if jRuby was going for the exact same syntax behaviour as MRI (for better or worse). If not 👍 and just good to know and keep an eye out for given that context.

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]

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.