checking casts

[Dan Upton]

When trying to compile something I was working on today, I got this
error based on a performing a cast:

PuzzleSolver.java:311: warning: [unchecked] unchecked cast
found : java.lang.Object
required: java.util.Vector<Piece>
piecesClone = (Vector<Piece>)pieces.clone();

I know it's a safe cast, but just for the sake of getting javac to leave
me alone I tried sticking it in a try...catch block:

Vector<Piece> piecesClone=null;
try{
piecesClone = (Vector<Piece>)pieces.clone();
}catch(ClassCastException cce){
System.out.println("This is just so javac will shut up");
}

I still get the warning from the compiler though, so I'm assuming this
*isn't* the correct way to check a cast. Any tips on what *is* then?

 

[Thomas Hawtin]

When trying to compile something I was working on today, I got this
error based on a performing a cast:

PuzzleSolver.java:311: warning: [unchecked] unchecked cast
found : java.lang.Object
required: java.util.Vector<Piece>
piecesClone = (Vector<Piece>)pieces.clone();

I know it's a safe cast, but just for the sake of getting javac to leave
me alone I tried sticking it in a try...catch block:

The compiler is complaining that that you are casting to Vector<Piece>,
but the runtime will not be able to check that the object isn't
actually, say Vector<String>.

The easy way around it is to write:

piecesClone = new ArrayList<Piece>(pieces);

Tom Hawtin

 

[Oliver Wong]

When trying to compile something I was working on today, I got this error
based on a performing a cast:

PuzzleSolver.java:311: warning: [unchecked] unchecked cast
found : java.lang.Object
required: java.util.Vector<Piece>
piecesClone = (Vector<Piece>)pieces.clone();

I know it's a safe cast, but just for the sake of getting javac to leave
me alone I tried sticking it in a try...catch block:

The compiler is complaining that that you are casting to Vector<Piece>,
but the runtime will not be able to check that the object isn't actually,
say Vector<String>.

The easy way around it is to write:

piecesClone = new ArrayList<Piece>(pieces);

Alternatively, you could add:

@SuppressWarnings("unchecked")

to suppress the warning within a block of code (might be a good idea to
add a comment explaining why you believe it's safe to ignore this warning).
Sun's "JavaC" compiler is supposed to support the SuppressWarnings
annotation in its next release, and Eclipse's compiler already does support
it.

- Oliver

 

[Thomas Hawtin]

Alternatively, you could add:

@SuppressWarnings("unchecked")

Perhaps it was a good idea that javac doesn't initially support
SuppressWarnings. Hopefully it should have encouraged programmers to
adopt idioms that don't cause warnings, rather than treating the symptoms.

Tom Hawtin

 

[Chris Smith]

Perhaps it was a good idea that javac doesn't initially support
SuppressWarnings. Hopefully it should have encouraged programmers to
adopt idioms that don't cause warnings, rather than treating the symptoms.

The problem with this is that there are things that can't be done in
Java 1.5 without warnings. Your code above sorta lucked out. If the
method had returned List instead of Vector and the new List needed to
have similar performance characteristics to the old one, then it would
definitely not have been good enough.

This is certainly not a clear-cut case of right or wrong. Certainly
it's best to avoid SuppressWarnings when possible, but it's equally good
to be aware of its presence.

It's unfortunate, though, that SuppressWarnings apparently can't be
applied to a block or statement; only to an API element, parameter,
local variable.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation