harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <alex.blew...@gmail.com>
Subject Re: [general] Reduced footprint class library
Date Thu, 18 Sep 2008 13:27:38 GMT
Converters are needed as an on demand basis - is there any reason the  
dynamic loading of a charset could be augmented with the ability to  
download additional converters if not found locally?

This might not make sense for non-connected devices but for desktops  
could allow a minimal set to be distributed and then others to be  
acquired on demand.


Sent from my (new) iPhone

On 18 Sep 2008, at 14:10, Tim Ellison <t.p.ellison@gmail.com> wrote:

> In another thread [1], Chris wrote:
>> Hi Tim,
>>>> Sounds good to me.  Let's see if anyone else is interested.
>> Should we start a separate thread with a more obvious title?
> Done, tweak the subject as you see fit.
>>>> You spurred me into committing the patch I was sat on to reduce the
>>>> footprint of the NIO character converters, by making the native
>>>> implementations optional.  You can now delete the 1.5Mb hyniochar
>>>> library and we'll fall back to doing the conversions in Java code.
>>>> I'm sure there are more examples like this where we can have the  
>>>> best of
>>>> both worlds for 'big' server and 'small' embedded sets of  
>>>> libraries.
>> In fact JavaME CDC/FP doesn't include java.nio, with the result  
>> that I
>> regularly have to patch code that is using java.nio just to do simple
>> byte<->char conversions.
> 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.
>> But in other respects this is a good example - for a
>> large class of applications (those which make only incidental use  
>> of char
>> conversion) the java-only library is perfectly adequate and saves  
>> 1.5 MB
>> (handy if your platform only has 8 MB of ROM!).
> Exactly.  Indeed, there are a number of charconv classes that we might
> decide are not of sufficient general interest to include in the small
> footprint definition.
> Today, the SE char converters are split into 'regular' and  
> 'additional'
> packages.  I'm not convinced about how much thought went into that
> classification, but by packaging them separately we could easily  
> reduce
> the set to a core of converters, with the option to download and add  
> in
> more as you need them.
>> Another area I would like to look at is Locale - last time I looked  
>> Harmony's
>> Calendar  was relying on a 6 MB library to handle Locale-related  
>> stuff, it
>> could be interesting to have a lightweight alternative.
> Yes.  I think we can do better with the set we have got, plus like the
> converters, we could have a reduced core set for those apps that don't
> deal with esoteric Locales.
> In such cases, I would first like to try and define a solution that
> starts small and grows to full SE, rather than define a separate code
> stream approach.
> [1] http://markmail.org/message/x3ydeos244pqpcws
> Regards,
> Tim

View raw message