Re: finding method efficiently
Robert == Robert Schuster [EMAIL PROTECTED] writes: Robert Now when evaluating the XML data I have to search the method put Robert which accepts the two arguments. Having Robert only String and JFrame as argument types means that the call to Robert HashMap.class.getMethod(put, new Class[] { String.class, Robert JFrame.class }); Robert will fail. My current naive approach to find HashMap.put(Object, Robert Object) is to generate a long list of a superclasses and Robert interfaces of all arguments and then calling getMethod(put, ..) with Robert every combination. You could use Class.getMethods to get an array of all methods in a class, then search for the method that allows this call, by using isAssignableFrom on the arguments. That's about all I can think of. This is more efficient than using getMethod since you don't need to generate all combinations of the method argument types. getMethods will look at the inheritance tree for you, so you only need to call it once. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: finding method efficiently
Tom Tromey writes Robert == Robert Schuster [EMAIL PROTECTED] writes: Robert Now when evaluating the XML data I have to search the method put Robert which accepts the two arguments. Having Robert only String and JFrame as argument types means that the call to Robert HashMap.class.getMethod(put, new Class[] { String.class, Robert JFrame.class }); Robert will fail. My current naive approach to find HashMap.put(Object, Robert Object) is to generate a long list of a superclasses and Robert interfaces of all arguments and then calling getMethod(put, ..) Robert with every combination. You could use Class.getMethods to get an array of all methods in a class, then search for the method that allows this call, by using isAssignableFrom on the arguments. That's about all I can think of. This is more efficient than using getMethod since you don't need to generate all combinations of the method argument types. getMethods will look at the inheritance tree for you, so you only need to call it once. But first you have to filter out the public methods, as getMethods will return them all. Hmmm. There is a further problem that you have to work out how to do this such that overload resolution is applied correctly. Basically I can't see any way to do this other than to reapply the same method resolution logic that javac would use! Find all applicable methods, then find the most specific. For the XML not to carry the parameter type information seems fundamentally broken. :( David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: finding method efficiently
David == David Holmes [EMAIL PROTECTED] writes: David Hmmm. There is a further problem that you have to work out how David to do this such that overload resolution is applied David correctly. Basically I can't see any way to do this other than David to reapply the same method resolution logic that javac would David use! Find all applicable methods, then find the most specific. Yeah, I agree, based on what I read it does seem that way. This algorithm is going through an overhaul as a result of all the new language features, I wonder if that will propagate to XMLDecoder. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: finding method efficiently
Tom Tromey writes: Yeah, I agree, based on what I read it does seem that way. This algorithm is going through an overhaul as a result of all the new language features, I wonder if that will propagate to XMLDecoder. At least the algorithm has been overhauled such that the new features do not impact if they are not used. The algorithm has been broken into phases such that phase 1 performs the old algorithm, then subsequent phases repeat the old algorithm after applying boxing/unboxing, varargs and generics etc. Regardless this is not something I would want to hand code using the reflection API as Robert must do. David ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: finding method efficiently
David Holmes wrote: Regardless this is not something I would want to hand code using the reflection API as Robert must do. I have come across this same challenge several times now, i.e., having to write code that implements the Java best match semantics for method invocation using reflection. Usually I end up doing something that works in all the 'easy' cases and punt on the rest. For an almost-example, look at Classpath's java.lang.Class.internalGetMethod(). So it would be nice if we could write this algorithm once and for all and make it public somewhere :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath