The following code
public class GenericsTest2 {
public static void main(String[] args) throws Exception {
Integer i = readObject(args[0]);
System.out.println(i);
}
public static <T> T readObject(String file) throws Exception {
return readObject(new ObjectInputStream(new FileInputStream(file)));
// closing the stream in finally removed to get a small example
}
@SuppressWarnings("unchecked")
public static <T> T readObject(ObjectInputStream stream) throws Exception {
return (T)stream.readObject();
}
}
compiles in eclipse, but not with javac (type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,java.lang.Object).
When I change readObject(String file) to
@SuppressWarnings("unchecked")
public static <T> T readObject(String file) throws Exception {
return (T)readObject(new ObjectInputStream(new FileInputStream(file)));
}
it compiles in eclipse and with javac. Who is correct, the eclipse compiler or javac?
I'd say it's the bug in the Sun compiler reported here and here, because if you change your line to the one below it works with both, which seems to be exactly what is described in the bug reports.
return GenericsTest2.<T>readObject(new ObjectInputStream(new FileInputStream(file)));
In this case, I'd say your code is wrong (and the Sun compiler is right). There is nothing in your input arguments to readObject
to actually infer the type T
. In that case, you're better off to let it return Object, and let clients manually cast the result type.
This should work (though I haven't tested it):
public static <T> T readObject(String file) throws Exception {
return GenericsTest2.<T>readObject(new ObjectInputStream(new FileInputStream(file)));
}
Oracle JDK6 u22 should be correct but I've this problem with JDK6 u24 too
This is a bug of eclipse bug 98379.
This was not corrected but the problem is resolved via workaround like example in eclipse bugs (see link)
I found this issue in java version "1.6.0_22". It disappeared when I upgraded to java version "1.6.0_32" as it was fixed in update 25.
If you can modify your method readObject to work transparently when called, you may also use following:
public static <T> T readObject(String file, Class<T> type) throws Exception {
return type.cast(readObject(new ObjectInputStream(new FileInputStream(file))));
}
This way, caller is forced to specify the type of the result and compiler knows how to cast the result.