db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: conflict between Derby API and JDBC 4.0
Date Wed, 25 Jan 2006 15:33:37 GMT
I really really don't want to see us modifying the class to indicate a 
different class version.  This path seems fraught with peril; this type 
of "white lie" (actually it's a pretty big lie) seems to me fraught with 
peril; who knows what other functionality depends on correct versioning 
of the class file?

David

Andrew McIntyre wrote:
> 
> 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

Mime
View raw message