Fix handling of invalid locales in Date/DecimalFormatSymbols.

For locales whose language code is "und" we use Locale.ROOT
instead. This also fixes two other corner cases :

- We were using the wrong locale to fetch timezone strings
  when the input locale was null. we now use the same locale
  throughout by making sure we don't perform any subsititutions
  in LocaleData.get.

- Adds a clearer comment about the broken serialization
  behaviour.

bug: 15849709

Change-Id: I95e7eb0ccb7458711038ce9b1c76b3279acda9d6

1 files changed, 1 insertions, 1 deletions

diff --git a/harmony-tests/src/test/java/org/apache/harmony/tests/java/text/DateFormatSymbolsTest.java b/harmony-tests/src/test/java/org/apache/harmony/tests/java/text/DateFormatSymbolsTest.java
index 9fe3681..70e41a2 100644
--- a/harmony-tests/src/test/java/org/apache/harmony/tests/java/text/DateFormatSymbolsTest.java
+++ b/harmony-tests/src/test/java/org/apache/harmony/tests/java/text/DateFormatSymbolsTest.java
@@ -88,7 +88,7 @@ public class DateFormatSymbolsTest extends junit.framework.TestCase {
 
         Locale locale = new Locale("not exist language", "not exist country");
         DateFormatSymbols symbols = DateFormatSymbols.getInstance(locale);
-        assertNotNull(symbols);
+        assertEquals(DateFormatSymbols.getInstance(Locale.ROOT), symbols);
     }
 
     /**