Re: Single JDK14 compile model?

[Shreyas Kaushik]

My answers are inline.
~ Shreyas
Daniel John Debrunner wrote:
The current compile model for Derby uses a JDK 1.3 and JDK 1.4. Those
classes that are required to run in JDK1.3/JDBC 2.0 are compiled against
the JDK 1.3 libraries, and the JDK 1.4/1.5/JDBC 3.0 are compiled against
the JDK 1.4 libraries. This requires developers to download and setup
two JDKs and some extra libraries from JDK 1.3 extensions.
While this model worked well for closed source (all the setup was
handled automatically), it's no so good for open source. This is because
of putting the burden on developers to download extra stuff.
I was trying to expand this model to support J2ME/CDC/Foundation but I
am now having doubts, mainly due to the requirement at Apache to be part
of Gump. Andrew had to modify various build.xml files (adding near
duplicate actions) and make the gump build a multi-pass affair. I don't
see how I can add J2ME support in this mode while also keeping Gump running.
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.
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).
 

I am not comfortable with doing this. What will be the impact on 
portability of code.
If there are some things in the class files that may differ from 1.3.* 
to 1.4.*, how  would
this be handled ?
We also need to see the impact with 1.5.* .

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?
Dan.