I have (another) unchecked cast question. I am 90% sure that it is safe, but I want to make sure (I'm justifying the use of @SupressWarnings
to another developer who is reviewing the code)
The following pattern has been set up by our framework:
abstract class Writer<T> {
Class<T> valueType;
Writer(Class<T> valueType) {
this.valueType = valueType;
}
}
class Cat { }
class CatWriter extends Writer<Cat> {
CatWriter() {
super(Cat.class);
}
}
I am also using a subclass of Writer
to write a class that makes use of generics:
class Color {}
class Green extends Color {}
class Brown extends Color {}
My writer class looks like this:
abstract class Bird<C extends Color> {}
class Parrot extends Bird<Green>{}
class Ostrich extends Bird<Brown>{}
class BirdWriter<C extends Color> extends Writer<Bird<C>> {
BirdWriter(Bird<C> bird) {
super((Class<Bird<C>>)bird.getClass());
}
}
I could use raw types in the writer but that gives many more warnings. Instead I include the generics in the Writer class. This is fine everywhere but the constructor. I am forced to cast the bird.getClass()
(which is a class object which has no generic signature) to a Class object with a generic signature. This produces an unchecked cast warning on the cast, but I believe it is safe to cast the result to Class<Bird<C>>
because the bird
that is passed into the parameter is guaranteed to be a Bird<C>
.
Testing backs up my theory, but I want to make sure that my thinking is correct. Is there any way in which this code is unsafe?
Thanks for your answers. Because of the answers I realized there was a weakness in my structure and have revised it.
Essentially Cat
uses a simple Writer
that knows it's always writing a Cat
. In my case, I've got a type of "SmartAnimal" that can be written by a dynamic Writer, so that I don't have to create a Writer
for every Animal.
class SmartAnimal {}
class Dog extends SmartAnimal {}
class Horse extends SmartAnimal {}
class SuperHorse extends Horse {}
class DynamicWriter<A extends SmartAnimal> extends Writer<A> {
DynamicWriter(A smartAnimal) {
super((Class<A>)smartAnimal.getClass());
}
}
Again, I have the same warning, but this seems to be more safe.
Is this better, and is it safe?
If we can't eliminate the “unchecked cast” warning and we're sure that the code provoking the warning is typesafe, we can suppress the warning using the SuppressWarnings(“unchecked”) annotation. When we use the @SuppressWarning(“unchecked”) annotation, we should always put it on the smallest scope possible.
Unchecked cast means that you are (implicitly or explicitly) casting from a generic type to a nonqualified type or the other way around.
Unchecked assignment: 'java.util.List' to 'java.util.List<java.lang.String>' It means that you try to assign not type safe object to a type safe variable. If you are make sure that such assignment is type safe, you can disable the warning using @SuppressWarnings annotation, as in the following examples.
You are not entirely correct. The correct, safe, but still unchecked cast is to Class<? extends Bird<C>>
, as the bird you are passed could, for instance, be an Owl, which would return a Class<Owl>
which could be assigned to a Class<? extends Bird<C>>
. Peter Lawrey is correct in the reason that this is unchecked but safe.
Update:
No, it is still not safe for the same reason. You can still do something like new DynamicWriter<Horse>(new SuperHorse());
which would perform an unchecked cast from Class<SuperHorse>
to Class<Horse>
. To be safe, you need to cast to a Class<? extends A>
.
It is most certainly not correct, for the reason listed by ILMTitan in his answer. But I'll give you a reason why it might also not be very safe. Imagine you had a method verifyType()
that made sure that anything that was passed in for writing was the correct type:
public void write(T t) {
if (!verifyType(t)) explode();
//...do write
}
public boolean verifyType(T t) {
return valueType.isInstance(t);
}
This method you would expect never to fail, right? After all, you're just ensuring that t
is a T
(since you have a Class<T>
), and we already know it is a T
because write()
only accepts a T
? Right? Wrong! You're not actually checking if t
is a T
, but potentially some arbitrary subtype of T
.
Examine what would happen if you declared a Writer<Bird<Green>>
and instantiated it with a Parrot<Green>
, it would be legal to do this call:
Writer<Bird<Green>> writer;
writer.write(new SomeOtherGreenBird());
And again you would not expect it to fail. However your value type is for Parrot
only, so the type check would fail. It all depends what you're doing in your writer class, but be forewarned: you are treading in dangerous water here. Declaring a Class<? extends T>
in your writer would prevent you from making a mistake like this.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With