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

java.txt.SimpleDateFormat.parse side-effect gone without notification

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.4.2
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Introduced In Version:
    • CPU:
      x86
    • OS:
      windows_xp

      Description

      FULL PRODUCT VERSION :
      The issue was first encountered with:

      java version "1.4.2"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
      Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

      It also appears with "1.5.0-beta".

      The earlier and different behavior may be seen with:

      java version "1.4.1_02"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
      Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

      but it also appears in 1.3.1, 1.4.1 and 1.4.1_1.




      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows XP [Version 5.1.2600]

      A DESCRIPTION OF THE PROBLEM :
      The small java program included the "source code" section gets different results when run using "1.4.2" and "1.4.1_02" when run with an argument,e.g.

      $java Test3 x

      but get the same result for "1.4.2" and "1.4.1_02" when run without an argument, i.e.

      $java Test3

      However, I see no documentation in the 1.4.2 release notes of the incompatibility and I found no bug report (fixed or open) about this difference.
      The difference is in the execution of
           Date d1 = fmt.parse(str, new ParsePosition(0));
      which, when run with 1.4.1_02, seems to alter the result of a subsequent
          internalGet(Calendar.ZONE_OFFSET);
      So it seems that executing SimpleDateFormat.parse changed the result of "internalGet(Calendar.ZONE_OFFSET)" with 1.4.1_02 but does not with 1.4.2. That may be a fix but I find no documentation of the change.

       The changes leads to failures in our product when an upgrade to 1.4.2 is made.

      When th SimpleDateFormat.parse is done (e.g. by java Test3 x), the output differs between 1.4.1_02 and 1.4.2, apparently due to a side effect in 1.4.1_02. Eliminating the side effect may be desirable, but I find no release documentation (e.g. incompatibilities) or bug report addressing this change.

       


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Put the source code in the "source code" section in a file named
      Test3.java. Then do:

      $ javac Test3.java
      $ java Test3
      $ java Test3 x



      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      I expected that either behavior would not have changed or that either a bug report or some release note for 1.4.2 would have explained the change from 1.4.1_02 to 1.4.2. Otherwise, although the new behavior seems desirable, it's uncertain whether it is present by intent or accident. As it is, it seems our product will have to provide version-specific logic to hide this difference between 1.4.1_02 and 1.4.2 and it would be nice to know that the new 1.4.2 behavior was intentional and therefore more likely to remain in future versions.
      ACTUAL -
      I'm repeating here part of what was included in the steps to
      reproduce:

      Here's the result when running with 1.4.1_02:

      bash-2.05b$ javac Test3.java
      bash-2.05b$ java Test3
      zone = -28800000
      bash-2.05b$ java Test3 x
      zone = -18000000
      bash-2.05b$ java -version
      java version "1.4.1_02"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
      Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

      Here's the output using 1.4.2. Notice that the result of
         java Test3 x
      differs from the 1.4.1_02 result:

      bash-2.05b$ javac Test3.java
      bash-2.05b$ java Test3
      zone = -28800000
      bash-2.05b$ java Test3 x
      zone = -28800000
      bash-2.05b$ java -version
      java version "1.4.2"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
      Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
      bash-2.05b$


      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      Here's the small test case:

      import java.text.SimpleDateFormat;
      import java.text.ParsePosition;
      import java.util.Date;
      import java.util.Locale;
      import java.util.TimeZone;
      import java.util.Calendar;
      import java.util.GregorianCalendar;

      class Test3 {
      public static void main(String[] args) {
      String str = "9:30:00 EST";
      SimpleDateFormat fmt = new SimpleDateFormat("HH:mm:ss z", Locale.US);
      _ParseCalendar parseData;
      parseData = new _ParseCalendar(fmt.getCalendar(), Locale.US);
      fmt.setCalendar(parseData);
      if (args.length > 0) {
      Date d1 = fmt.parse(str, new ParsePosition(0));
      }
      System.out.println("zone = " + parseData.get());
      }

      private static class _ParseCalendar extends GregorianCalendar
      {
      _ParseCalendar(Calendar cal, Locale locale)
      {
      super(cal.getTimeZone(), locale);
      }

      int get() { return internalGet(Calendar.ZONE_OFFSET); }
      }

      }

      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      Haven't addressed yet. I assume we can adjust for the new 1.4.2 behavior and implement version specific logic so as to handle 1.4.1_02 and earlier java versions. Apparently there has been a history with our product of adjusting for various bugs in java releases in the date, time, and timezone areas, but it would be helpful (even if it seems idealistic) if we can clearly identify the need for such changes by readily found documentation in the jdk release notes or in supplementary documentation pointed to by the release notes.

      Thanks.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: