db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 16:31:51 GMT
Jeremy Boynes wrote:

> Daniel John Debrunner wrote:
> 
>>
>> So I looked at an alternate approach where all the code is compiled
>> using a single JDK, requiring at least JDK 1.4 though I'm only tested
>> with 1.4 so far. This requires making some classes abstract that must
>> not be abstract in J2ME or JDK 1.3. EmbedResultSet is an example. This
>> allows the class to then compile under JDK 1.4.
>>
> 
> I did some playing around came up with a small IdeaJ project that
> implements a couple of the API classes (CallableStatement and
> ResultSet). This compiles under 1.4 (with target=1.3) and runs under 1.4
> (with 3.0 features) and 1.3 (without).
> 
> Code can be downloaded from http://www.apache.org/~jboynes/vmtest.jar
> 
> Is this a solution to the VM compatibility issue or is there a case I am
> missing?

This is somewhat similar to what Derby does today, with one exception.
Your CallableStatement implementation references a class,
ParameterMetaData, that will not exist in jdk 1.3 environments.

The issue then becomes, is it *guaranteed* that any 1.3 JVM will not
throw a class not found exception when it loads this implementation?

With Cloudscape we saw in the past problems with this approach, with
JVMs that did aggressive pre-loading of classes (as they are allowed to)
and when byte code verification is enabled.

That's why the approach was taken to ensure that in any enviromnent that
only classes that could be loaded through code were ones that were
guaranteed to be there.

Dan.


Mime
View raw message