Actually, it may be a second bug. I'm tired and am ready to give up for the day.

-- Sean

On 9/10/15 1:30 PM, Sean Gilligan wrote:
Adding 'L' produces the same result. I actually discovered this issue a while back and even wrote some unit tests for it (see link in my previous email). It's embarrassing that I didn't recognize it immediately.

I wish I had the time and ability to submit a fix.

-- Sean

On 9/10/15 1:26 PM, wrote:
Try adding L to your long constants.
I ran into a similar problem the other days where my calculation of date difference in milliseconds produced an overflow and a negative number.

assert 100000000000000016L == (({ BigDecimal it -> it})(100000000000000010L))

On 10 September 2015 at 22:15, Sean Gilligan <> wrote:
A one line assert which PASSES and shouldn't:

assert 100000000000000016 == (({ BigDecimal it -> it})(100000000000000010))

More detail (all asserts pass):

def val = 100000000000000010
assert val.class == Long
def closure = { BigDecimal it -> it}
def bdVal = closure(val)
assert bdVal.class == BigDecimal
assert bdVal == 100000000000000016
def bdCastVal = (BigDecimal) val
assert bdCastVal.class == BigDecimal
assert bdCastVal == 100000000000000010

So, converting to BigDecimal with a cast or with an `as` seems to work.
But having Groovy do it automatically for a function or closure
parameter fails.

Am I missing something? Is this a known issue?