groovy

Strange behaviour when passing chained methods (methodA().methodB().etc()) as parameters

Details

  • Type: Sub-task Sub-task
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Ubuntu Gutsy Gibbon
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

import org.joda.time.DateTime
import static org.joda.time.DateTimeZone

class EWUtils {
      static DateTime nowUTC() {
              return new DateTime(UTC)
      }
}

//Inside a test case
import static EWUtils.nowUTC
...
DateTime baseDate = nowUTC()
println "${baseDate.minusWeeks(1)} ${baseDate.minusWeeks(1).millis}"
println "${nowUTC().minusWeeks(1)} ${nowUTC().minusWeeks(1).millis}"

// The output
2008-04-16T18:40:09.698Z 1208371209698
2008-04-16T18:40:09.709Z 1208976009709

The second println statement demonstrates the bug. The epoch time is approximately equal to the current time instead of being a week old as in the first example.
The bug only manifests when nowUTC() belongs to another class - if I move it into the same class as the test it's OK

  1. GZip Archive
    groovybug.tar.gz
    08/May/08 1:03 AM
    165 kB
    Stephen Cresswell

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

the output is not very clear, but I thin I get it now. 1208371209698 is the time in millis for 2008-04-16T18:40:09.698Z, which is correct. 1208976009709 is not the same date, it is a date one week (and a few millis) in the future.

Only... I have problems reproducing this issue. Which version of Groovy did you use? Can you give an example that uses no external lib?

Show
blackdrag blackdrag added a comment - the output is not very clear, but I thin I get it now. 1208371209698 is the time in millis for 2008-04-16T18:40:09.698Z, which is correct. 1208976009709 is not the same date, it is a date one week (and a few millis) in the future. Only... I have problems reproducing this issue. Which version of Groovy did you use? Can you give an example that uses no external lib?
Hide
Permalink
Stephen Cresswell added a comment -

Sorry it's taken so long. Have finally found time to reproduce in isolation (and with a proper test case this time).
We're using grails 1.0.2 which ships with groovy 1.5.4
Also fails on OSX 10.x

see

/test/unit/example/UtilsTest in the (soon to be) attached

Show
Stephen Cresswell added a comment - Sorry it's taken so long. Have finally found time to reproduce in isolation (and with a proper test case this time). We're using grails 1.0.2 which ships with groovy 1.5.4 Also fails on OSX 10.x see /test/unit/example/UtilsTest in the (soon to be) attached
Hide
Permalink
Stephen Cresswell added a comment -

Attachment for previous comment

Show
Stephen Cresswell added a comment - Attachment for previous comment
Hide
Permalink
blackdrag blackdrag added a comment -

but if it is a problem that happens only within Grails, wouldn't it be then a Grails bug?

Show
blackdrag blackdrag added a comment - but if it is a problem that happens only within Grails, wouldn't it be then a Grails bug?
Hide
Permalink
Stephen Cresswell added a comment -

I only said I'm using grails and therefore the version of groovy is 1.5.4. I never said the problem only occurs with grails. In fact if you look at the attached source there's nothing remotely grails dependent in the example. It's just two groovy classes and a test case that extends GroovyTestCase.

Show
Stephen Cresswell added a comment - I only said I'm using grails and therefore the version of groovy is 1.5.4. I never said the problem only occurs with grails. In fact if you look at the attached source there's nothing remotely grails dependent in the example. It's just two groovy classes and a test case that extends GroovyTestCase.
Hide
Permalink
Paul King added a comment -

This script (reworking of attached) reproduces the problem:

class DateTime {
    long millis
    DateTime() { millis = new Date().getTime() }
    DateTime(long millis) { this.millis = millis }
    DateTime minusWeeks(Integer numWeeks) {
        return new DateTime(millis - (1000 * 60 * 60 * 24 * 7 * numWeeks))
    }
}

class Utils {
    static nowUTC() { return new DateTime() }
}

import static Utils.nowUTC

DateTime baseDate = Utils.nowUTC()
Long now = new Date().getTime()
Long lastWeekFromBaseDate = baseDate.minusWeeks(1).millis
Long lastWeekInline = Utils.nowUTC().minusWeeks(1).millis
assert now > lastWeekFromBaseDate, "Should have passed"
assert now > lastWeekInline, "Here's the bug"

Commenting out the import static line and the code works fine. The code isn't using the static import so that both variations should work with just the one line change but the behavior is the same in both cases.

Show
Paul King added a comment - This script (reworking of attached) reproduces the problem: class DateTime { long millis DateTime() { millis = new Date().getTime() } DateTime( long millis) { this .millis = millis } DateTime minusWeeks( Integer numWeeks) { return new DateTime(millis - (1000 * 60 * 60 * 24 * 7 * numWeeks)) } } class Utils { static nowUTC() { return new DateTime() } } import static Utils.nowUTC DateTime baseDate = Utils.nowUTC() Long now = new Date().getTime() Long lastWeekFromBaseDate = baseDate.minusWeeks(1).millis Long lastWeekInline = Utils.nowUTC().minusWeeks(1).millis assert now > lastWeekFromBaseDate, "Should have passed" assert now > lastWeekInline, "Here's the bug" Commenting out the import static line and the code works fine. The code isn't using the static import so that both variations should work with just the one line change but the behavior is the same in both cases.

People

  • Assignee:
    Unassigned
    Reporter:
    Stephen Cresswell
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: