1) Failure:
test_event(TestSetTraceFunc) [test_settracefunc.rb:89]:
<["c-call", 32, :new, Class]> expected but was
<["c-call", 32, :initialize, Exception]>.

the new patch doesn't contain other equality fixes yet:

missing Method: Proc#==
missing Method: Method#==
missing Method: UnboundMethod#==
extra Method: Time#===

maybe the failed test relies on Method comparison (but guessing now)

attached new patch (not final one) and current JRuby/MRI api diff

there's more work left for tomorrow though, any further thoughts ?.

• RubyKernel#eval needs to pass "0" as the starting default line number to eval, not 1
• RubyKernel#raise appears to be responsible for a call to backtrace and another to set_backtrace when constructing a simple RuntimeError. This could indicate that we're missing some call steps in the exception construction sequence that Ruby has.
• RaiseException currently does a "return" trace on the current frame's information which should actually be a "raise" trace on the previous frame's.
• interpreted methods can result in only their return event firing if a trace is set while they're running and still exists when they return. Previously in DefaultMethod the return event would only fire if the call event fired previously.
• Exceptions should be constructed by actually invoking "new" on the appropriate class, not by just constructing a RubyException manually. Ruby expects "new" to be called along with "initialize".

Since the patch breaks ant test, it still needs work. All these changes except the stuff inside RubyKernel#raise seem mostly reasonable...though they have some small potential to add a bit of overhead. The backtrace/set_backtrace stuff needs a better explanation...my hacked way of making it pass is not sufficient.

Note three tests are marked as failing under Ruby 1.8.5, in spite of documentation stating that they should pass.

I've added method_equality_test.rb to define the expected behaviour of the missing == methods. I hit the issue when switching a Rails project from Ruby 1.8.5 to JRuby 1.0.1. There is no way to implement these in user code as the internals of all three classes are hidden in both implementations.

Also, I found it frustrating in Ruby that == is defined on these three classes in terms of having the same body (which is preserved under method aliasing), and yet eql? and hash are not defined in a similar way so none of them can be used effectively as Hash keys, which is my target usage.

I am currently working around this in Ruby by defining UnboundMethod#=hash to be a fixed number, which works but means my Hashes degenerate to associative lists. I will log this as a feature request on the appropriate Ruby issue tracker, but I just wanted to mention it here for interest's sake.