@SuppressFBWarnings on lambdas?

[jiangty-addepar]

I'm trying to migrate from Findbugs 3.0 to Spotbugs 3.1.6. There are quite a few new NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE warnings that are generated now. I can fix some of them easily, but others have less well-defined behavior, so I'd like to suppress the FB warnings for now.

A lot of these warnings are coming from statements inside lambdas, but there doesn't seem to be a way to apply @SuppressFBWarnings to a lambda. Moreover, @SuppressFBWarnings on the method containing the lambda also doesn't actually suppress the warning, either; I feel like it used to work in Findbugs, though...

Is there a way to suppress the warning without suppressing warnings for the entire class?

[ylexus]

That's a serious blocker for us as we fail the build on findbugs violations. is there a workaround for suppressing spotbugs failures on lambdas? Using 3.1.9.

[realPyR3X]

I can confirm this. We also fail build on spotbugs violations. Really need a fix for this.

[kennknowles]

Confirmed. This showed up in apache/beam#7704 migrating from findbugs to spotbugs. You can suppress at the containing class but that is obviously not great.

[hd42]

This bug leads to some unnecessary code in our projects, using extra functions or anonymous classes just to have a place for the @SuppressFBWarnings annotation where it's scope isn't wider than necessary

[andychen23]

Facing the same issue, @SuppressFBWarnings annotation does not work for java lambda function, which force me refactoring the code and writing lots of unnecessary code.

[facewindu]

Any plan to fix this ?

[eitan12345om]

I am also facing the same issue

[tomqwpl]

Ditto. Major annoyance to have to refactor code so that I can apply the annotation

[jcopenhop]

this is still an issue in spotbugs 4.7.2

[albertoolivan]

same in 4.7.3 !

[harbulot]

Workaround

A workaround for this problem is to exclude these specific bugs using the baseline XML configuration (not to be confused with exclusion filters): -excludeBugs <baseline bugs> option on the command line or excludeBugsFile option with the Maven plugin.
(This could also be handled by the m2e plugin: m2e-code-quality/m2e-code-quality#316.)

The exclude bugs file can have a number of <BugInstance /> entries like so:

<?xml version="1.0" encoding="utf-8"?>
<BugCollection>
    <!--
        We can't put the SuppressFBWarning annotation on a lambda.
    -->
    <BugInstance type="..." priority="2" rank="20">
        <Class classname="...">
            <SourceLine classname="..." sourcefile="..." sourcepath="..."/>
        </Class>
        <Method classname="..." name="lambda$0" signature="..." isStatic="true">
            <SourceLine classname="..." start="174" end="180" startBytecode="0" endBytecode="190" sourcefile="..." sourcepath="..."/>
        </Method>
        <Method classname="..." name="..." signature="..." isStatic="true" role="METHOD_CALLED">
            <SourceLine classname="..." start="4141" end="4141" startBytecode="0" endBytecode="67" sourcefile="..." sourcepath="..."/>
        </Method>
        <String value="..." role="..."/>
        <SourceLine classname="..." start="178" end="178" startBytecode="43" endBytecode="43" sourcefile="..." sourcepath="..."/>
    </BugInstance>
</BugCollection>

The exact contents of each <BugInstance> can come from the XML result of running SpotBugs, and it's also directly visible in the "Bug Info" panel in Eclipse, for example (although be aware of #2389 if it's in a contructor).

Downsides

• It depends on the exact line numbers: if you refactor the code around a little and the lines move, the explicit exclusion will be ignored, so the warning will show up again.
• There doesn't seem to be a way to see which of these exclusion rules are actually not used, so if some code is removed or even just moved, the XML exclusion file could contain a number of rules that are no longer relevant. It's not immediately as visible as exclusion via annotations.

Alternatives

I'm not sure if the idea has already been discussed, but perhaps it would be good to be able to suppress SpotBugs warnings via directives in comments, more specifically targeted around the code in question.

I realise SpotBugs seems to rely mainly on bytecode analysis, but it looks like there already is some capability to analyse some comments too when the source code is available (findbugs.sf.comment property for SwitchFallthrough detector).

It would be useful for more modern ways of writing Java (lambdas). I also think it's generally better to keep the warning suppression as closely targeted on the area where the issue is (instead of having to put a @SuppressFBWarning annotation on the full class or the full method), so that would help too.

[Manu10744]

How come this hasnt been fixed in 4 years???

[iloveeclipse]

How come this hasnt been fixed in 4 years???

If you think it's trivial issue, please consider to propose a PR with the fix.

[zhenyanghua]

This annotation could still be applied to the concrete method if the lambda is converted to the anonymous class.