On Saturday, June 2, 2012 4:59:33 PM UTC+2, Shawn Pearce wrote:
>
> On Fri, Jun 1, 2012 at 10:17 AM, Lloyd Chang <[email protected]>
> wrote:
> > Continuous Integration for Gerrit via Jenkins
> > at http://ci.jenkins-ci.org/job/gerrit_master/ has been broken since
> April
> > 21.
> >
> > Is this expected?
>
> Yes. That system has an older version of the Java compiler installed
> that contains a bug in its generics type handling that prevents it
> from correctly compiling the current Gerrit code.
>
AFAICT the build could easily be fixed by using explicit generic type
parameters instead of relying on inference.
The errors are:
[ERROR]
/home/jenkins/slave/workspace/gerrit_master/gerrit-gwtui/src/main/java/com/google/gerrit/client/rpc/RestApi.java:[127,34]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds
T,com.google.gwt.core.client.JavaScriptObject
[ERROR]
/home/jenkins/slave/workspace/gerrit_master/gerrit-gwtui/src/main/java/com/google/gerrit/client/rpc/Natives.java:[39,17]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds
T,com.google.gwt.core.client.JavaScriptObject
In the first case, it's on:
T data;
try {
data = Natives.parseJSON(json.substring(JSON_MAGIC.length()));
where parseJSON return type is a generic (see method signature below)
In the second case:
public static <T extends JavaScriptObject> T parseJSON(String json) {
// ...
return parse0(parser, json);
where parse0 is defined as:
private static native <T extends JavaScriptObject>
T parse0(JavaScriptObject p, String s)
Using Natives.<T>parseJSON and Natives.<T>parse0 would probably fix the
build.
