Hi Tim, > > I can see this working in Mika, in fact I'm tempted to implement it > > already. :-) > > How are you getting on -- did you try it?! I'm cracking on with the > 'non-dynamic' model of removing the optional data in NIO_CHAR.
No, I didn't have time yet, due to customer meetings etc.. However at one of those meetings we had a request to provide java.nio on Mika, so it's definitely time to look at the following: > You can now go into the NIO_CHAR/make/excludesfile and specify > converters to drop from the Harmony provider. That allows you to ditch > some esoteric charsets and save footprint, and in many cases the ICU > provider has an equivalent anyway. But isn't the ICU provider itself rather large? The native charsets look a bit verbose, with their sparsely-populated arrays and "boilerplate" code repeated in different files. I think we might want to "tweak" this a bit ... for java.lang.Character we built some quite compact structures, for example re-using identical table rows (e.g. all 0x00). But we do this at build time based on the selected charsets, and it would be harder if charsets could be added dynamically (so say nothing of unloading them!). In fact it's pretty hard to be dynamic *and* compact *and* start up fast. :-( I suppose the Sun-defined provider mechanism only works for 100%-Java charsets? Regards Chris -- Chris Gray /k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 Skype: k.embedded.chris
