java 6 compiler bug or ...

[Rémi Forax]

On 06/07/2011 04:02 PM, Neal Gafter wrote:
> On Mon, Jun 6, 2011 at 5:41 PM, Dan Smith <daniel.smith at oracle.com 
> <mailto:daniel.smith at oracle.com>> wrote:
>
>     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.
>
>
> Having followed this kind of process as maintainer of javac and 
> contributor to the JLS for some years, I am quite familiar with the 
> process.  In step (2), what javac used to be doing was quite 
> straightforward (the rule about conflicting methods also takes into 
> account the erasure of the return type).  The backward-compatible and 
> least-invasive (to the customer) way to fix it is obviously to add a 
> line in the JLS and relax the Eclipse implementation.  I cannot 
> imagine what considerations would lead to the current result (other 
> than, perhaps, that the JLS maintainer is too busy to make the 
> necessary change to the specification).

Dan, again, I agree with Neal:
   - if two erased methods with different return types can create a 
clash, I need to understand why.
     (I think it's better to understand JLS rules than memorize them all :)
  - it's not a source compatible change.

So why introducing a source incompatible change that blurs a restriction 
(name clash) which is easy* to understand.
I am interested to have an explanation.

Rémi
* compared to other rules related to generics.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110608/673eaa15/attachment.html