ICU4J Locale service returns incorrect result with unsupported class loader protocol

Deleted Component: misc

ICU4J service framework depends on the list of all available locales. The list of all available locales is created by walking through a resource path. However, when class loader uses a protocol not supported by ICU (file/jar), it cannot walk through the resource path. As the fallback logic, the trunk version uses res_index.res.

res_index.res is created at build time for Locale::getAvailableLocales in ICU4C. The list of locales in this resource does not contain aliases and root.

ICU4J service framework validate a request locale with the available list first. Thus, when the fallback logic (res_index.res) is used above, an alias locale (such as "iw") or root locale is treated as unsupported.

Until ICU 4.2, ICU4J build script generated res_index.txt which contains all available locales including aliases and root. The service code relied on the list in res_index.txt and did not use res_index.res (this is really confusing.. ICU4C build create res_index.txt at build time, but the one created by ICU4J 4.2 build script is different..)

In longer term, we should review the design of the ICU4J service framework. I'm wondering if we really need to maintain all available locales in the framework code. In short term, we need to re-introduce build time generated available locale list (but I suggest to use a name other than res_index.txt, because it does not match the contents of res_index.res) and use it as the fallback when unknown class loader protocol is used.