Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional

Andrew John Hughes gnu_andrew at
Fri May 15 15:30:04 UTC 2009

2009/5/15 Mark Reinhold <mr at>:
>> Date: Thu, 14 May 2009 23:31:58 +0100
>> From: Andrew John Hughes <gnu_andrew at>
>> 2009/5/14 phil.race at
>>> I do think I know what you want. But I consider its a slippery slope as
>>> you have no way of knowing or keeping track of the consequences of
>>> not building a particular component.
>> Sure, but if someone chooses to set DISABLE_NIMBUS then they take that
>> risk.  It's much the same as if they turn on insane mode or don't
>> build the docs.  It's a tradeoff of having an incomplete build at the
>> end against simplifying the process, and one it is down to the user to
>> make.  For example, if someone wants to build OpenJDK as a precursor
>> to hacking on HotSpot, then they are probably more concerned about
>> just completing the build than finding an additional set of
>> dependencies for a look and feel they probably won't use.  I don't see
>> how arbitrarily restricting choice helps anyone.
>>> I suggest its better to fix the local build problem than push workarounds
>>> upstream.
>> My fear is we will run over this problem again and again.  If people
>> working on OpenJDK day in and day out are having issues with this,
>> then newbies are going to fare even worse.
> I have to agree with Andrew on this one.
> Engineers working on the JDK routinely skip building various components,
> yet somehow we've survived.  When was the last time, e.g., you built
> HotSpot, or javac, or the Windows installer, or generated rpm packages on
> Linux?
> There are already lots of ways to disable various components of the
> build.  The better ones take care to issue a warning during the sanity
> check so that people who carelessly set build variables in their shell
> environment don't get tripped up too badly, as long as they make sure to
> read the sanity log.
> That these happen to be "platform" classes doesn't mean much.  The chance
> that a Nimbus-disabled build would be mistaken for a product build is
> pretty well near zero, given all the testing that we do.
> If this tiny change makes it easier for people to work with our code,
> then I'm all for it.
> My only comment on Andrew's actual patch is that Sanity.gmk should be
> extended to print a warning when Nimbus is disabled.  It otherwise looks
> fine to me.

I was thinking this as I read your mail.  It should be easy enough to
add this as an #else clause to the existing patch in Sanity.gmk.
What's the best way to handle updating the patch, given that the
existing patch is a committed changeset?  Do I need to somehow revert
the changeset or is a pair of changesets feasible?

> Oh, and if we have somehow become dependent upon a third-party tool
> (JIBX) that's so difficult to locate and has such a low commitment to
> interface stability, then perhaps we should reconsider that and use a
> different tool.
> - Mark

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 build-dev mailing list