Hi Nishit,
Here are my comments:
- CLDRConverter: As the compact pattern no more employs List<String>,
can we eliminate stringListEntry/Element, and use Array equivalent instead?
- CompactNumberFormat.java
Multiple locations: Use StringBuilder instead of StringBuffer.
line 268: The link points to NumberFormat.getNumberInstance(Locale)
instead of DecimalFormat
line 855: no need to do toString(). length() can detect whether it's
empty or not.
line 884: "Overloaded method" reads odd here. I'd prefer specializing in
the "given number" into either long or biginteger.
line 1500: subparseNumber() pretty much shares the same code with
DecimalFormat.subparse(). can they be merged?
line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls super.
No need to override them.
line 2231: You need to test the type before cast. Otherwise
ClassCastException may be thrown.
Naoto
On 11/16/18 9:54 AM, Nishit Jain wrote:
Hi,
Please review this non trivial feature addition to NumberFormat API.
The existing NumberFormat API provides locale based support for
formatting and parsing numbers which includes formatting decimal,
percent, currency etc, but the support for formatting a number into a
human readable or compact form is missing. This RFE adds that feature to
format a decimal number in a compact format (e.g. 1000 -> 1K, 1000000 ->
1M in en_US locale) , which is useful for the environment where display
space is limited, so that the formatted string can be displayed in that
limited space. It is defined by LDML's specification for Compact Number
Formats.
http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats
RFE: https://bugs.openjdk.java.net/browse/JDK-8177552
Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8188147
Request to please help review the the change.
Regards,
Nishit Jain
