Re: Re: BC: Unchecked/unconfirmed cast (BC_UNCONFIRMED_CAST)

yes, this code should use a null check.

No, handling this won't make it into 1.1.2. We're trying to
get 1.1.2 out the door this week.

One of the questions we'll have to decide is whether we want to do a  
simply hack
to suppress this warning for this precise idiom, or figure a way to  
do the right that
and make the type analysis understand this.

Actually, the code you've provided is a little subtle. Doing the  
right thing
in the type analysis might be a little subtle. The more typical  
instance of this
idiom if

  if (o.getClass() == Foo.class) {
        Foo foo = (Foo) o;
        ...
        }
which isn't as subtle.

So we'll need to think about it a while. Maybe 1.1.3.


Bill

On Dec 4, 2006, at 10:35 PM, John Penix wrote:

> shouldn't you use instanceOf which includes a null check?
>
> John
>
> On 12/4/06, Nils Kilden-Pedersen <nilskp@xxxxxxxxx > wrote:
> On 11/29/06, Nils Kilden-Pedersen <nilskp@xxxxxxxxx> wrote:
> In a MyClass.equals(Object) implementation, I have this code:
>
> public boolean equals(Object object) {
>     if (this.getClass() == object.getClass() {
>         MyClass that = (MyClass) object;
>         ...
>     }
>     ...
> }
>
> This incorrectly causes a "BC: Unchecked/unconfirmed cast" warning.
>
> Any comment on this? Will a fix for this make it into 1.1.2?
>
>
>
> _______________________________________________
> Findbugs-discuss mailing list
> Findbugs-discuss@xxxxxxxxxxxxxxxxxx
> http://mailman.cs.umd.edu/mailman/listinfo/findbugs-discuss
>
>
>
>
>
> --
> John Penix
> Member of Technical Staff
> Google, Inc.
> _______________________________________________
> Findbugs-discuss mailing list
> Findbugs-discuss@xxxxxxxxxxxxxxxxxx
> http://mailman.cs.umd.edu/mailman/listinfo/findbugs-discuss