|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Charles Oliver Nutter - 27/Jul/08 03:03 PM
Thanks for the regression report Rod...should be easy enough to fix, I'll look into it.
This should be fixed now, and I also added appropriate smarts to select the more specific primitive-typed target method based on the size of the incoming Fixnum or Float. Specs have been enabled in spec/java_integration/coercion_spec for this logic.
Reopening...I was a bit hasty in marking it resolved.
I think the problem is that rather than search for a best match in integer types first it's probably picking up the float types and doing an assignable search. Since int is assignable to float, it never continues to search for int typed methods that might be a better match. I'll see if I can't tighten up the logic a bit. I'm also considering looking into Attila Szegedi's dynalang MOP, which he claims does JLS method selection for Java types. If I can wire that search logic into our Java integration layer, it might solve a lot of issues. Ok, I rolled back my "enhancement" and went with code that better mimicked the 1.1.3 method search logic. It does fix your exact case now, but I haven't come up with a test for it. So let me know that it's working while I try to formulate a good test that fits into our suite. Fixed as of 7310.
It fixes that test case, but unfortunately not my actual issue. I'm having trouble nailing down another test case, so here's a very short version of the real problem that still occurs. It requires jscience.jar (from jscience.org: http://jscience.org/jscience-4.3.1-src.zip
 ). I hope this helps.
include Java class Numeric puts 3.kg Results with 1.1.3: Results with 7310: Here's the link to the binary download that actually contains jscience.jar: http://jscience.org/jscience-4.3.1-bin.zip
Marking as blocker. 1.1.4 this week needs this fix.
I just committed a fix and Tom's working on a spec. Your revised case, with JScience, now works correctly. It's a fairly primitive fix for now, scoring methods both on whether the arguments are assignable AND an "exactness count" but it should solve the majority of cases. Post 1.1.4 we'll look at getting a more complete JLS-standard scoring mechanism in place, either by repurposing code from Dynalang or by examining what Groovy, Rhino, et al do. Please let us know ASAP if you see any additional issues.
Specs coming in a moment. Blast it all, I know it was fixed. I wonder if the commit didn't get pushed correctly. I'll investigate.
Argh. There were two problems, and I'm not sure whether they were introduced after my change or came along with it.
First off, a different overloaded version of the method selection logic is getting called for your test. I think we wandered away from your test into a hand-written specification of our own that didn't follow the same path. Second, it seems a ! snuck into the exactness scoring logic and somehow flipped the logic so it's picking the LEAST exact method. I have no frigging clue how this happened. I've fixed the overload (deleted), removed the cursed ! and this is my result running your script now: ~/NetBeansProjects/jruby ➔ cat jscience_test.rb include Java require 'jscience.jar' Amount = org.jscience.physics.amount.Amount Unit = javax.measure.unit.Unit class Numeric def method_missing(sym) Amount.valueOf(self, Unit.valueOf(sym.to_s)) end end puts 3.kg puts 4.5.kg ~/NetBeansProjects/jruby ➔ jruby -I jscience-4.3/ jscience_test.rb 3 kg (4.5 ± 4.4E-16) kg I'm going to get this pushed out and I'll talk to Tom tomorrow about how to deal with it. I think this is responsible for one other regression report in JRuby too. I have pushed the change along with a substantial expansion of the specs that accompanied it in r7586. I don't think we're going to be able to re-spin 1.1.4 but this is strong motivation to spin a 1.1.5 before month's end.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Blocker
Wrong overloaded Java method called when both int and float signatures exist