and I want to make sure I call the second method but with a null component then in java I do this:
obj.doSomething((Component)null, 0)

But in jruby I haven't found a convinient way to do this. My current solution is to use reflection something like this:
method = obj.java_class.declared_method(:doSomething, Component, int)
method.invoke( obj, Java.primitive_to_java(nil), 0 )

If instead there was something like a null method on wrapped java classes this would be much nicer:
obj.doSomething(Component.null, 0)
The null method could return an special object that the jruby Java method finding code could use to find the correct method in java.

Charles Oliver Nutter
added a comment - 06/Aug/09 1:48 AM Ok, now this is a real need for sure, and one I've known we would hear about eventually.
Your reflection workaround is clever, and probably the only way at the moment. It is obviously less than desirable.
I think this bug may lead the way toward a practical casting syntax/API we can use for Java integration. I'm marking this a blocker for 1.4.

Scott Cytacki
added a comment - 09/Aug/09 10:03 AM Another option would be to simplify the reflection approach which would then help other cases. Live Connect 3 has something like this:
http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html (see the bottom of the page)
perhaps this could look like:
ObjClass.java_method(:doSomething, Component, :int).invoke(obj, nil, 0)
If this is worth it then there could be some special method on the obj itself so this would be possible:
obj.java_method(:doSomething, Component, :int).invoke(nil, 0)

Scott: That's definitely planned, probably in the form of making the proxy classes (the Class object you get from e.g. java.lang.System-style accesses) provide a complete set of reflective capabilities. For the moment, most reflective logic you would need is available via the Java::JavaClass object you get from calling .java_class, which allows working around most things (in a very painful way).

Charles Oliver Nutter
added a comment - 20/Aug/09 1:47 PM Scott: That's definitely planned, probably in the form of making the proxy classes (the Class object you get from e.g. java.lang.System-style accesses) provide a complete set of reflective capabilities. For the moment, most reflective logic you would need is available via the Java::JavaClass object you get from calling .java_class, which allows working around most things (in a very painful way).

I started to tackle this but it gets pretty involved; we don't have any logic at present for handling a normal JavaClass/JavaObject/proxy wrapping a null value, so we may want to introduce a new custom type that the method selection can recognize. I'm attaching what I have, which does allow typed null references for simple cases but blows up a bunch of tests and specs.

Charles Oliver Nutter
added a comment - 01/Sep/09 5:30 PM I started to tackle this but it gets pretty involved; we don't have any logic at present for handling a normal JavaClass/JavaObject/proxy wrapping a null value, so we may want to introduce a new custom type that the method selection can recognize. I'm attaching what I have, which does allow typed null references for simple cases but blows up a bunch of tests and specs.

Joshua Go
added a comment - 06/Jan/10 7:22 PM - edited Working off the patch that Charles submitted, I just tracked it down and ran the tests to see if I could find the cause of the problem.
The problem was that the change in src/org/jruby/RubyBasicObject.java would cause more involved tests to fail: getMetaClass().dataGetStruct() was returning null.
I've added a check which should preserve the behaviour of Charles's patch while not breaking any tests.
Now, as for whether getMetaClass().dataGetStruct() should ever return null: this is probably better left to a grander effort tackling more general aims, if you guys would like to pursue it.