db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 01:05:41 GMT
RPost wrote:
>>"Jeremy Boynes" wrote:
>>A lot of the problems here arise because we are trying to support 3
>>different JVM revision levels with one output JAR. Is this time to
>>consider generating multiple output JARs, one for each VM?
>>This would also allow us to tune the implementations for each VM
>>configuration e.g. eliminating code entirely for features not
>>supportable/wanted in J2ME environments (reducing the code footprint),
>>replacing SANE/INSANE with assertions in 1.4 and up, native support for
>>regex using j.u.regex from 1.4, or leveraging features only available in
>>JDK1.5 such as j.u.concurrent?
> Do you know how the current codebase break out in terms of JVM version?
> Which code is currently needed support 1.3 environments?

I was under the impression that the entire codebase currently ran under 
1.3 (with the exception of the stuff specifically compiled for 1.4 which 
can be extracted from the build).

Given Sun have their version of JDK1.3 in EOL and are dropping support 
as of 3/30/2006 I would expect most users to be in the process of 
migrating away from it; those that aren't are not likely to be 
considering database upgrades either.

I see support for J2ME being more important than 1.3, and in those 
environments eliminating redundant code is useful. As we go further and 
add features to Derby then the size of the codebase is only going to 
increase. Some of those features may not be necessary in a J2ME 
environment (analytics as an extreme example) so some profiling will be 
to their benefit. I don't see this as any different to an embedded 
distribution without DRDA support.

> How would you handle interfaces or base classes that are common to more than
> one JVM version if the descendent class is specific to, say, 1.3? Would you
> duplicate the base classes in each jar?

To a large extent yes. The build for each JVM would result in a single 
JAR targeted at that JVM so users would just include the correct JAR for 
their VM.

Ideally there would also be one version of the interface/base-class in 
the source tree shared by all versions, with the VM-specific descendent 
just included in the appropriate build.


View raw message