I have updated the patch and add it to jira so that DateFormatSymbols can follow the cimpatibility and write a testcase for its serialization:

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.text.DateFormatSymbols;
import java.util.Arrays;

import junit.framework.TestCase;

public class TestDateFormatSymbolsSerialization extends TestCase {

    private ByteArrayOutputStream bao;

    private ObjectOutputStream oos;

    private ObjectInputStream ois;

    public TestDateFormatSymbolsSerialization(String name) {
        super(name);
    }

    protected void setUp() throws Exception {
        super.setUp();
    }

    protected void tearDown() throws Exception {
        super.tearDown();
    }

    public void test_Serialization_DateFormatSymbols() throws IOException,
            ClassNotFoundException {
        DateFormatSymbols dfs = new DateFormatSymbols();
        String[][] zoneStrings = dfs.getZoneStrings();
        oos = new ObjectOutputStream(bao = new ByteArrayOutputStream());
        oos.writeObject(dfs);
        ois = new ObjectInputStream(new ByteArrayInputStream(bao.toByteArray()));
        DateFormatSymbols result = (DateFormatSymbols) ois.readObject();
        String[][] rsZoneStrings = result.getZoneStrings();
        if (zoneStrings.length != rsZoneStrings.length) {
            fail("zoneStrings and rsZoneStrings is not equal");

        }
        for (int i = 0; i < zoneStrings.length; i++) {
            if (!Arrays.equals(zoneStrings[i], rsZoneStrings[i])) {
                fail("zoneStrings and rsZoneStrings is not equal");
            }
        }
    }
}

2009/2/18 Tony Wu <wuyuehao@gmail.com>
Great! I think it does help us on start up time.

But your patch breaks the serialization compatibility. I suggest to
make the icuSymbols transient and override the writeObject to make
sure the zoneStrings has been initialized before writing it out. And I
think it is not necessay to maintain the local var with the same name
anymore.

On Wed, Feb 18, 2009 at 1:43 PM, Deven You <devyoudw@gmail.com> wrote:
> Hi,
> I have raised a jira HARMONY-6095 for improving java.text.DateFormatSymbols
> performance. I found  DateFormatSymbols(Locale) will invoke
> com.ibm.icu.text.DateFormatSymbols.getZoneStrings() which can take
> significant time but rarely used in real world applications. So I delay this
> call until it really be used. it seems the performance of
> DateFormatSymbols(Locale)  can be greatly improved.*
> *the testcase is:
>
> import java.text.DateFormatSymbols;
> import java.util.Locale;
>
> public class TestDateFormatSymbols {
>
>    /**
>     * @param args
>     */
>    public static void main(String[] args) {
>        long time = System.currentTimeMillis();
>        DateFormatSymbols dfs = new DateFormatSymbols(Locale.getDefault());
>        time = System.currentTimeMillis() - time;
>
>        System.out.println("the total time is " + time + " ms!");
>    }
>
> }
>
> I have tested  on Intel(R) Core(TM)2 Duo Cpu 2.4GHZ, 2.98GB Memory machine,
> the result is as below:
> Harmony patch before: 1125 ms
>  Harmony patched: 78 ms
>



--
Tony Wu
China Software Development Lab, IBM