db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Single JDK14 compile model?
Date Fri, 04 Mar 2005 22:58:21 GMT
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

Mime
View raw message