Skip to content

GitLab

Switch branch/tag
  1. 05 Oct, 2016 2 commits
  3. 04 Oct, 2016 2 commits
  5. 03 Oct, 2016 1 commit
  7. 30 Sep, 2016 1 commit
    • Neil Fuller's avatar
      Remove DateFormat time pattern caching · 6fdc0bf1
      Neil Fuller authored 
      This change removes pattern string caching from
the SimpleDateFormat constructor only used by
DateFormat.getInstance().

Before this change, the LocaleData.getTimeFormat(int) method
that is used to populate the cached data can return different
information for SHORT and MEDIUM times based on the
DateFormat.is24Hour setting and so the results are not safe
to cache: if the user modifies their "use 24-hour format"
setting and the data is already cached the old pattern was
persisted forever.

This was also causing various CTS tests to fail if the device
had the "use 24-hour format" setting on. For example:

libcore.java.text.OldDateFormatTest
org.apache.harmony.tests.java.text.MessageFormatTest
org.apache.harmony.tests.java.util.DateTest

Callers of java.text.DateFormat.get(int, int, int, Locale)
are affected. In practice that means DateFormat.getTimeInstance()
/ getTimeInstance(int) and getTimeInstance(int, Locale).

Indirect callers in the Android framework include:
android.text.format.DateUtils
android.text.format.DateFormat
android.widget.DigitalClock
java.text.MessageFormat

This change has a small negative affect on performance, but
not a significant one: obtaining a DateFormat via
DateFormat.getTimeInstance() goes from ~28us to
~33us on an Angler device.

Full results for the benchmarks included:

Before:

benchmarkMethod=timeGetDateTimeInstance
runtime(ns): min=27518.68, 1st qu.=28461.12, median=28775.87,
mean=28732.44, 3rd qu.=29235.59, max=29320.80
runtime(ns): min=28599.17, 1st qu.=28769.57, median=29277.13,
mean=29682.69, 3rd qu.=29824.08, max=33419.06

benchmarkMethod=timeGetDateTimeInstance_multiple
runtime(ns): min=108667.38, 1st qu.=110223.70, median=111547.98,
mean=112173.89, 3rd qu.=113748.88, max=118091.12
runtime(ns): min=102995.66, 1st qu.=105045.16, median=108558.77,
mean=108817.18, 3rd qu.=111677.65, max=115886.11

After:

benchmarkMethod=timeGetDateTimeInstance
runtime(ns): min=31365.39, 1st qu.=32904.01, median=33303.47,
mean=33244.55, 3rd qu.=33983.32, max=34052.99
runtime(ns): min=31785.28, 1st qu.=32921.68, median=33364.01,
mean=33531.03, 3rd qu.=34301.06, max=35031.33

benchmarkMethod=timeGetDateTimeInstance_multiple
runtime(ns): min=126834.48, 1st qu.=128605.17, median=130069.44,
mean=131157.63, 3rd qu.=134095.26, max=138164.92
runtime(ns): min=124618.08, 1st qu.=126097.91, median=130190.93,
mean=130027.17, 3rd qu.=131991.56, max=140283.06

Bug: 31762542
Test: Ran CtsLibcoreTestCases with the "use 24-hour format" on
      and off
Change-Id: I02798e8fcd2ed5f7625a32261112560b5d9b18f3
      6fdc0bf1
  9. 21 Sep, 2016 1 commit
  11. 19 Sep, 2016 1 commit
    • Neil Fuller's avatar
      Fix DatagramSocket.disconnect() · 393a0c10
      Neil Fuller authored 
      Fix DatagramSocket.disconnect() in the case where an exception has
been thrown during connect().

commit 6764aa32 introduced a bug
because it would leave connectState as ST_CONNECTED when
connect() failed. The correct state in this case appears to be
ST_CONNECTED_NO_IMPL instead (which is then dealt with correctly
by disconnect()).

This change rearranges the Android changes over upstream to make it
closer to upstream and try to make it clearer what state is guaranteed
after an exception is thrown.

Test: Ran CtsLibcoreTestCases
Bug: 31218085
(cherry picked from commit 979fbd7f)

Change-Id: I8b8e595a8c160b9dbc3450ae20da1be5fb91f47c
      393a0c10
  13. 18 Sep, 2016 1 commit
  15. 16 Sep, 2016 2 commits
  17. 15 Sep, 2016 12 commits
  19. 14 Sep, 2016 2 commits
  21. 13 Sep, 2016 14 commits
  23. 12 Sep, 2016 1 commit