Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Fri, 04 Mar 2005 14:35:06 -0800
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: Single JDK14 compile model?
In-reply-to: <4228E051.5010601@debrunners.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <4228E29A.5030308@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
 Gecko/20040113
References: <4228E051.5010601@debrunners.com>

I must confess to not understanding all the issues, but I think in 
summary what you're saying is that you are "tricking" the older VMs to 
work by modifying byte code compiled under JDK 1.4.  Although I see the 
ease-of-development value in this, it is a little disconcerting that 
we'd be taking VM compatibility into our own hands.  Also, what are the 
consequences of this approach when we want to support JDK 1.5? 

At the same time, I think what you're saying is that if we include 
support for J2ME then things as they are become untenable.  Are there 
any other alternatives? 

David

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