Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine

[Nikolay Gorshkov]

Hi Andrew,

I see your point that we chose a risky way and remember discussions
around
http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-December/002195.html
that we had in the past when the fix for OPENJDK6-35 was in review.

Well, my opinion is that this risk was taken when we decided to integrate
OPENJDK6-35. Unfortunately, we have consequences, and now we need to deal
with them. Luckily, the problem is known and resolved by a simple fix.
We have verified it by all available means and currently are not aware of
any other regressions. In my opinion, this approach (moving forward, fixing
regressions) is more preferable than moving to pre- JDK-6650759 state where
we had known incompatibilities.

Thanks,
Nikolay

On 10.12.2014 15:31, Andrew Haley wrote:
> On 12/10/2014 12:06 PM, Nikolay Gorshkov wrote:
>> Please, review the fix for
>> OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45
>> compiles fine
>>
>> This is a regression of the fix for OPENJDK6-35 (which is a backport of
>> JDK-6650759 to OpenJDK 6). In OpenJDK 7 this regression existed too -
>> it was tracked as
>> JDK-6938454: Unable to determine generic type in program that compiles under Java 6
>> The solution is to backport the fix for JDK-6938454 to OpenJDK 6.
>> The backport is small and straightforward, but not identical to the original
>> fix - the changes related to "diamond" operator support are not applicable
>> to OpenJDK 6.
>>
>> The practical reason for this fix is that currently OpenJDK 6 fails to compile
>> Apache Flume 1.5.0, while Oracle Java 6 and 7 do the compilation successfully.
>>
>> Bug: https://java.net/jira/browse/OPENJDK6-40
>> OpenJDK bug: https://bugs.openjdk.java.net/browse/JDK-6938454
>> Webrev: http://cr.openjdk.java.net/~ikrylov/openjdk6bug40.langtools.webrev/
>>
>> Testing: builds on Windows and Linux, all regression tests for javac, building
>> Apache Flume 1.5.0.
>
> Ah, the bug that will never die.  Such changes have a very unfortunate
> history, and this one goes back over four years.
>
> The problem always comes down to the risk of breaking existing code.
> This has actually happened on at least one occasion when we "fixed"
> such a bug in order to compile an application server and other
> packages which have been very stable for a long time failed to build.
>
> See
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-December/002195.html
>
> So, is it better to take the risk that we'll break something else?  It
> was IMO a mistake to backport 6650759 to OpenJDK 6, but we are where
> we are.  How important is this fix?
>
> Andrew.
>