Forum: JRuby How do I find a Java method like JRuby java_send does?

Hi there!

This is from the Ruboto project.  I have included the larger problem to 
encourage new ideas for solutions.

We have an option hash that is converted to Java setter method calls. 
Today we use "send" with the adapted method name and the given 
arguments.  Now we want to allow sending "int" arguments defined by Ruby 
hex literals like 0xFFB90706.  In Ruby this becomes a positive Integer, 
while in Java this literal becomes a negative int.  When trying to call 
a Java method accepting an int argument we get the error "too big for 
int: 4290316038" which is reasonable since we try to send a number 
larger than an int can hold.

So we want to subtract 0x100000000 from arguments to int parameters if 
their value is between 0x80000000 and 0xFFFFFFFF

We only want to do this for int parameters, and we do not want to 
interfere with the regular JRuby election of which method to call. 
Especially if there is an overloaded method with an implementation that 
accepts a long instead of the int, we want that method to be called as 
usual.

How do we best do this?  Any advice is appreciated.

Our current code:

method_name = "setMargin"
args = [0xFFB90706] # this should be converted to [-0x46F8FA]
button.send(method_name, *args)

We have tried a few things, but it boils down to getting the correct 
method without knowing the parameter types.  We need an answer to this 
query:  "Give me the method with the given name that would be called on 
this object with the given arguments."  We would then iterate over the 
arguments and parameter types and convert the int arguments that fit our 
criteria.

Any thoughts?

--
Uwe Kubosch
http://ruboto.org/

As far as I see it, it seems inevitable to create a special subroutine 
that
analyzes the Ruby hex literal in order to determine whether it will fit 
to
the intended type range in the Java world, or am I missing something ?
Unfortunately, this would lead to some ugly boilerplate code, but at 
first
look I can't think of anything better, mainly because the two ranges of
values do not match well with each other.