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.
