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 [general] Reduced footprint class library
Date Thu, 18 Sep 2008 13:10:00 GMT
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


View raw message