Spring CustomNumberEditor issue with string conversion [SPR-14689]

Giuseppe Corsaro opened SPR-14689 and commented

Hello, I think to have found an issue in the CustomNumberEditor class in the Spring Beans package. The issue is caused by a presumable bug in java.text.NumberFormat.parse that doesn't convert the number following the specified pattern. Here you can find an example on ideone https://ideone.com/6l0bGF In the example I'd expect to have one digit after comma, when using parse, as done by using format method To workaround the issue I have created a copy of CustomNumberEditor where I changed the setAsText method from:

@Override
public void setAsText(String text) throws IllegalArgumentException {
     if (this.allowEmpty && !StringUtils.hasText(text)) {
          // Treat empty String as null value.
          setValue(null);
     }
     else if (this.numberFormat != null) {
          // Use given NumberFormat for parsing text.
          setValue(NumberUtils.parseNumber(text, this.numberClass, this.numberFormat));
     }
     else {
          // Use default valueOf methods for parsing text.
          setValue(NumberUtils.parseNumber(text, this.numberClass));
     }
}

to

@Override
public void setAsText(String text) throws IllegalArgumentException {
     if (this.allowEmpty && !StringUtils.hasText(text)) {
          // Treat empty String as null value.
          setValue(null);
     }
     else if (this.numberFormat != null) {
          // Use given NumberFormat for parsing text.
          try {
               setValue(this.numberFormat.parse(this.numberFormat.format(NumberUtils.parseNumber(text, this.numberClass, this.numberFormat))));
          } catch (ParseException e) {
               setValue(null);
          }
     }
     else {
          // Use default valueOf methods for parsing text.
          setValue(NumberUtils.parseNumber(text, this.numberClass));
     }
}

I realize it's an issue related to java framework but it would be great to change the modifier for numberClass, numberFormat and allowEmpty to protected in order to make CustomNumberEditor class extensible. Just for info, I'm running the code in a Spring Batch job.

---

Affects: 4.3.2

Comment From: spring-projects-issues

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Comment From: corzar71

Hello, I've seen you have closed this issue but it would be nice if you open again and make those methods protected. I think it's a quite important improvement.

Comment From: rstoyanchev

Team Decision: We've discussed this and see it as intended behavior, to preserve maximum detail when parsing, so not a bug. You can control numberClass, numberFormat, and allowEmpty through the constructor, but for custom parsing, e.g. combined with extra formatting, just use the existing PropertyEditor as a recipie and create your own.