java 6 compiler bug or ...

[Neal Gafter]

On Mon, Jun 6, 2011 at 5:41 PM, Dan Smith <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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110607/e7fe8dec/attachment.html