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: <42291504.4080903@apache.org>
Date: Fri, 04 Mar 2005 18:10:12 -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> <4228FC74.2020408@apache.org>
 <422907F0.40103@sun.com> <42290A89.7090504@debrunners.com>
In-Reply-To: <42290A89.7090504@debrunners.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel John Debrunner wrote:
> David Van Couvering wrote:
> 
> 
>>If the current situation (as I am beginning to understand) prevents us
>>from taking advantage of numerous JDK 1.4 and 1.5 features, then I think
>>this going to become more and more of a burden.  As well as what Jeremy
>>mentioned, there is exception chaining, and NIO support, and others I'm
>>sure...
> 
> 
> The current Derby architecture explictly allows modules to take
> advantage of features in various JDKs. SO there is no issue there. Derby
> can dynamically load different modules for different VM environments.

Sure but as we take more and more advantage of features in newer VMs 
then the number of different modules is going to grow and grow.

> 
> 
>>If the current situation also constrains our ability to add features
>>because we're worried about overall size of the JAR for J2ME, this is a
>>problem too.
> 
> 
> Maybe an issue. The bulk of the code is currently in the SQL engine and
> compiler, which is required on J2ME. At the moment, splitting the code
> up to have a jar that just supports J2ME is not worth the effort. It may
> become an issue if analytics or other features are added, but I'll worry
> about that when it happens.
> 
> While I would like to see the current derby.jar get smaller, say 1Mb,
> I'm also half not convinced it's worth the effort. Having just got my
> wife an IPod mini with 4Gb storage, I was thinking given the really
> small physical size of such a device, what's the difference between 1Mb
> and 2Mb.
> 

Drop it and see what still works (just don't tell the wife) - there is a 
big difference between rotating bits of plastic and flash. How much RAM 
does that iPod have? No more than 32MB I would guess, most of which will 
be buffer to let them spin down the drive to reduce shock risk and power 
drain.

To me the big issue is setting expectations with users - are they always 
going to be getting one jar or are they going to be able to choose 
between profiles based on JVM version, platform level, or SQL feature set.

I believe that some features are going to be big and complex (e.g. 
object type support, charsets/collations, geo/spatial, full-text 
indexing, analytics, ...) and very few users will want/need all of 
these. Ultimately we are going to want a mechanism that allows users to 
easily build the module configuration they want.

--
Jeremy