Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: JRuby 1.4
-
Fix Version/s: JRuby 1.7.0.pre2
-
Component/s: Java Integration
-
Labels:None
-
Number of attachments :
Description
Currently method selection uses only a few coarse-grained facts to determine a best match for incoming Ruby values:
- Exact type matches
- Assignability of coercion product
- Implementability of target types
When passing a Fixnum to a method with two overrides, one that takes Object and one that takes Integer, because Fixnum's "natural" Java type is Long, both of these options currently appear to be equally valid. Neither is more exactly matching, and neither is a better assignment target. Because of this, when the Object version comes first in method selection, it may be chosen rather than the Integer version.
This is currently causing two failures on IBM's Java 5 JDK:
1)
'A Java object's java_method method produces Method for static methods against an instance' FAILED
expected: #<Java::JavaLang::Integer:0x473e473e>,
got: 1 (using ==)
...
./spec/java_integration/methods/java_method_spec.rb:22:
...
2)
'A Java object's java_method method produces Method for static methods against a class' FAILED
expected: #<Java::JavaLang::Integer:0x40a640a6>,
got: 1 (using ==)
...
./spec/java_integration/methods/java_method_spec.rb:33:
...
Fixing this will require implementing a more complete Java method selection protocol, which should come in JRuby 1.5.
I patched the failing specs in 6bbcf1e. Ideally this change should be reverted once this is fixed.