So I was experiencing a weird bug in Spring where an abstract controller method was being called and being passed an object that the type system should not have allowed.
This is a simple example that demonstrates the bug.
import org.junit.Test;
import java.lang.reflect.InvocationTargetException;
public class RandomJavaTesting
{
public static class Animal {
}
public static class Cat extends Animal {
}
public static class AnimalManager<T extends Animal> {
// This gets called and doesn't blow up
public void add(T animal){
// This will throw a class cast exception
// Why does this blow up here for CatManager?
this.callAdd(animal);
}
public void callAdd(T animal){
}
}
public static class CatManager extends AnimalManager<Cat> {
@Override
public void callAdd(Cat animal)
{
// This will never run
}
}
@Test
public void callingGenericMethodWithSubClassType() throws InvocationTargetException, IllegalAccessException
{
CatManager manager = new CatManager();
Animal animal = new Animal();
AnimalManager.class.getDeclaredMethod("add", Animal.class).invoke(manager, animal);
}
}
This test gives the following exception:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at RandomJavaTesting.callingGenericMethodWithSubClassType(RandomJavaTesting.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.ClassCastException: RandomJavaTesting$Animal cannot be cast to RandomJavaTesting$Cat
at RandomJavaTesting$CatManager.callAdd(RandomJavaTesting.java:28)
at RandomJavaTesting$AnimalManager.add(RandomJavaTesting.java:20)
... 32 more
Basically, my question is, why does calling the add
method not cause a ClassCastException. Why does calling callAdd
cause the exception? I understand that generic information isn't preserved at runtime however I was under the assumption that extending a class caused the type parameters of a generic class to be preserved. This is the mechanisim behind the Guava TypeToken. Or, at least that's what I thought.
Aucun commentaire:
Enregistrer un commentaire