Subj : Re: static method signature matching issues in Rhino & JUnit To : netscape.public.mozilla.jseng From : Attila Szegedi Date : Thu Aug 18 2005 11:42 pm On Tue, 16 Aug 2005 02:06:46 +0200, wrote: > To clarify, what I mean by "I'm not sure what's going on," is that that > appears to be a fairly un-ambiguous choice. So, I'm not sure what's > changed, or what's causing the ambiguity. Probably the JUnit class earlier didn't have one of the two overloaded methods. You got me intrigued by this as I've myself written code for FreeMarker that dinamically chooses from overloaded methods based on argument types (every dynamic language built atop of Java that can invoke Java methods inevitably needs to contain such an algorithm, except if it chooses not to handle overloaded methods...). Just for the record, I could recreate your problem in Rhino. Also for the record, I constructed a similar example in FreeMarker, and it unambiguously chose the "assertEquals(String, String, String)" method. (I guess this is the choice you expected). I believe that the method selector in Rhino has the problem with middle argument being a JS "string" -- it can be treated either as a String or as a ScriptableObject. When I changed the middle parameter to be java.lang.String, i.e. Assert.assertEquals("Unexpected status code", new java.lang.String(expectedStatusCode), statusCode); it went through, *however* it chose the assertEquals(String, Object, Object) method. I'll try to devote some time (I'm pretty busy with my paid work at the moment...) to analyzing the Rhino method selector algorithm and see if I can apply my experience from implementing similar stuff in FreeMarker here. There's a tiny problem that we need to observe the conversion rules of LiveConnect when inspecting whether two types are convertible into one another, and that brings some further concerns into the play -- it might turn out that under LiveConnect this is unfortunately indeed unresolveable ambiguity. I'll keep you updated. Anyone with experience in Rhino LiveConnect compliance and/or that particular piece of code (NativeJavaMethod.findFunction()) is welcome to chime in the discussion. Attila. -- home: http://www.szegedi.org weblog: http://www.jroller.com/page/aszegedi .