Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8151431

DateFormatSymbols triggers this.clone() in the constructor

    Details

    • Subcomponent:
    • Resolved In Build:
      b114
    • CPU:
      x86
    • OS:
      windows_8
    • Verification:
      Verified

      Backports

        Description

        FULL PRODUCT VERSION :


        A DESCRIPTION OF THE PROBLEM :
        To implement my own locale service provider, I have a class extending java.text.DateFormatSymbols. My custom subclass's constructor implicitly invokes the no-args constructor in java.text.DateFormatSymbols. The constructor calls a private method - initializeData(Locale).

        It looks the implementation was updated in Java 8 and initializeData is now trying to cache an instance of DateFormatSymbols at the end and calls this.clone().

        In my own subclass implements clone() method, which copies a field initialized by a constructor in the class. For example,

        ===============
        public class MyDateFormatSymbols extends DateFormatSymbols {
            private final Foo foo;

            public MyDateFormatSymbols(Foo foo) {
                if (foo == null) {
                    this.foo = new Foo();
                } else {
                    this.foo = foo;
                }
            }

            @Override
            public Object clone() {
                MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone();
                mdfs.foo = this.foo.clone();
            }
        }
        ===============

        When the constructor MyDateFormatSymbols(Foo) is called, it triggers no-args constructor of the super class - DateFormatSymbols() first. As I explained earlier, Java 8 implementation calls this.clone() in DateFormatSymbpls.initializeData(Locale). At that point, the field foo in my class is not yet initialized, so this.foo.clone() will throw NullPointerException.

        My own code expects the field 'foo' is always non-null. I could change clone() to check if this.foo is null or not, but I cannot control cached 'premature' instance held by Java DateFormatSymbols. At this moment, it looks the cache is only used for copying field values maintained by DateFormaSymbols itself and never call a method. So, even 'premature' instance of my own subclass instance is referenced by DateFormatSymbols, it won't cause any problems. However, if the Java's implementation is changed to call any DateFormatSymbols method overridden by my own subclass, it may not work (because my subclass expects the field foo is non-null).

        Such code above did not have any problems with earlier Java releases (Java 6 / 7).

        In my opinion, this.clone() should not be called in DateFormatSymbols initialization code. Instead, it should create a private container class for these symbols, and cache the object, not DateFormatSymbols itself.

        REGRESSION. Last worked in version 7u80


        REPRODUCIBILITY :
        This bug can be reproduced always.

          Issue Links

            Activity

            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26b82c87d8c7
            User: okutsu
            Date: 2016-04-07 08:52:33 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26b82c87d8c7 User: okutsu Date: 2016-04-07 08:52:33 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26b82c87d8c7
            User: lana
            Date: 2016-04-13 17:56:05 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26b82c87d8c7 User: lana Date: 2016-04-13 17:56:05 +0000

              People

              • Assignee:
                okutsu Masayoshi Okutsu
                Reporter:
                okutsu Masayoshi Okutsu
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: