java 6 compiler bug or ...

Rémi Forax forax at univ-mlv.fr
Mon Jun 6 15:58:06 PDT 2011


I agree with Neal, the spec should be fixed not the implementation.

On 06/06/2011 05:10 PM, Neal Gafter wrote:
> That doesn't make sense as a fix.  The reason for this error message 
> is to enable compiling generics via erasure, but methods with return 
> types whose erasures differ don't have VM signatures that conflict.  
> One would think that maintaining backward compatibility is more 
> important that mindless compliance with a specification that matches 
> no previous implementation. 

In fact, it matches Eclipse JDT implementation.

> Wouldn't it make more sense to fix the specification to allow what 
> makes sense to allow rather than break compatibility?

Rémi

>
> On Mon, Jun 6, 2011 at 3:07 AM, maurizio cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     On 06/06/2011 09:31, Ali Ebrahimi wrote:
>     > Hi all,
>     >
>     > This test case compiles with java 6 compiler, but current
>     compiler rejects
>     > that.
>     >
>     > public class Test {
>     >
>     >      static Integer call(List<String>  ls) {
>     >          System.out.println("ls");
>     >          return 0;
>     >      }
>     >
>     >      static void call(List<List<String>>  lls) {
>     >          System.out.println("lls");
>     >      }
>     >
>     >      public static void main(String[] args) {
>     >
>     >      }
>     > }
>     >
>     > current compiler error message:
>     > error: name clash: call(List<List<String>>) and
>     call(List<String>) have the
>     > same erasure
>     >
>     > Best Regards,
>     > Ali Ebrahimi
>     >
>     Hi Ali,
>     this is a JDK 6 bug that has been fixed in JDK 7 - as a result of a
>     merge, the lambda compiler picked up that fix.
>
>     Maurizio
>
>
>



More information about the lambda-dev mailing list