This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] java.beans.EventHandler


Bryce McKinlay writes:
 > Hi Jerry,
 > 
 > Jerry Quinn wrote:
 > 
 > >+    System.out.println("ptype="+propertyType.getName());
 > >+    System.out.println(" val="+((val==null)?"null":val.toString()));
 > >  
 > >
 > Presumably these are left-overs from debugging and should be removed?

Yes, oops.

 > 
 > >+    // Find the actual method of target to invoke.  We can't do this in the
 > >+    // constructor since we don't know the type of the property we extracted
 > >+    // from the event then.
 > >+    //
 > >+    // action can be either a property or a method.  Sun's docs seem to imply
 > >+    // that action should be treated as a property first, and then a method,
 > >+    // but don't specifically say it.
 > >+    //
 > >+    // XXX check what happens with native type wrappers.  The better thing to
 > >+    // do is look at the return type of the method
 > >+    Method actionMethod;
 > >+    try
 > >+      {
 > >+       // Look for a property setter for action.
 > >+       actionMethod =
 > >+         target.getClass().getMethod("set" + capitalize(action),
 > >+                                     new Class[] {propertyType});
 > >+      }
 > >  
 > >
 > 
 > It would be much faster to look up the actionMethod once when the 
 > EventHandler is constructed, and cache it, rather than looking it up 
 > again during every dispatch. Looking up methods can be quite slow, plus 
 > you'll avoid several allocations.

I started to do that.  The problem is that you don't know propertyType when
the EventHandler is constructed, because you don't know the object that the
event will be pulled from.  Also, the property is hierarchical, which means
walking down a chain of objects to find this property and this chain could be
assembled at run time.

Unless I'm missing something, which is possible.  For now, I'll commit this as
is, but if you see how to solve this, I'll be happy to patch it.

 > Otherwise, this looks good.

Thanks.  Committed (minus the debugging :-) (on the second try :-()

Jerry


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]