covariant return types means usually to have two method withe the same name and the same parameter types, but diefferent return types. Groovy does support this already:

class A{
void foo(){}
Object foo(){}

}

A.class.declaredMethods.each{println it}

and you get:
public void A.setProperty(java.lang.String,java.lang.Object)
public java.lang.Object A.getProperty(java.lang.String)
public java.lang.Object A.invokeMethod(java.lang.String,java.lang.Object)
public groovy.lang.MetaClass A.getMetaClass()
public void A.setMetaClass(groovy.lang.MetaClass)
static java.lang.Class A.class$(java.lang.String)
public void A.foo()
public java.lang.Object A.foo()

there are 2 foo methods, so the methods are there. To do it like java means to let one of it redirect to the other automatically. This part is missing, yes.

btw, you can only call only one of these methods!

ah - there's a problem though:

abstract class Numeric {
abstract Numeric eval();
}

class Rational extends Numeric {
Rational eval() {
this
}
}

this would have Groovy complaining that eval() in Numeric is not implemented

I think, to fully support this we have to generate 1.5 bytecode. We decided not to do this before 1.0, so this does have to wait. After 1.0 we will have to discuss how we support generics.

Please note that even if Groovy decides to ignore generics because it is already a dynamically typed language, it is still important that it generate the correct 1.5 generics bytecode, including all the generics metadata.

Even after erasure, there is still a good deal of generics metadata present in the bytecode of Classes, Methods and Fields, and many significant frameworks (JPA, Spring) depend on this.

A prominent use case would be trying to define an EJB3 entity bean using GroovyBeans...

@Entity
class Foo
{
@OneToMany
Set<Bar> bars;
}

...it is important that groovyc maintain the generics information when it compiles the class.

Here is an example of useful inheritance of Generics, including test case. drop it in src/test/groovy/tiger
As Kennard pointed out, it's something important to achieve a friendly integration with JavaEE and their frameworks, esp JPA

as commented in GROOVY-1860 a bigger refactoring is needed here, so I will have it postponed to beta-3

fixed