Serializing a matcher with Matcher.writeXML
produces an output like the following:
<FindBugsFilter> <And> <Method name="setDescriptionText" signature="(Ljava/lang/String;)V" role="EARLIER_CALL"/> <Method name="setMarginWidth" signature="(I)V" role="LATER_CALL"/> </And> </FindBugsFilter>
This will not be parsed correctly by SAXBugCollectionHandler.parseMatcher
, which expects a method to have a params
and return
attribute rather than a signature
attribute.
This is certainly a bug.
There is also a related feature request: Please introduce a MethodMatcher(MethodAnnotation)
constructor, at least if you stick with Method
having params
and return
attributes. Turning a MethodAnnotation
's signature into human-readable types like int
and java.lang.String[]
yourself just to call one of the other constructors is pretty cumbersome.
FYI: As I would really like to see this fixed soon (i.e., 3.0.1) I'll prepare a patch.
Just to double-check: Who's the "I" that's doing the patch? You or me? (FWIW, I've just started with writing a unit test for the problem.)
You of course, since you seem have time for it :-)
No problem. I just got confused by the way your first reply was quoted and the fact that you then set
assigned_to
to yourself.Anyway, please have a look at the attached patch. I think the test cases cover everything that's documented on http://findbugs.sourceforge.net/manual/filter.html. The one remaining issue I can think of is the missing license header.
Please advise me on what I should put there.
For the record: Both I and my employer (Codetrails GmbH) are fine with contributing this change to FindBugs under the terms of the LGPL.
Further question:
Serializing a
new MethodMatcher(null, "int", "boolean")
currently (and prior to my patch) yieldsShouldn't this just omit the
name
attribute?I've applied patch, thanks. regarding the last question: I believe we want to keep "any" methods filter, but I might be wrong here.