On 17 November 2010 07:17, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > On Nov 16, 2010, at 4:19 PM, sebb wrote: > >> On 17 November 2010 00:06, ralph.goers @dslextreme.com >> <ralph.go...@dslextreme.com> wrote: >>> I'm not sure why the tool didn't catch it, but a few methods now return >>> Map<String, Object> where they previously returned Map. I didn't check for >>> generics other than "Map<". >> >> Surely these are equivalent at run-time? >> >> Generics are a compile-time feature. >> > > See > http://www.jroller.com/scolebourne/entry/java_generics_migration_compatibility > and then take a look at the several changes made to add generics to > Comparable. These changes don't seem to be binary compatible. I'm surprised > they didn't show up in the report you ran.
Maybe Clirr does not check fully - after all it was written before Java 5. But I agreed that once generics are introduced, one needs to be careful to ensure that source compatibility is also maintained. Prior to Java 5, I think source compatibility was probably guaranteed if the code was binary compatible. I don't think it is now. [The reverse has never been the case - e.g. changing a void method to return boolean won't affect recompilation, but will affect run-time as the signature changes - so the method can no longer be found.] There probably needs to be a tool to check source compatibility. > I've found several other articles that describe how, under certain > circumstances, type erasure can result in a different type being used than > existed in a prior, non-generified version of the code. I've not fully > inspected all teh changes to determine if any of those cases are present. Perhaps add the links to a Wiki page where we can collect any such info? > I'm not suggesting we change these. Since we are adopting Java 5 I would > prefer to change these now and move forward. To change or not to change? Sorry, cannot understand the last paragraph. > Ralph > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
