We're now seeing problems with Java tools on ppc64le as a result of this
decision not to give it a distinct arch name.

The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being
reported as the same; "ppc64". This leaves Java applications no way of
determining which of the two platforms the JDK is running on and, for example,
means that Maven can't determine which native JNI binaries to download.

There is a sun.cpu.endian property but this is non-standard and it seems
wrong to me that every Java tool should have to add a special case for
ppc64le using such a property. This value is traditionally not so much
just the architecture as a composite of the architecture, the bit size
and the endianness. The only difference with other platforms is that they
only support one default endianness so the value is implied e.g.
little-endian for amd64, big-endian for sparc. We do distinguish between
ppc and ppc64 rather than expecting tools to check sun.arch.data.model,
so we should do the same with endianness.

To add to the confusion, other JDKs are reporting it as ppc64le
(thanks to Tiago Sturmer Daitx for these results):

IBM Java 2.7 SR1
os.arch: ppc64le
sun.cpu.endian: little

GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2):
os.arch: ppc64le
sun.cpu.endian: null

whereas OpenJDK gives:

os.arch: ppc64
sun.cpu.endian: little

It also means that ppc64le is alone in not having a unique architecture
directory in jre/lib. I understand that a ppc64le machine is not going
to support ppc64be, but likewise amd64 is not going to support arm,
yet they have unique arch directories.

I've prepared a webrev which fixes the external facing architecture names,
LIBARCH and os.name, while leaving the HotSpot build architecture, BUILDARCH,
as it is, to avoid the duplication mentioned as a problem in the original
review.

http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/

This is against our IcedTea OpenJDK7-based HotSpot where we've been testing
but it should still be applicable to the 9 HotSpot repositories. The JDK side
is another issue and I suspect we'll need a completely different patch there
to the one we have for 7.