You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This bug has quite many moving parts. I've tried to summarize them below. Hopefully the included code example makes the case clearer.
Reproducing this bug requires the following:
A: Java class that has been reopened in Ruby where an inherited hook has been added
B: Ruby subclass of A
C: Java interface that defines one method that returns A
D: Ruby implementation of C that creates an instance of B as its return value
E: Another Java method that accepts an implementation of C and calls its method
When D is passed to E, A is returned instead of B. If the inherited hook is removed from A, then B is returned as expected.
If the object proxy cache is enabled, the code works "most of the time." A is still returned instead of B "randomly." This bug was originally reported by my colleague back in 2011: ago: http://jira.codehaus.org/browse/JRUBY-6151
I've tried to make a minimal test case that includes both the broken inherited implementation as well as a class that has no inherited and works as expected.
turns out JI depends on super's inherited being called, otherwise Java sub-classes might not work correctly. this is fine when inherited is not overriden (as the test confirms) in the Ruby sub-class but fails otherwise. work-around for now is to call super in the inherited callback.
@headius I'm thinking of creating a thin internal RubyClass sub-class ProxyClass.java ... that would solve the need for relying on inherited called from Ruby-land. I think it might be useful for the future to have a ProxyModule (for proxied interfaces) as well to eaze the pain of hooking up these. let me know if you can think of any reason not to. I'm hoping to test the ProxyClass out soon-ish