Hi, AFAIK internal providers implementation came from HARMONY-3593 ([classlib][nio_char] Contribution of charset encoders/decoders for nio_char module). And as far as I understand these providers still have some benefits - they're faster than ICU's ones and fix some known ICU issues (see HARMONY-3307 for example). Original announcement message can be found at http://article.gmane.org/gmane.comp.java.harmony.devel/25623
In this way, I think we should be careful with switching back to pure-ICU without detailed investigation. Thanks, Alexei 2007/10/8, Ilya Berezhniuk <[EMAIL PROTECTED]>: > 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.
