This might be an easy one to track down, so I'll mark with beginner for now.

We don't officially support 2.0 mode on 1.7, so marking this as a 9k bug.

I don't quite get how JRuby manages object ids in the implementation yet, so no fix here but maybe this helps people get started:

Problem in JRuby is that a Float does not always map to the same object id:

>> 1.0.object_id
=> 2042
>> 1.0.object_id
=> 2044
>> 1.0.object_id
=> 2046

Whereas MRI gives:

>> 1.0.object_id
=> -36028797018963966
>> 1.0.object_id
=> -36028797018963966

Also note that there is an existing spec in spec/ruby/core/kernel/Float_spec.rb that is supposed to test exactly that, i guess.

it "returns the identical Float for numeric Floats" do
    float = 1.12
    float2 = @object.send(:Float, float)
    float2.should == float
    float2.object_id.should == float.object_id
  end

But this test actually PASSES also on JRuby, so i guess the spec should also add:
float.object_id.should == 1.12.object_id

Ruby 1.8.x used to allow floats to be modified via scale= and I suspect our logic reflects that it used to be a non-immediate value type.

Oh, I just realized what's causing this: MRI now uses tagged pointers for floats too.

We do not have any way to support tagged pointers, which means that all Float instances are real, allocated, GCable objects with their own identities. Rubinius and other impls also do not use tagged pointers for Float, though some support tagged pointers for Fixnum.

I would call this an implementation detail; you should not rely on two Floats being .equal?.

Did you run into this issue in the wild? I would strongly recommend against ever writing code that expects two value-equivalent Float objects to always be the same object.

I came across it while debugging a build failure on unparser (https://github.com/mbj/unparser). It was fixed in mbj/unparser@fab00e7 by replacing #equal? with #eql?.

I'm fine with calling this an implementation detail and leaving it at that.

Thanks for looking into this.