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
