Agree, there is no problem - Charset class adds internal charsets first, and when adding charsets from ICU it skips existing ones, comparing by charset canonical name.
Probably the reason is easy extensibility - external charset provider can be simply substituted in configuration file, and also several external providers could be specified. 2007/10/8, Oliver Deakin <[EMAIL PROTECTED]>: > Ilya Berezhniuk wrote: > >>> BTW, We keep some resource bundle classes in luni, such as Locale and > >>> Currency, which used by luni and text module. These data are aslo > >>> included in icu, I suggest to remove this overlap, just keep one of > >>> them. > >>> > >> Agreed - if we can use the ICU version of these resources then IMHO we > >> should do it. > >> > > > > There is similar place in java/nio/charset/Charset: when > > availableCharsets method prepares charsets it concatenates ICU > > charsets with a set of internal charsets returned by > > org.apache.harmony.niochar.CharsetProviderImpl class. But I'm not > > quite sure that it should be fixed; probably there were some reasons > > for such approach. > > > > It would be interesting to know the reasons for this. Where they > charsets missing from ICU or were the ICU versions of those charsets > lacking something? I would think that if it was possible for us to feed > those issues back to ICU and have them maintain these resources for us > it would be a good thing. However I don't see any problem with us > keeping the Harmony versions of these resources if need be - I don't > feel strongly either way. > > Regards, > Oliver > > > Ilya > > > > > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > -- Ilya
