harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [general] Reduced footprint class library
Date Thu, 18 Sep 2008 13:43:18 GMT
Alex Blewitt wrote:
> 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?

Now y'a getting fancy <g> but "yes" it is possible.  In fact, you could
generalize that to arbitrary areas of functionality.

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

"Put floppy in drive A:"

> Sent from my (new) iPhone

Sent from my (old) laptop

Tim - with apologies for being flippant :-)

> 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