Compilers and Libraries used from the system

[Kelly O'Hair]

Historically the JDK distributed by Sun were built with a set of "build platforms",
that are quite old now, but will always be older releases.
This is done so that the resulting binaries run on as many platforms
as possible, and building on older platforms has provided the best chance
for that. Also, fewer builds often translates to lower overhead for
the release engineering and quality departments.

But using these older platforms has some serious problems, one of those is
that the compilers and libraries provided on those platforms aren't
ideal or are (were?) quite frankly unstable, unreliable, or unavailable.

The goal was to make it as easy as possible for the JDK image to install on
most Linux systems and just work, and work reliably. Without having to
install any additional OS packages or patches to a system.
Unfortunately some of the things we had to do need to be re-visited now,
especially as the formal "build platforms" get upgraded for JDK7, but
also with regards to OpenJDK. But we need to be very careful here.
Native libraries loaded in with a JVM can create a great deal of havoc,
and sometimes it is not horribly obvious why.
Just compiling a native library with some new gcc/g++ optimization
flag could introduce unstabilities, or using a shared library that
wasn't mapped&scoped and exposed an extern symbol that conflicted with some
other shared library or system call.

I'm not saying we shouldn't try and use more external instances of
libraries, just saying we need to be very careful and make sure that what
we use is secure, mapped&scoped, safe, reliable, and always available.

-kto