/hg/icedtea: 2 new changesets

[Andrew John Hughes]

2009/10/28 Matthias Klose <doko at ubuntu.com>:
> On 29.10.2009 00:04, andrew at icedtea.classpath.org wrote:
>>
>> changeset 853eaa194f9a in /hg/icedtea
>> details:
>> http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=853eaa194f9a
>> author: Andrew John Hughes<ahughes at redhat.com>
>> date: Wed Oct 28 22:42:45 2009 +0000
>>
>>        One jar to rule them all and simplify the build.
>>
>>        2009-10-28 Andrew John Hughes<ahughes at redhat.com>
>>
>>        * Makefile.am: Have one jar to rule them all
>>        (rt.jar) and make others (tools.jar, rt-closed.jar)
>>        symlinks to it. Remove the hotspot-tools target and do all
>>        patching, etc. prior to building rt.jar. Use zip rather
>>        than jar to update rt.jar for efficiency.
>
>  - did you check that the increase in size still allows bootstrapping
>   using gcj on more uncommon architectures, and that the memory
>   footprint doesn't change too much to the worse?

I don't have an uncommon architecture to check on, but I think we're
being exceptionally kind to the current build if we're saying that's
why it's in the mess it's in.  I think the more accurate depiction is
that we still have cruft from the old days of having to fake binary
plugs that's since built up further every time we need to work around
a build problem.  If we do see problems with the new single jar on
some platforms, I'd rather fix that issue than keep the current status
quo.  The situation of having multiple jars with different bits and no
coherent picture is what I believe lead to your failure with cacao
and, more importantly, me not being able to replicate it.   Likewise,
I think it's also why the test builder was failing with missing
classes.  Do we really want something where none of us have a clue
what's going on?

All that said, I don't think the size increase is particularly huge.
We're adding some Sun classes to the existing rt.jar, not the whole of
OpenJDK (and ones that are required, discovered through a number of
build runs).  The long term fix is twofold:

1.  For API classes, things need to be fixed in gcj et. al.  I don't
think that's as major as it sounds.  There aren't that many issues and
I've filed bugs for most of them under a metabug of building OpenJDK.
We already disable Nimbus for the bootstrap which avoids many of them.
2.  For the Sun classes, the upstream build should be using the code
from the JDK being built as a reference, not relying on the (unknown)
versions in the boot JDK.  That's a bug and one that leads to
bootstrapping issues with OpenJDK.  For example,. an API may change
and no-one notices it's relevant to the build because everyone
bootstraps with the previous JDK.  That's definitely not unlikely; it
happened only this week with Roman's refactoring of FontManager and it
was IcedTea that caught it.

We also build this stuff even when building with OpenJDK.  Another
thing on the TODO list is to check for com.sun classes in the build
JDK and skip this rt.jar update altogether if they are present.  All
such a build should do other than building OpenJDK is patch the tree
and build our extra features (plugin, netx, visualvm, pulse-java,
cacao, etc.)  It shouldn't be building a heap of OpenJDK classes ahead
of time which aren't used.

>  - we already have the option to configure with fastjar, why change
>   that to an explicit dependency on zip? (No, I don't care that much).

We're already bringing in zip; always have, it's needed by OpenJDK as
far as I'm aware.  So why not use it?  As you know from adding the
fastjar option, a native binary is going to be faster than doing it
with Zero and it's not like we need anything to do with the manifest.
I've only covered one case with this patch (the new code) but I do
intend to replace some of the others in 7.  Eventually, I hope to get
a lot of this into 6 too.

>
> Matthias
>

Cheers,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8