Spring Batch
  1. Spring Batch
  2. BATCH-1777

org.springframework.batch.core.converter.DefaultJobParametersConverter not safe for use with certain Locales

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 2.1.8
    • Fix Version/s: 2.1.9
    • Component/s: Core
    • Labels:
      None

      Description

      if you run the tests for org.springframework.batch.core.converter.DefaultJobParametersConverter on a machine with Locale.GERMAN

      testGetParametersWithNumberFormat (uses "value(long)=1,000")
      and
      testGetParametersWithDouble (uses "value(double)=1.38")

      will fail because of Locale problems
      (same applies to org.springframework.batch.core.step.job.DefaultJobParametersExtractorJobParametersTests testGetNamedDoubleJobParameters (uses "foo(double)=11.1"
      which uses the Converter under the hood)

      i would not call this a bug, because it would be a real hassle to solve the Locale problems for all Possibilities

      but maybe you could improve the Default..Converter to make it possible to set the locale and include following code
      for the NumberFormat instance

      // property locale or default
      NumberFormat f = NumberFormat.getInstance(Locale.getDefault());
      // getInstance might return a DecimalFormat, depends on Locale
      if (f instanceof DecimalFormat)

      { Double result = ((DecimalFormat) f).parse(value).doubleValue(); }

      // some fallback code

      the current JUnit tests would need an improvement too

      factory.setLocale(Locale.UK) // or .US

        Activity

        Hide
        Dave Syer added a comment -

        The JobParametersConverter is injectable wherever it is used I think, so it's pretty easy to write your own and use that as a workaround (or just use a non-localised format for specifiying JobParameters as Properties).

        Show
        Dave Syer added a comment - The JobParametersConverter is injectable wherever it is used I think, so it's pretty easy to write your own and use that as a workaround (or just use a non-localised format for specifiying JobParameters as Properties).
        Hide
        Michael Lange added a comment -

        fair enough, maybe you could add the Locale Problem to the JavaDoc

        Show
        Michael Lange added a comment - fair enough, maybe you could add the Locale Problem to the JavaDoc
        Hide
        Dave Syer added a comment -

        Actually, you can already inject a NumberFormat and DateFormat instance into the DefaultJobParametersConverter, and the Javadocs say that it is not used to parse doubles, but it is (it's just not used to format them). See also BATCH-1756.

        I actually don't think there is a general solution to this problem so a custom converter might be necessary for some people anyway. I have updated the javadocs and also changed the behaviour so that if a NumberFormat is supplied it is always used, which seems like the most straightforward solution, but might not always be what you want.

        Show
        Dave Syer added a comment - Actually, you can already inject a NumberFormat and DateFormat instance into the DefaultJobParametersConverter, and the Javadocs say that it is not used to parse doubles, but it is (it's just not used to format them). See also BATCH-1756 . I actually don't think there is a general solution to this problem so a custom converter might be necessary for some people anyway. I have updated the javadocs and also changed the behaviour so that if a NumberFormat is supplied it is always used, which seems like the most straightforward solution, but might not always be what you want.

          People

          • Assignee:
            Dave Syer
            Reporter:
            Michael Lange
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: