java 6 compiler bug or ...

[Dan Smith]

As background, this kind of thing comes up all the time in addressing bug reports.  The typical process is: 1) observe a discrepancy between javac and the JLS, where neither is clearly in error; 2) try to characterize what javac is actually doing; 3) see what Eclipse does; 4) Compare the specified and implemented behavior, and try to find a minimally-invasive way to reconcile them.

Frequently, the solution is as simple as changing a line in the JLS.  Sometimes, the solution is a source-incompatible implementation change.  There are costs in both directions, and we try to balance those costs appropriately.  Of course this process is subjective, but it is also reasonably careful, I think.

I misread Remi's comment about Eclipse, but that observation was probably influential in this particular case: javac was accepting programs that both the JLS and Eclipse considered malformed.

—Dan

On Jun 6, 2011, at 3:58 PM, Rémi Forax wrote:

> 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> 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
>> 
>> 
>> 
>