Chris Gray wrote: >> 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?
Yes. We can move on to look at reducing that too, but first order was to reduce the duplication we are responsible for. > 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. :-( The natives are there to support heuristic optimization of encoding/decoding direct buffers. While it makes sense on a machine with lots of resources (e.g. a server) it doesn't for constrained devices which is why they are now optional. I agree that it is hard to balance all the requirements, but I think it is feasible to assess each module for scalability though design, rather than making a single choice of target. > I suppose the Sun-defined provider mechanism only works for 100%-Java > charsets? Not sure I understand the question. You can write a provider with non-Java code too (like the native code we have got), but you then hook into the provider mechanism through the Java APIs. Of course, you can also have 'built-in' providers that are not added via the regular framework APIs, which we use for example in bootstrapping the class libraries. Regards, Tim
