Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.92.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=QSIRNrJ9iFDvgNtPoX4CMy1MmdCknqvJd3gL9/M3h8O1n8cETo6yAMlh5GnV8NjR9s
         N5WXBbrqrIVI4EYmMOFfg6sOqSfVMQ/Ynj37VquybqgdnMQtRnSlSmepVvuK0OwE6yb0
         ihsqQi0Q3X2eTgMdenxOU9apdSa5gqddyOR5Q=
Message-ID: <48D27468.8010404@gmail.com>
Date: Thu, 18 Sep 2008 16:31:52 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [general] Reduced footprint class library
References: <48D25328.6050701@gmail.com>
 <200809181552.05205.chris.gray@kiffer.be>
In-Reply-To: <200809181552.05205.chris.gray@kiffer.be>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Chris Gray wrote:
> On Thursday 18 September 2008 15:10, Tim Ellison wrote:
>> In another thread [1], Chris wrote:
>>> Should we start a separate thread with a more obvious title?
>> Done, tweak the subject as you see fit.
> 
> Ta.
> 
>>> [...]
>>> In fact JavaME CDC/FP doesn't include java.nio, [...]
>> True, as you are adhering to the ME specs.  But if you are prepared to
>> branch out and define an alternative reduced footprint library profile
>> you might also choose to include NIO functionality, and 1.5 syntax
>> support, etc.
>>
>> You may have some insights based on the "Mika class libraries with
>> packages taken from Harmony" use cases you have already seen.
> 
> Java.nio is something of an Awful Example in this context, because it contains 
> such disparate elements. One application might really need the charset stuff 
> but have no use whatever for the java.net-revisited parts, another might be 
> i/o intensive and need direct buffering and select()-style functionality 
> above all. IOW the granularity of the footprint reduction process will 
> probably not map neatly onto package boundaries.

Right.  In fact, as you know Harmony has NIO (for IO channels) and
NIO_CHAR (for character converters).  We went through an exercise way
back to split the monolith into different functional areas, and defined
the metadata to describe the inter-dependencies.  While we try to
minimize the coupling some of it is forced upon us by the SE APIs.

> In actual use cases the most popular single import seems to be java.beans 
> (which does actually correspond to a Sun-defined profile, namely CDC/PP). The 
> biggest import was in order to run Ant on the target for purposes of 
> auto-deployment - not a route I would recommend, but that was the customer's 
> choice.

A good example.  Harmony's BEANS module depends upon AWT through a
spurious public interface parameter (and the fact that BEANS carries
around the persistence delegates).  For people that don't want AWT and
SWING in their runtime they need to break the SE API in Beans.

In general you can't mix and match, but have to surgically carve through
the class libraries.

> See also my response to Alex Blewitt regarding char converters and locales.

ACK.

Regards,
Tim

>> [1] http://markmail.org/message/x3ydeos244pqpcws
> 
> Regrads,
> 
> Chris
>