Spring Batch
  1. Spring Batch
  2. BATCH-1723

Change JobParameters to use wrapper types for getLong and getDouble

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 2.1.7
    • Fix Version/s: 2.2.0, 2.2.0 - Sprint 17
    • Component/s: Core
    • Labels:
      None

      Description

      As a continuation of BATCH-1316 I'm filing this request in hopes it will make into the 3.0.0 release. The requested change to JobParameters is that "long getLong" and "double getDouble" change back to "Long getLong" and "Double getDouble" respectively as they were in Spring Batch 1.x. This will allow for optional job parameters without burdening client code with NullPointerException try/catches or "getParameters().contains(...)" (where getParameters() returns Map<String, JobParameter>) precondition checks everywhere getLong or getDouble are called. See BATCH-1316 for a patch and further discussion.

        Activity

        Hide
        Dave Syer added a comment -

        Thanks for the feedback again. The impact of this change on existing users is pretty limited right? They might not even need to re-compile. If you can confirm that we'll change it in a point release.

        Show
        Dave Syer added a comment - Thanks for the feedback again. The impact of this change on existing users is pretty limited right? They might not even need to re-compile. If you can confirm that we'll change it in a point release.
        Hide
        Ian Brandt added a comment -

        Unfortunately this would be a binary and potentially source incompatible change. Classes compiled against long getLong(...) will throw a NoSuchMethodError on a change to java.lang.Long getLong(...). Also, even after a recompile, if anyone coded to long myLong == getLong(...) they'll likely be bit by the change from value equality to reference identity comparison.

        Show
        Ian Brandt added a comment - Unfortunately this would be a binary and potentially source incompatible change. Classes compiled against long getLong(...) will throw a NoSuchMethodError on a change to java.lang.Long getLong(...). Also, even after a recompile, if anyone coded to long myLong == getLong(...) they'll likely be bit by the change from value equality to reference identity comparison.
        Hide
        Dave Syer added a comment -

        Binary compatibility is a problem, but I think we might be still be able to justify that change in 2.2.0 (Spring users are used to quite a lot of new stuff happening in first order releases, and no other Spring projects depend on Spring Batch, so no-one has to re-compile unless they are actually using Spring Batch). The source incompatibility is less of an issue because I think anyone already using "long" will find that equality assertions are the same when they recompile, as long as they stick to "long" and don't mix it up with the odd "Long" (123L==123L any day of the week). In any case 99% of Batch users do not code to the JobParameters API directly - they will be using SpEL - so most people really won't care.

        Show
        Dave Syer added a comment - Binary compatibility is a problem, but I think we might be still be able to justify that change in 2.2.0 (Spring users are used to quite a lot of new stuff happening in first order releases, and no other Spring projects depend on Spring Batch, so no-one has to re-compile unless they are actually using Spring Batch). The source incompatibility is less of an issue because I think anyone already using "long" will find that equality assertions are the same when they recompile, as long as they stick to "long" and don't mix it up with the odd "Long" (123L==123L any day of the week). In any case 99% of Batch users do not code to the JobParameters API directly - they will be using SpEL - so most people really won't care.

          People

          • Assignee:
            Michael Minella
            Reporter:
            Ian Brandt
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: