db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: conflict between Derby API and JDBC 4.0
Date Wed, 25 Jan 2006 07:28:35 GMT

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  

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.

View raw message