#1242 False positive BC_UNCONFIRMED_CAST_OF_RETURN_VALUE with superclass generics

[David Shepherdson]

Steps to reproduce:

1. Expand the attached .tgz file.
2. Edit build.xml and point `findbugs-home` at a FindBugs installation.
3. `ant findbugs`.
4. Produces `findbugs.xml` with one bug reported.

The 'bug' is supposedly an unconfirmed cast on line 6 of Child.java. FindBugs claims that the returned value of the superclass method is Interim, and therefore cannot be assigned to a variable of type Something without a cast.

However, the generics in the definition of the method in the superclass state that the return type is T, and in Child this type parameter has been specified as Something -- therefore the value returned by the superclass method must be a Something.

By comparison, doing exactly the same thing with FindBugs 1.3.9 does not produce any bug warnings.

Interestingly, changing the definition of the T type parameter in Parent.java to be more general, as per the commented-out line at the beginning of the file, causes the bug warning to go away.

Java Versions: reproduced with both 1.7.0_45 and 1.6.0_65
OS: Mac OS X 10.8.5

[David Shepherdson]

Attached to this comment is a slightly revised version of the example, which removes some extraneous code from a couple of the classes and simplifies things a bit. (Sorry -- first time using SourceForge's bug tracker, and I can't see how to edit the original ticket. :-))

[William Pugh]

Thanks, I was able to reproduce the problem, although FindBugs only assigns a low confidence to the warning. Is that what you are seeing?

Generally, if you have configured FindBugs to report low confidence warnings, you need to be prepared to deal with false positives.

If it is only low confidence, then I'll look at it to see if it is an easy problem to fix. But we don't make significant changes to reduce low confidence false positives.

[David Shepherdson]

Yes, that's what we're seeing too.

I realise it's low confidence, and not exactly a super-common scenario, but I thought it worth reporting anyway in case it turns out to be an easy fix, given that it was a change of behaviour from 1.3.9.

Thanks William,

David

[Andrey Loskutov]

From the bytecode point of view we see only erased type info on the frames (here: Enum, and not Enum & Displayable). I've tried to play with the local variable table, but this is also hardly possible to get desired type info there.