The trick I then use is to modify the class file sometime after compilation to mark it concrete by modifying the byte code in the .class file (using Derby's class file utilities). This does not cause any problems with the JVM (though there are some issues with the current version of jikes that Derby uses).
This really really worries me and I am very uncomfortable with it.
So is this direction ok for Derby? Along with Jeremy checking in the Apache jar files required by Derby, it would make downloading and compling Derby much easier.
Looking at the two approaches, here are the trade-offs:
Mulitple JDKs
+ enforces correct sub-setting at development time, enforced by the compiler, e.g. correct methods in JDBC implementations, not using JDK 1.4 classes in a JDK 1.3 environment, not using non J2ME classes in J2ME code.
- tricky (maybe impossible with J2ME) to work with Gump
- tricky for the developer to get started on Derby
- J2ME libraries not (easily) available
Single JDK
- correct implementations only enforced by testing in the given environment, e.g. JDK 1.3 J2ME.
- requires more awareness for contributors working in the code (e.g. not to use JDK 1.4 classes in code that might be used in J2ME).
+ simple for Gump (hopefully)
+ simple for the developer to set up
Comments?
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?
The testing burden for this is no different as production releases would need to be tested on all VMs anyway. It is a higher burden for developers as fixes would need to be done in all code-lines (assuming some divergance).
-- Jeremy
