This is a funny one. The bug itself is present in JRuby 1.6, but upgrading stdlib from 1.9.2 to 1.9.3 merely exposed it.
Compare Float#to_d in 1.9.2-p290: https://github.com/ruby/ruby/blob/866f369446da5fdbfa315f40571025b8075d31ce/ext/bigdecimal/lib/bigdecimal/util.rb#L18-22 and in 1.9.3-p0: https://github.com/ruby/ruby/blob/7da63cd80fa13606e17b29f3a79dc0b00e809ef0/ext/bigdecimal/lib/bigdecimal/util.rb#L18-33
The crucial difference is the presence of the second argument in the 1.9.3 version.
The code branch is different when we call BigDecimal.new with precision. JRuby code has not changed; even with 1.6.x, we still have this problem:
$ ./bin/jruby --1.9 -v; ./bin/jruby --1.9 -e 'require "bigdecimal"; p BigDecimal.new(1.1,16)'
jruby 1.6.7.dev (ruby-1.9.2-p312) (2012-02-06 9677219) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java]
TypeError: can't convert Float into String
new at org/jruby/RubyBigDecimal.java:353
(root) at -e:1
In general, we are dealing with the string representation of an Object when we get to this code path. However, currently RubyBasicObject.convertToString() is used, which is not good for Floats and Rationals. Thus the problem above manifests for Rationals as well:
$ jruby -v; jruby -e 'require "bigdecimal"; p BigDecimal.new(Rational(1,2),16)'
jruby 1.7.0.dev (ruby-1.9.3-p28) (2012-02-06 1c3a405) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java]
TypeError: can't convert Rational into String
new at org/jruby/ext/bigdecimal/RubyBigDecimal.java:367
(root) at -e:1
Note that switching to asString() is not sufficient here, since Rational#to_s returns something like "1/2", not "0.5".
I also note that the second argument has no effect on the return value.