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). > >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. > > > > Is there any bytecode incompatibility when you compile under jdk141 and run under jdk131? I heard once that there was but it was merely anecdote and I don't know if that is really true or not, but thought it would be worth confirming that it is ok to compile under jdk141 and run under jdk131.
Thanks Kathey
