This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Now, this seems to be all nice and spiffy, until I try submitting the form. That gets me this error when the validator tries to get the attribute add from CourseCommand: java.lang.NoSuchMethodError: uio.ifi.joly.web.command.CourseCommand.getAdd()Lui o/ifi/joly/domain/Course

From what I can tell it looks like Spring has reflected a new getAdd() method on top of my old one, with the return type Object, clobbering the type erasure generated by the compiler, and making the generics go up in smoke. Is this a known issue, and if so is there a way to stop Spring from breaking the generic functionality?

Comment

It is direct consequence of type erasure (see 4.6 in the Java langauge specification, "The erasure of a parameterized type (§4.5) G<T1, ... ,Tn> is |G|."). So, at runtime class Super1<Integer> is represented just as Super1 and any reflection calls can not see that it was parametrized by Integer,

This require some Java 1.5 code (but it could be made backward compatible by some tools). In any case, I'd think that Spring could either come up with a spring-core-jdk15 using these technologies or define some kind of Annotation that would make the BeanWrapper able to find out more about the PropertyType (why not using getPropertyValue().getClass() as the first attempt).

For instance in the enclosed code that shows it is possible to find out the generic type of a property.