Hello,
Initially, I committed a LoctionOnlyFilter that wasn't really
implemented. Now after having actually used something that needs a
LocationOnlyFilter, I understand better how this "filter" is going to
work -- it will always match; it's just a bookkeeping artifact.
I've updated the javadoc for this class and "implemented" the "matches"
method.
Keith
ChangeLog
* gnu/classpath/jdwp/event/filters/LocationOnlyFilter.java:
Update javadoc.
(matches): Implement.
Index: LocationOnlyFilter.java
===================================================================
RCS file: /sources/classpath/classpath/gnu/classpath/jdwp/event/filters/LocationOnlyFilter.java,v
retrieving revision 1.1
diff -u -r1.1 LocationOnlyFilter.java
--- LocationOnlyFilter.java 26 Aug 2005 21:52:28 -0000 1.1
+++ LocationOnlyFilter.java 15 Mar 2006 23:18:40 -0000
@@ -1,5 +1,5 @@
/* LocationOnlyFilter.java -- filter on location
- Copyright (C) 2005 Free Software Foundation
+ Copyright (C) 2005, 2006 Free Software Foundation
This file is part of GNU Classpath.
@@ -49,6 +49,13 @@
* May be used with breakpoint, field access, field modification, step,
* and exception event kinds.
*
+ * This "filter" is not really a filter. It is simply a way to communicate
+ * location information for supported events in a generic way to ease
+ * the burden of special casing several things in
+ * EventReqeustCommandSet.executeSet.
+ *
+ * Consequently, this "filter" always matches any event.
+ *
* @author Keith Seitz ([EMAIL PROTECTED])
*/
public class LocationOnlyFilter
@@ -85,7 +92,7 @@
*/
public boolean matches (Event event)
{
- // FIXME
- throw new RuntimeException ("LocationOnlyFilter.matches not implemented");
+ // This filter always matches. See comments in class javadoc.
+ return true;
}
}
