ResolveVisitor improperly marks generics types as being resolved when sub-generics types haven't been resolved, leading to classes being generated that lack fully qualified generics typing and then subsequent errors while compiling against those generated class files. Here's an example:
If you compile this with the joint compiler and inspect ItemListList with javap, the type signature will be:
Note that Item type is not fully qualified (it should refer to a.Item), and if that class file is accessed during a later compilation (e.g., for an incremental compilation or a groovy server page), an exception with a stack trace similar to the following will be thrown:
The problem is that ResolveVisitor marks a GenericsType as resolved iff the type (i.e., ClassNode) has been resolved, but ignores any failure to resolve any generic types associated with the generic type itself. To use the example above, when resolving List<List<Item>> it first attempts to resolve the generic type List<Item>. It successfully resolves List to java.util.List, but isn't yet able to resolve Item to a.Item, as a star import is used and the java-compiler stage of joint compilation has yet to run, so a.Item is unavailable for classloader-based resolution in resolveToOuter to occur. Nonetheless, it incorrectly marks List<Item> as resolved, as it only checks that the primary type was resolved. A later attempt at resolution occurs after the java compilation, at which time an attempt to resolve Item would work since a/Item.class now exists, but no re-attempt is made at this time to resolve the GenericType as it had already been marked as being resolved. The solution is simple: only mark a GenericType as resolved if both its type and any genericsTypes it has are resolved.
Pull request is at https://github.com/groovy/groovy-core/pull/408
It's possible that this bug was responsible for