Re: conflict between Derby API and JDBC 4.0

[Andrew McIntyre]

On Jan 24, 2006, at 5:13 PM, Daniel John Debrunner wrote: Are generics represented by new entries in the class file that break on older VMs? This question caught my eye, and I did a little research. The answer is both yes and no. The bytecode for generics is compatible with older VMs because the generic type signature is erased at compile time and appropriate casts added by the compiler. The new methods could be used in the older VM, but casts which were not expected when the newer class was compiled would result in a ClassCastException.  But, attempting to load a class with generics compiled with 1.5/1.6 in a 1.4 JVM yields this error: Exception in thread "main" java.lang.UnsupportedClassVersionError: Generic (Unsupported major.minor version 49.0) It is also not possible to compile a class with generics with -target 1.4. But, you could change the class version so that the class got past the verifier on the earlier VM and it would still work. I even verified that this would work with a simple test case. I haven't had time to look at whether the new methods with generics have counterparts in JDBC 3.0, but assuming they don't, and the JSR-014 charter says that JDBC 4.0 should be backwards compatible with JDBC 3.0, altering the class version would do the trick. But, then you've entered the dreaded area of modifying class files post-compilation. :-) Also, I found this document: http://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla.pdf very enlightening as to the mechanics of how generic types are handled in the compiler. It was linked from the JSR-014 page. andrew