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: neutral (hermes.apache.org: local policy)
Message-ID: <4228FC74.2020408@apache.org>
Date: Fri, 04 Mar 2005 16:25:24 -0800
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Single JDK14 compile model?
References: <4228E051.5010601@debrunners.com>
In-Reply-To: <4228E051.5010601@debrunners.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:
> 
> 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).
> 

This really really worries me and I am very uncomfortable with it.

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

A lot of the problems here arise because we are trying to support 3 
different JVM revision levels with one output JAR. Is this time to 
consider generating multiple output JARs, one for each VM?

This would also allow us to tune the implementations for each VM 
configuration e.g. eliminating code entirely for features not 
supportable/wanted in J2ME environments (reducing the code footprint), 
replacing SANE/INSANE with assertions in 1.4 and up, native support for 
regex using j.u.regex from 1.4, or leveraging features only available in 
JDK1.5 such as j.u.concurrent?

The testing burden for this is no different as production releases would 
need to be tested on all VMs anyway. It is a higher burden for 
developers as fixes would need to be done in all code-lines (assuming 
some divergance).

--
Jeremy