Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Won't Fix
    • Affects Version/s: 1.6.3
    • Fix Version/s: None
    • Component/s: parser
    • Labels:
      None
    • Environment:
      suse linux enterprise 64 bit
    • Number of attachments :
      0

      Description

      hi i just tried some groovy by following http://pleac.sourceforge.net/pleac_groovy/numbers.html
      code:

      import java.text.*
       int nb = 0
      try {
          nb = NumberFormat.getInstance().parse('33.5') // '.5' will be ignored
          nb = NumberFormat.getInstance().parse('abc')
      } catch (ParseException ex) {
          assert ex.getMessage().contains('abc')
      }
      assert nb == 33
      

      i get the error Caught: java.lang.AssertionError: Expression: (nb == 33). Values: nb = 335

      and when i do println nb it gives me the value 335 !
      i categorize this as blocker because it can block the whole system if youre working with floats castings

      greeets umit

        Activity

        Hide
        umit added a comment -

        ok the code that i pasted is modified by jira
        ill try once again:

        import java.text.*
        int nb = 0
        nb = NumberFormat.getInstance().parse('33.5') // '.5' will be ignored
        println nb

        should be enough
        the .5 won't be ignored

        Show
        umit added a comment - ok the code that i pasted is modified by jira ill try once again: import java.text.* int nb = 0 nb = NumberFormat.getInstance().parse('33.5') // '.5' will be ignored println nb should be enough the .5 won't be ignored
        Hide
        blackdrag blackdrag added a comment -

        I added code tags... umit, for those you have to start the code part with {code:Java}, the :Java will create syntac highliting for Java, which is equal enough to groovy. You end the code ares with {code}

        Show
        blackdrag blackdrag added a comment - I added code tags... umit, for those you have to start the code part with {code:Java}, the :Java will create syntac highliting for Java, which is equal enough to groovy. You end the code ares with {code}
        Hide
        blackdrag blackdrag added a comment -

        now on the issue itself... You use the Java-API here, so given that the correct string is given to the Java-API Groovy is not doing anything wrong here. In what cases could ".5" be ignored? Numberformat.getinstance() returns a NumberFormat with the current locale. If the locale is form an UK or US area, then the comma is used to mark thousands and the dot to mark the part lower 1. But if the locale is for example German, then the dot is used for thousands and the the comman for parts lower 1. An implementation could for example simply ignore the thousand markings and thus 33.5 might be 335, because "." is not seen as introducing the part <1.

        Since my system is German I can reproduce the error, but if I change your code to

        import java.text.*
         int nb = 0
        try {
            nb = NumberFormat.getInstance(Locale.US).parse('33.5') // '.5' will be ignored
            nb = NumberFormat.getInstance(Locale.US).parse('abc')
        } catch (ParseException ex) {
            assert ex.getMessage().contains('abc')
        }
        assert nb == 33
        

        everything works just fine.

        If you want someone to blame for not throwing an exception even though the thousands marking is not followed by 3 digits, then fill a bug report for sun.

        Show
        blackdrag blackdrag added a comment - now on the issue itself... You use the Java-API here, so given that the correct string is given to the Java-API Groovy is not doing anything wrong here. In what cases could ".5" be ignored? Numberformat.getinstance() returns a NumberFormat with the current locale. If the locale is form an UK or US area, then the comma is used to mark thousands and the dot to mark the part lower 1. But if the locale is for example German, then the dot is used for thousands and the the comman for parts lower 1. An implementation could for example simply ignore the thousand markings and thus 33.5 might be 335, because "." is not seen as introducing the part <1. Since my system is German I can reproduce the error, but if I change your code to import java.text.* int nb = 0 try { nb = NumberFormat.getInstance(Locale.US).parse('33.5') // '.5' will be ignored nb = NumberFormat.getInstance(Locale.US).parse('abc') } catch (ParseException ex) { assert ex.getMessage().contains('abc') } assert nb == 33 everything works just fine. If you want someone to blame for not throwing an exception even though the thousands marking is not followed by 3 digits, then fill a bug report for sun.
        Hide
        umit added a comment -

        done i wrote a bug report to sun.
        however the code can also be written as:

        
        import java.text.*
        int nb = 0
        nb = NumberFormat.getInstance().parse('33,5') // ',5' will be ignored
        println nb
        
        
        Show
        umit added a comment - done i wrote a bug report to sun. however the code can also be written as: import java.text.* int nb = 0 nb = NumberFormat.getInstance().parse('33,5') // ',5' will be ignored println nb
        Hide
        blackdrag blackdrag added a comment -

        I suggest you read http://www.javapractices.com/topic/TopicAction.do?Id=210
        NumberFormat.getInstance() will most probably return a DecimalFormat instance. If you want to parse the number, I suggest you use Double or BigDecimal to parse it. But beware, that this is also depending on the locale.

        Show
        blackdrag blackdrag added a comment - I suggest you read http://www.javapractices.com/topic/TopicAction.do?Id=210 NumberFormat.getInstance() will most probably return a DecimalFormat instance. If you want to parse the number, I suggest you use Double or BigDecimal to parse it. But beware, that this is also depending on the locale.

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            umit
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1 hour
              1h
              Remaining:
              Remaining Estimate - 1 hour
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified