pp Object.new shows 0x0000000 instead of a unique number for each object.

looks good to me

A clever but weird patch. One problem with it is that it uses to_java, which for many core types (fixnums, strings, etc) will not produce normal Ruby objects. The subsequent inspectHashCode won't work, as a result.

inspectHashCode is also based on java.lang.System.identityHashCode, which is not guaranteed to be unique (it's just the hashcode the object would have if it weren't overridden).

object_id is probably the right way to do this, even though it has quite a bit more overhead for JRuby. I suspect the real problem here is that we don't (and won't) support the "p" format for Array#pack, and so the mask doesn't work right.

I'll try to patch it in another way. Thanks for the interesting shot at it!

Minimal reproductions, showing only 1.9 mode failing:

system ~/projects/jruby $ jruby -rpp -e "pp Object.new"
#<Object:0x00000000>

system ~/projects/jruby $ jruby -rpp -e "p Object.new"
#<Object:0x5ea1068>

system ~/projects/jruby $ jruby --1.8 -rpp -e "pp Object.new"
#<Object:0xfa0>

Cool. Thanks for the feedback — I was unaware of to_java's behaviour on core types (though luckily this code wouldn't have been called for too many of them!).

It would be nice (if it's possible) to have the same hex string here as is used by the default inspect (though maybe changing the default inspect to use .object_id would be an interesting way to unify them).

MRI's output seems to be largely hacked to produce the "hashy" result in PP that inspect would produce if it weren't already overloaded...so they're trying to basically reimplement inspect's hashy logic from Ruby using these tricks.

Your version may be good enough, if we don't use to_java (since that causes other things to happen). Perhaps it would be ok for us to use JRuby.reference internally, or to add a JRuby.identity_hash that just uses System.identityHashCode?

I'll try the latter.

Thanks .