[GROOVY-199] overriding an inherited method that has basic types in the signature is problematic

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 1.0-beta-4
• Fix Version/s: 1.0-beta-5
• Component/s: class generator, parser
• Environment: ArchLinux 0.6 w/ jdk 1.4.2_01
• Assignee: James Strachan
• Reporter: Chris Poirier
• Created: 17/Feb/04 02:39
• Updated: 12/May/04 08:01
• Resolved: 12/May/04 08:01

Description

Given the following java class:
class Base
{
public boolean doit( int value )

{ System.out.println( "In Base::doit( " + value + ") " ); return true; }

}

implementing a subclass in groovy that overrides doit() doesn't seem to work.

First up, the groovy class has to declare the method as
boolean doit( int value )
not
Boolean doit( Integer value )

This might seem obvious, but the basic types are not valid as identifiers elsewhere in groovy, so it probably requires some documentation. That or the basic type names should be accepted and treated as synonyms for the wrappers as necessary.

The following groovy class compiles:

class Test extends Base
{
public boolean doit( int value )

{ System.out.println( "In Test::doit( " + value + " )" ); return true }

public static void main( String[] args )
{
Base o = new Test()
result = o.doit( 9 )

if( result != null && result )

{ println( "returned true" ) }

else

{ println( "returned false" ) }

}
}

However, "java Test", dies with a VerifyError:
Exception in thread "main" java.lang.VerifyError: (class: Test, method: doit signature: (I)Z) Expecting to find object/array on stack

If the body of doit() is empty:
public boolean doit( int value )
{
}

"java Test" dies with a NullPointerException:
Exception in thread "main" java.lang.NullPointerException
at Test.doit(Test.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:324)
at groovy.lang.MetaClass.doMethodInvoke(MetaClass.java:765)
at groovy.lang.MetaClass.invokeMethod(MetaClass.java:214)
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:324)
at groovy.lang.MetaClass.doMethodInvoke(MetaClass.java:765)
at groovy.lang.MetaClass.invokeMethod(MetaClass.java:214)
at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:130)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:98)
at Test.invokeMethod(Test.groovy)
at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:117)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:98)
at Test.main(Test.groovy:22)

I haven't been able to coax it to run long enough to find out what would happen on a call to "super( value )".