java 6 compiler bug or ...
forax at univ-mlv.fr
Tue Jun 7 15:17:24 PDT 2011
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.
* compared to other rules related to generics.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev