David Holmes - Sun Microsystems wrote:
Andrew,
Andrew John Hughes said the following on 06/20/08 09:35:
I would hope one of the side effects of moving the JDK from a
proprietary to a community-based Free Software model would be that it
gets built, run and tested on a much wider range of platforms and
compilers. This has already started to happen.
Agreed - this is a good end goal. Meanwhile there are some
practicalities to address.
The reality is that people aren't going to download and build a
specific copy of GCC just for OpenJDK, and distros will certainly want
it to build with the GCC they use for everything else.
But are the Distros expecting/assuming that everything will work fine
with their version of GCC? Who is expected to have done the testing?
If something goes wrong who would be expected to fix it? Would the
Distros patch the OpenJDK code with a workaround for their GCC
version? Or would they grab a known working GCC version and rebuild
using that?
Right now the reality is that these alternate compiler versions have
not undergone extensive testing for the OpenJDK. Over time that will
hopefully change, but for now - caveat emptor!
Cheers,
David Holmes
While what Andrew says is true to a certain extent, I think it behooves
us to act as guides. Hotspot in particular is a _very_ complex piece of
code, and exercises (let's be honest, _stresses) a compiler far more
than virtually any other piece of software commonly available (the Xorg
stuff is probably the only comparable one in a standard Linux distro).
Consequently, it is very sensitive to bugs and changes in a compiler.
For large organizations (such as those managing a distro), it may make
sense to put in the effort to make sure their "standard" compiler works
with OpenJDK. It is none too difficult for even such an org to use a
different compiler, though.
For smaller companies and individuals, I think we (i.e. the community,
not just Sun), should _strongly_ encourage them to pick one of the
handful of "official" compilers, which are specified in the source
documentation. Downloading the appropriate compiler is trivial these
days (via Yum or apt-get), and it avoids a whole rash of problems.
Otherwise, folks get bogged down in trivial build problems (which, may
turn out to be non-trivial), rather than doing what they were intending
to do with the OpenJDK (which, is almost certainly not "adding support
for compiler X.Y.Z").
Certainly, we should pick compiler versions which are easily available,
and will remain so for several years.
While I love free software (in all its incarnations), one of the
problems with running a large project is trying to "herd cats" - that
is, setting appropriate boundaries and encouraging everyone to work
within those boundaries, rather than just a willy-nilly free-for-all.
In areas where it fruitful to push a boundary, the community should
encourage it. However, there needs to be some social pressure in a
community to discourage people from doing what I call the
"look-at-me-I'm-cool" hack - that is, something that looks neat and may
have been technically difficult or challenging, but really isn't useful
(and, in many cases, carries a burden of support by the community).
There is a non-zero cost to adding support to a codebase for any new
feature. What the community needs to do is say that "Doing XYZ costs
more than it is worth to community, so we will NOT accept XYZ".
While this originally started out as a discussion around GCC, it applies
to the other primary compilers currently used, i.e. SunStudio and Visual
Studio. I've run in considerable problems by applying a new Service
pack to a Visual Studio 2003 (or, previously, VC 6), as not only
bugfixes but behavior modifications are installed. Running down those
differences is a HUGE timesink. One which I think we should avoid if at
all possible.
Sometimes Freedom means you need to give up something to get something
else. In this case, I think the tradeoff is unlimited flexibility (use
whatever compiler you want) for maintainability. As I don't see any
real benefit not easily obtainable otherwise by allowing many different
compiler versions, I vote for maintainability as the more important feature.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
