aph at redhat.com
Thu Jun 2 06:38:43 PDT 2011
On 06/02/2011 01:20 PM, Dr Andrew John Hughes wrote:
> On 12:40 Wed 01 Jun , Denis Lila wrote:
>> This bug will require a couple of backports:
>> The attached patch does this. It doesn't contain the regression
>> tests T6369605a.java and T6369605b.java because even after the
>> patch was applied these tests were failing.
>> I think this is ok though because they fail with ecj and
>> proprietary javac too. What's probably happening is that
>> they're assuming other changes in the compiler in addition
>> to the fix for 6369605.
>> I've attached three tests I wrote that were derived from
>> commons-discovery (whose compilation fails, as detailed
>> in the bug report). All three compile with ecj and proprietary
>> javac, but they fail with openjdk javac before this backport.
>> With the backport they compile.
>> I haven't tried compiling commons-discovery yet. I will
>> do that soon and give an update.
>> I ran the langtools regression tests, and there were no changes
>> in the results.
>> 2011-06-01 Denis Lila <dlila at redhat.com>
>> * Makefile.am: Apply patches.
>> * NEWS: Update with backports.
>> * patches/openjdk/6938454-generic-type.patch:
>> * patches/openjdk/6369605-unconstrained-type-vars.patch:
>> New patches. Compiler backports.
>> Is this good to go (contingent on commons-discovery compiling
>> The bug was reported against F14, so this should go into 1.9,
>> 1.10 and head. I would like to let it soak in head for a week
>> or two before I push to 1.9 and 1.10 though.
> I'd say put this in HEAD but leave the release branches. We can
> always back it out if it causes major problems.
The problem with this approach is that we won't know until HEAD becomes
a release branch for one of the distros. It might help to test with
some big programs that we know have had problems in this area, such as
More information about the distro-pkg-dev