db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shreyas Kaushik <Shreyas.Kaus...@Sun.COM>
Subject Re: Single JDK14 compile model?
Date Mon, 07 Mar 2005 03:52:47 GMT
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
>- 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

View raw message