[GROOVY-5006] Inappropriate transformation of type from int to BigDecimal

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 1.8.2, 1.9-beta-3
• Fix Version/s: 1.8.3, 1.9-beta-4
• Environment: Debian Testing; Groovy trunk fdf212623511fce9d47d3d8ab3954a709d70583f
• Assignee: Jochen Theodorou
• Reporter: Dr. Russel Winder
• Created: 09/Sep/11 06:41
• Updated: 09/Sep/11 11:20
• Resolved: 09/Sep/11 09:24

Description

In Groovy 1.8.1 the following code compiles fine and runs fine. Fine here means hanging forever with no output.

@Grab ( 'org.codehaus.gpars:gpars:0.12' )

import groovyx.gpars.group.DefaultPGroup

final int n = 1000000000i
final int actorCount = 1
final int sliceSize = n / actorCount // The division expression here is crucial to observing the problem.
final group = new DefaultPGroup ( )
final accumulator = group.messageHandler { }
final computors = [ ]  
assert sliceSize.class == Integer
for ( index in 0 ..< actorCount ) {
  assert sliceSize.class == Integer
  computors.add (
    //assert sliceSize.class == Integer // this statement causes a compilation error in the following statement ?????
    group.actor {
      assert sliceSize.class == Integer
    }
  )
}
accumulator.join ( )

Using 1.8.2 or Groovy trunk with the SHA1 given above, this results in:

An exception occurred in the Actor thread Actor Thread 2
Assertion failed:

assert sliceSize.class == Integer

1000000000| false
class java.math.BigDecimal

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:385)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:658)
at alt$_run_closure2.doCall(alt.groovy:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:882)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at alt$_run_closure2.doCall(alt.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:882)
at groovy.lang.Closure.call(Closure.java:410)
at groovy.lang.Closure.call(Closure.java:404)
at groovyx.gpars.actor.DefaultActor.handleStart(DefaultActor.java:336)
at groovyx.gpars.actor.AbstractLoopingActor$1.handleMessage(AbstractLoopingActor.java:70)
at groovyx.gpars.util.AsyncMessagingCore.run(AsyncMessagingCore.java:132)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

it then also hangs forever, but in this case that can be considered normal and correct.