Harmony
  1. Harmony
  2. HARMONY-1110

[classlib][text] ChoiceFormat(String) pattern parser differs from RI

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Classlib
    • Labels:
      None

      Description

      Harmony and RI have different pattern parsers implementations of ChoiceFormat class. Spec hasn't any rules for pattern except a single example
      "-1#is negative| 0#is zero or fraction | 1#is one |1.0<is 1+ |2#is two |2<is more than 2."
      So we have some differences in pattern processing

      Test ---------------------------------------------------------------------------------------

      import java.text.*;

      public class bug9411 {
      public static void main(String[] args) {
      try

      { System.out.println(new ChoiceFormat("2|").toPattern()); }

      catch (Exception e)

      { e.printStackTrace(); }

      try

      { System.out.println(new ChoiceFormat("2#ok #ab").toPattern()); }

      catch (Exception e)

      { e.printStackTrace(); }

      try

      { System.out.println(new ChoiceFormat("2#ok <ab").toPattern()); }

      catch (Exception e)

      { e.printStackTrace(); }

      }
      }

      Output ---------------------------------------------------------------------

      RI
      0.0#
      java.lang.IllegalArgumentException
      at java.text.ChoiceFormat.applyPattern(ChoiceFormat.java:197)
      at java.text.ChoiceFormat.<init>(ChoiceFormat.java:294)
      at bug9411.main(bug9411.java:12)
      java.lang.IllegalArgumentException
      at java.text.ChoiceFormat.applyPattern(ChoiceFormat.java:197)
      at java.text.ChoiceFormat.<init>(ChoiceFormat.java:294)
      at bug9411.main(bug9411.java:17)

      Harmony
      java.lang.IllegalArgumentException
      at java.text.ChoiceFormat.applyPattern(ChoiceFormat.java:127)
      at java.text.ChoiceFormat.<init>(ChoiceFormat.java:66)
      at bug9411.main(bug9411.java:7)
      2.0#ok #ab
      2.0#ok <ab

        Activity

        Hide
        Jim Yu added a comment -

        I agree with Denis Kishenko's view point that symbols "|", "#" and "<" should be treated as reserved ones because of their influence on pattern parse algorithm. And we should put them in quotes to avoid misunderstandings when they are used in formats. According to my regression test cases, RI behaves just like that. Now that spec doesn't have specific rules about it, I think we should follow RI's behavior. I've submitted the patch.

        Show
        Jim Yu added a comment - I agree with Denis Kishenko's view point that symbols "|", "#" and "<" should be treated as reserved ones because of their influence on pattern parse algorithm. And we should put them in quotes to avoid misunderstandings when they are used in formats. According to my regression test cases, RI behaves just like that. Now that spec doesn't have specific rules about it, I think we should follow RI's behavior. I've submitted the patch.
        Hide
        spark shen added a comment -

        Hi Denis Kishenko:
        I have forwarded our disscussion onto dev list. Shall we discuss this one there.

        Best regards

        Show
        spark shen added a comment - Hi Denis Kishenko: I have forwarded our disscussion onto dev list. Shall we discuss this one there. Best regards
        Hide
        Denis Kishenko added a comment -

        From my point of view, symbols "|", "#" and "<" should be reserved as pattern control symbols because they influence of pattern engine algorithm. If user want to use such symbols let's put them in quote to avoid misunderstandings.

        2#ok #ab => 2#"ok #ab"
        2#ok <ab => 2#"ok <ab"

        Show
        Denis Kishenko added a comment - From my point of view, symbols "|", "#" and "<" should be reserved as pattern control symbols because they influence of pattern engine algorithm. If user want to use such symbols let's put them in quote to avoid misunderstandings. 2#ok #ab => 2#"ok #ab" 2#ok <ab => 2#"ok <ab"
        Hide
        spark shen added a comment -

        Hi Denis Kishenko

        But I totally agree with harmony on 3 cases.
        On the first, '2|' indicates that there are 2 choices, but the second one is missing. So throwing an IllegalArgumentException is OK.
        On the second and third('2#ok #ab' & '2#ok <ab') there is only one choice. When the formatted thing >= 2, then ok#ab or ok <ab should be used IMHO.

        Best regards

        Show
        spark shen added a comment - Hi Denis Kishenko But I totally agree with harmony on 3 cases. On the first, '2|' indicates that there are 2 choices, but the second one is missing. So throwing an IllegalArgumentException is OK. On the second and third('2#ok #ab' & '2#ok <ab') there is only one choice. When the formatted thing >= 2, then ok#ab or ok <ab should be used IMHO. Best regards
        Hide
        Denis Kishenko added a comment -

        Spark, which behavior is reasonable depends on point of view. For example for me Harmony is reasonable in the first case while RI is reasonable in the second and third cases.

        Show
        Denis Kishenko added a comment - Spark, which behavior is reasonable depends on point of view. For example for me Harmony is reasonable in the first case while RI is reasonable in the second and third cases.
        Hide
        spark shen added a comment -

        On this specific case, seems the behavior of harmony is also reasonable. I suggest to change component to Non-bug difference.

        Best regards

        Show
        spark shen added a comment - On this specific case, seems the behavior of harmony is also reasonable. I suggest to change component to Non-bug difference. Best regards

          People

          • Assignee:
            Unassigned
            Reporter:
            Denis Kishenko
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development