"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.
-- Jeremy
