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 <lloyd...@gmail.com> 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.