I hope this is related to the problem I posted in April on the email list. In summary: We have a Java class with two instance methods that have one argument:
method (double x)
method (Foo a)
Class Foo is also a Java class and has a method:
double __float__() {....}
The problem is that when I do this in Jython:
a = Foo(10)
b = Bar()
b.method(a)
Jython seems to fetch the __float()__ value from Foo and then uses the
"method(double x)" signature. In my mind, it should use the
"method(Foo val)" signature and pass in the instance of Foo. In the
actual case, this is what we need to happen (and what 2.1 did).

Apparently this is impacted by "faux" float support in PyObject#__tojava__ (as of 2.5). Given that floats have higher matching priority in ReflectedArgs the call path ends up not selecting what these users consider to be better matches in overloaded methods.
Instead, the precedence should go to a nonconversion path, if available. Changing ReflectedArgs#match seems to be the place to select this.

Fixed by r7066.
tomw2 should adopt a similar solution to what was done with PyComplex#__tojava__ - there doesn't seem to be a reasonable way to indicate a preference without a rewrite of our reflection support. Therefore, modifying or adding __tojava__ seems like the better solution:
// Special case __tojava__ for bug 1605, since we broke it with our support for faux floats.
@Override
public Object __tojava__(Class<?> c) {
if (c.isInstance(this)) {
return this;
}
return Py.NoConversion;
}