[#GROOVY-2773] Strange behaviour when passing chained methods (methodA().methodB().etc()) as parameters

groovy

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

Created: 24/Apr/08 04:57 AM Updated: 13/May/08 05:39 AM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

1.5.7, 1.6-beta-2

Time Tracking:

Not Specified

File Attachments:	1. groovybug.tar.gz (165 kb)
Environment:	Ubuntu Gutsy Gibbon

Testcase included:

yes

Description

« Hide

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

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Jochen Theodorou - 24/Apr/08 05:36 AM

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?

[ Permlink | « Hide ]

Stephen Cresswell - 08/May/08 01:02 AM

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

[ Permlink | « Hide ]

Stephen Cresswell - 08/May/08 01:03 AM

Attachment for previous comment

[ Permlink | « Hide ]

Jochen Theodorou - 08/May/08 01:28 PM

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

[ Permlink | « Hide ]

Stephen Cresswell - 08/May/08 01:57 PM

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.

[ Permlink | « Hide ]

Paul King - 12/May/08 10:55 PM

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.