Specification Question

[Maurizio Cimadamore]

Hi Richard
This is a specification problem - type-inference (as specified in the 
JLS) cannot derive any useful constraint from int >> T - autoboxing is 
currently only applied in argument position. We have a bug for this:

http://bugs.sun.com/view_bug.do?bug_id=6785114 (return type-inference doesn't work with autoboxing)


Maurizio


Richard Warburton wrote:
> I have noted a difference between SUN javac and ecj for a given program:
>
> package tree;
>
> public class Fail {
> 	static <T> T t() { return null; }
>
> 	public static void main(String[] args) {
> 		boolean b = t();
> 		System.out.println(b);
> 	}
> }
>
> This fails type checking in javac [0]:
>
> Fail.java:6: type parameters of <T>T cannot be determined; no unique
> maximal instance exists for type variable T with upper bounds
> boolean,java.lang.Object
> 		boolean b = t();
> 		             ^
> 1 error
>
> Under eclipse [1] it compiles, and then throws the runtime error.
>
> Exception in thread "main" java.lang.NullPointerException
>    at tree.Fail.main(Fail.java:7)
>
> By my reading of the program, SUN javac is applying a capture on <T>
> to boolean, and then realising there's no common subtype between
> boolean and java.lang.Object, thus provides a compile error.  ECJ
> appears to infer that java.lang.Boolean is a valid subtype of
> java.lang.Object, and then apply unboxing to convert to boolean.
> Throwing an exception appears correct to me under section 5.1.8 of JLS
> v3.
>
> I've skim read appropriate parts of JLS and I'm not sure which of
> these behaviours corresponds to a correct JLS interpretation?  Is this
> a javac bug, or an ecj bug?  Thanks for any help on the matter,
> apologies if this question has already been asked somewhere.
>
> regards,
>
>   Richard Warburton
>
> [0] From 1.6 release 16
> [1] Galileo release
>