I incorporated the suggestions from Mandy and Alan. Also one change
since the last webrev was to revert the hard-coding of the supported
locales list back to the one which dynamically generates the lists at
the build time. I initially thought static listing of locales would be
less complex as to the build script/makefile, but on second thought it's
less evil than possible future regressions.
Please review:
http://cr.openjdk.java.net/~naoto/8038436/webrev.5/
Naoto
On 8/28/14, 11:34 AM, Naoto Sato wrote:
Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the
changes based on your suggestions as follows:
http://cr.openjdk.java.net/~naoto/8038436/webrev.4/
Here are the changes since webrev.3
- CLDRLocaleProviderAdapter.java: modified to throw
UnsupportedOperationException with the actual exception set to its
"cause." More descriptive comment on it.
- *ProviderImpl.java: Removed changes to them. Initial thought was to
make them performant by changing the langtags to static, but it turned
out that wasn't necessary.
- JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: Renamed
to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo respectively for
readability. String constants are wrapped for readability as well. Used
getOrDefault() for getSupportedLocaleString().
- Added test cases for SecurityException and JRE's supported locales for
each service.
I'd appreciate it if someone in the build-dev could review the makefile
changes.
Naoto
On 8/22/14, 11:46 AM, Naoto Sato wrote:
Hello,
Please review the changes for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8038436
The proposed changes are located at:
http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
The idea is to introduce an SPI so that supported locales are
dynamically searched at runtime, not depending on the existence of
physical jar files.
I'd appreciate it if build folks could review the makefile related
changes, i18n forks to review locale framework files, and Mandy from
modularization point of view.
Naoto
