db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 01:25:07 GMT
On Fri, 04 Mar 2005 14:25:21 -0800, Daniel John Debrunner
<djd@debrunners.com> wrote:
> 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.

Just to be clear, the near-duplicate actions were needed to work
around a bug in Jikes 1.22. But yes, because of the way Gump controls
the compilation classpath, it became necessary to split the engine
build across JDBC 2/JDBC 3 lines. I might be able to simplify it
somewhat from the current situation, but I haven't spent much time on
it since I got it working.

> 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). 

Adjusting how we build in Gump for changing requirements is an
inconvenience, one that I'm not sure really calls for going to such
lengths to mitigate. I'd rather put the time in myself to keeping our
build running in Gump than deal with problems caused by modifying the
classfiles at build time (I'm thinking of all the fun I've had with
obfuscation). :-)

A more serious problem would seem to be:

> - J2ME libraries not (easily) available

Is there any readily available reference implementation for J2ME
(w/JSR169)? How would Gump, or anyone, build Derby if we require J2ME
reference libraries to build, but there's no available reference
implementation? If the answer is: there is none, then I suppose we'll
need to consider this anyway.

Also, Kathey Marsden wrote:
> Suddenly users have to think of which set of jar files to
> download, we need to document when and why to use which and they may
> need to download a different jar when they upgrade their jvm. 

If the choice is between J2ME and J2SE, then that's pretty easy, but I
don't think we should have separate jars for different JDK revisions.
That would get confusing indeed, not to mention be a real hassle for
maintenance (and versioning, and, and...)

Even creating a split between J2ME and J2SE shouldn't require
splitting the codeline. The module system allows for creating
different jar files with different sets of modules, although I think
the code for this would need to be revived in the build.


View raw message