Subj : Re: static method signature matching issues in Rhino & JUnit To : netscape.public.mozilla.jseng From : Attila Szegedi Date : Fri Aug 19 2005 11:12 am On Fri, 19 Aug 2005 00:42:31 +0200, wrote: > Thanks for the reply. > > Looking at the LC3 spec, it would appear that in this case the "string" > to java.lang.String conversion ought to be preferred over the > conversion to java.lang.Object. So, I don't think it's a case of LC3 > mandated ambiguity. > > Also, I really do think that this issue is caused by the updates > between 1.5.2 and 1.5.3 related to resolving method ambiguity. Ah, those are Rhino version numbers? I assumed you upgraded JUnit, as Rhino version numbers are in form major.minorRrelease, i.e. 1.5R4... Hm, then it would be a simple matter of diffing the class source code between 1.5R2 and 1.5R3. > checked our JUnit version and it doesn't appear that anything has > changed there that would have introduced this ambiguity. Regardless, > as you mention, it does appear to be a real issue with the Rhino method > selector. Yes, it's tricky to get it right. The basic algorithm is to first find all applicable methods (methods with matching number of arguments, and with declared argument types that the actual types can be converted to), then find the maxima of the lattice formed from these applicable methods when the partial ordering relation "argument list is more specific than" is applied to it. If there's a single maximum, you're lucky. If some arglists are incomparable (i.e. (String, Object) vs. (Object, String)), there can be more than one maximum, and then there's ambiguity. Anyway, I won't molest anyone on the list with more algebra :-). I'll try to set aside an hour this weekend to fix Rhino's algorithm. Attila. -- home: http://www.szegedi.org weblog: http://www.jroller.com/page/aszegedi .