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