finding method efficiently
Hi Classpath hackers, I am currently implementing java.beans.XMLDecoder which now starts to work. But I have a small (efficiency) problem. As you might know the decoder accepts XML data like this: 12 43 and executes this using reflection as if I had written: new Point(12, 43). Now something more complicated: someId This is equivalent to: m = new HashMap(); m.put("someId", new JFrame()); (variable m is not needed in XML version) Now when evaluating the XML data I have to search the method "put" which accepts the two arguments. Having only String and JFrame as argument types means that the call to HashMap.class.getMethod("put", new Class[] { String.class, JFrame.class }); will fail. My current naive approach to find HashMap.put(Object, Object) is to generate a long list of a superclasses and interfaces of all arguments and then calling getMethod("put", ..) with every combination. It should be clear that performance is not on my side when doing this. My question is: Is there anything I can do to make this more efficient? cu Robert ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
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