Improve test coverage for SimpleDateFormat
Commit 5a2c0fcc0f7030758b6bc13b828ed40a8a55ad75 added an Android-removed
section to matchString() to fix a bug in fast-path logic.
This CL adds test coverage for the distinction between the buggy vs. the
fixed logic.
Specifically, the buggy logic assumed that the first key matched is the
one needed but it has a faulty justification: it relyies on the fact
that "first match is the answer" is wrong in case when key set traversed
has two keys so that one is a prefix of another.
For example, imagine matching "15 července 2020" which is "15
June 2020" in Czech. When SimpleDateFormat parses date it tries to
match all field names with current text chunk. This set of field names
in this case would contain month names in nominative and genitive cases
so it containts "července" (July in genitive) and "červen" (July in
nominative). Since the real answer is "července" but "červen" would
still match it picks the wrong shorter field and parsing fails.
This can be fixed by iterating keys in descending order but this is
still may be faulty if Map's comparator is overridden.
This test creates two custom calendars that behave as GregorianCalendar
except they override getDisplayNames() so it wraps it's return value in
in TreeMap instead of HashMap which is used by default so it becomes an
instance of SortedMap. This makes SimpleDateFormat with enabled buggy
code to fail to parse such dates.
The second calendar in addition overrides comparator with a inverted
(descending) version to demonstrate that iterating key set in descending
order does not fix the issue.
Bug: 119913354
Test: atest core-tests:libcore.java.text.SimpleDateFormatTest#testMatchStringSortedMap
Change-Id: Iede082f5972ae6288674db08fda4f32cceef5441
1 file changed