New CPU & OS Platform System Properties Updated

Bob Vandette bob.vandette at
Tue Feb 12 08:52:20 PST 2013

I've withdrawn my request to add a new os.variant.  We'll just set to Android.

I will use sun.arch.abi to identify platform specific ABI differences.


On Feb 12, 2013, at 11:16 AM, mark.reinhold at wrote:

> (cleaning up old threads ...)
> 2013/1/23 10:00 -0800, bob.vandette at
>> On Jan 23, 2013, at 11:38 AM, mark.reinhold at wrote:
>>> 2013/1/10 10:59 -0800, bob.vandette at
>>>> Thanks for all the input.  Here's an update to the proposal based on the
>>>> feedback I've received so far.
>>>> -----------------------------
>>>> ...
>>>> The only remaining problem is that of ABI.  For this I propose the
>>>> addition of a single new property.
>>>> os.arch.abi 
>>> This makes sense, but since you're not proposing to add this new property
>>> to the Platform Specification [1] its name should start with "jdk." or
>>> "sun.".  Current convention would be to use "jdk.", but given that the
>>> names of existing closely-related properties already start with "sun."
>>> (, etc.), this new property should be named
>>> "sun.arch.abi".
>> Ok, I can live with sun.arch.abi.    It's a shame we can't easily move these
>> to oracle.arch.* but that's for another CCC.
> Even if we could, we'd never rename these to oracle.arch.*.  They are in
> no way Oracle-specific.
>>> Will this property be defined for regular Linux, Mac OS, or Windows
>>> builds?
>> I was not planning on adding this property for any platform where the
>> abi does not vary within the same cpu family or where ABI changes are
>> already covered by previously available properties.  For example,
>> there's no need to distinguish 32 and 64 bit x86 ABIs since we have an
>> endian property that provides that distinction.
> Okay.
>>>> -----------------------------
>>>> My proposal below for stands with the exception of Apple
>>>> platforms.  For iPhone and iPad Java implementations, we will be
>>>> setting to "iOS" since Apple informed me that there is really
>>>> no concrete specified relationship between OSX and iOS.  They are two
>>>> very distinct OS platforms and should be treated as such.
>>>> I would still like to propose os.variant and os.variant.version for
>>>> Android.
>>> I don't think it makes sense to describe Android as a variant of Linux.
>>> Sure, it's built on top of a Linux kernel, but the rest of the
>>> environment is vastly different from the typical Linux distro where
>>> "" currently has the value "Linux".
>>> In short form, Linux : Android :: Mac OS : iOS.
>>> The "" property should have the value "Android" on Android
>>> devices, and "os.version" should be the Android version number.
>>> Given that, I don't see a compelling need to introduce "os.variant"
>>> properties at this time.
>> Here's the justifications that I have to support this addition:
>> 1. It would avoid adding a lot of " || == "Android" in several
>> places in the JDK and application sources where the code currently
>> check for "Linux" resulting in faster execution and less maintenance.
> Saving a few lines of code and a few conditional tests in the JDK source
> code really doesn't buy much.
> As to application code, I think calling Android a "Linux" will actually
> require existing code to change if and when it's run on the JDK in an
> Android environment.  Code that tests the value of in order to
> construct a string that's then passed to Runtime.exec on a real Linux
> system will not work on Android -- it will have to be augmented also to
> test os.variant, and to do something else.
>> 2. OpenJDK community feedback.  Mike Swingler from Apple agrees with my
>> position that Android is a variant.
> I respectfully disagree.  Android is based on a Linux kernel but the
> userland is entirely different.  The name of the property is "",
> not "".
>> 3. Google sets the == Linux for Android platforms, not "Android".
> That's their mistake.
>> 4. is the operating system and not the specific platform.
>> Android is built on top of a compatible implementation of Linux.  We
>> don't set to ubuntu or debian for those platforms so I don't
>> think we should equate Android to
> You're equating Ubuntu and Debian (and RHEL and Fedora and ...) with
> Android.  That's incorrect.  The only thing all these systems have in
> common is the Linux kernel.  The userlands of Ubuntu, Debian, RHEL, and
> Fedora are (roughly) compatible with each other.  The userland of Android
> is not.
> I still don't see a compelling need to introduce an "os.variant"
> property.
> - Mark

More information about the porters-dev mailing list