PATCH: Tired of waiting for rt.jar to build?

Andrew John Hughes gnu_andrew at
Thu Sep 10 15:17:01 UTC 2009

2009/9/10 Martin Buchholz <martinrb at>:
> Hi Andrew,
> I don't recall all the details, but I probably backported all-at-once
> because it was a little easier for me to do so - it reflected the
> engineering that was actually done.   I care more about
> the quality of the openjdk7 mercurial history.  In this case
> the information *is* available to allow a future maintainer
> to do archaeological investigations.  I agree it would have
> been a little cleaner to backport each change individually.

Yeah, the OpenJDK6 version history is already a complete mess, so I
don't suppose it makes that much difference :)
Neither are ideal because everything before b24 is missing from OpenJDK7 too.

The problem was more that this was never mentioned in the thread, so
we didn't pick up on this until Andrew Haley spotted it today.  I
remember reading the thread at the time, but because there was no
apparent conclusion publicly, I missed out on it actually being
committed and wasn't just another patch in a big pile of pending

> You also correctly notice that not all discussions end up
> on core-libs-dev.  In part this is a cultural heritage - tradition
> is private, not public, peer review.  I have been trying,
> and have been encouraging others, to make discussions
> more public, even when we might perceive them to be
> uninteresting to others.  (What can be said about a backport,
> except whether it's worth doing, one might think.)
> Thanks for the culture change prodding.

I'm aware of this endemic culture at Sun (see, and I
very much appreciate your efforts to do things publicly.  Believe me,
it hasn't gone unnoticed, and the prodding was aimed more at the
authors of the missing messages in that thread... :)

FWIW, I'm pretty sure I'm not alone in saying I'd much prefer to
receive these 'uninteresting' mails.  There are plenty of mailing
lists and mail filters to allow us to cherry-pick what we want to
read, but we can't recreate missing e-mails.

> Martin
> On Thu, Sep 10, 2009 at 06:01, Andrew John
> Hughes<gnu_andrew at> wrote:
>> 2009/4/29 Martin Buchholz <martinrb at>:
>>> Since writing this, I have learned, to my horror, that the
>>> behavior of the -C flag differs from the behavior in tar in that
>>> - -C is not sticky - it applies only to the one following argument
>>> - the path is relative to the JDK's current directory, not the
>>> previous -C directory.
>>> despite assurances from jar(1)
>>>          -C  dir
>>>             Temporarily changes directories (cd dir) during execution of the
>>>             jar command while processing the following inputfiles argument.
>>>             Its operation is intended to be similar to the -C option of the
>>>             UNIX tar utility.
>>> If you squint, you can see that it says "argument", not "arguments".
>>> Martin
>>> On Mon, Apr 27, 2009 at 17:54, Martin Buchholz <martinrb at> wrote:
>>>>  I believe the better fix would be
>>>> to eviscerate the code that handles the "-C" flag and do it right,
>>>> Someone who cares about the Makefiles can also try to remove the
>>>> 16000 gratuitous -C flags that makes jar's life "jar hell".
>>>> Martin
>> Martin,
>> Thanks a lot for this patch.  We've seen good speedups with it applied.
>> The thread here reads very strangely; did a number of mails go to a
>> different mail list or only to private mail addresses?
>> There's also seems to be no mention of this being applied to OpenJDK6:
>> That changeset seems to have been merged together with several others;
>> was there a reason the changesets were not imported individually so as
>> to retain the history?
>> Thanks,
>> --
>> Andrew :-)
>> Free Java Software Engineer
>> Red Hat, Inc. (
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> PGP Key: 94EFD9D8 (
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (

Support Free Java!
Contribute to GNU Classpath and the OpenJDK

PGP Key: 94EFD9D8 (
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the core-libs-dev mailing list