Not able to use variables defined in classes within groovy annotations

Question

I am trying to port some code from the Dropwizard examples from java to groovy.

I see that within java, I can use the following code without any issues:

package com.example.helloworld;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;

@Produces(MediaType.APPLICATION_JSON)
public class HelloWorldService{  

}

However, with the groovy compiler ( both 1.8 and 2.0.6 ), the class fails to compile with a noClassFoundException around MediaType.APPLICATION_JSON

If I change this code to use the actual string value

@Produces('application/json')
public class HelloWorldService{  

}

everything works perfectly.

Are there any differences between the way groovy resolves annotations and the way that java does?

For completeness, this is part of a gradle project and here is my build.gradle ( the file goes under src/groovy/com/example/helloworld )

apply plugin: 'groovy'

// Set our project variables
project.ext {
    dropwizardVersion = '0.6.1'
}

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'com.yammer.dropwizard', name: 'dropwizard-core', version: dropwizardVersion
    groovy group: 'org.codehaus.groovy', name: 'groovy-all', version: '1.8.7'
}

The compilation error is:

Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl ... 17 more Caused by: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl at org.gradle.api.internal.tasks.compile.TransformingClassLoader.findClass(TransformingClassLoader.java:47)

Answer 1

The problem is caused by an unfortunate limitation of the Groovy compiler, namely that it uses reflection to access classes on the compile class path. This may in turn trigger other classes to get loaded, which may not be available on the compile class path. Typically (but not always) these are runtime dependencies.

In the concrete case, the Groovy compiler loads javax.ws.rs.core.MediaType via reflection, which ultimately results in com.sun.ws.rs.ext.RuntimeDelegateImpl being loaded via Class.forName (triggered by a static initializer), which isn't on the compile class path. The solution is to put that class on the compile class path. (In the longer run, the solution is to fix the standalone Groovy compiler not to use reflection, and from what I know this is already in the queue.) If your module's transitive dependencies aren't an issue, the simplest way to achieve this is:

dependencies {
    compile "com.sun.jersey:jersey-client:1.15" 
}

I suspect that the Eclipse Groovy compiler doesn't have this problem because it doesn't use reflection to access the compile class path. I'd expect GMaven to blow up like Gradle, unless it is configured to use the Eclipse compiler (which isn't currently supported by Gradle).