New CPU & OS Platform System Properties Updated

[mark.reinhold at oracle.com]

(cleaning up old threads ...)

2013/1/23 10:00 -0800, bob.vandette at oracle.com:
> On Jan 23, 2013, at 11:38 AM, mark.reinhold at oracle.com wrote:
>> 2013/1/10 10:59 -0800, bob.vandette at oracle.com:
>>> Thanks for all the input.  Here's an update to the proposal based on the
>>> feedback I've received so far.
>>> 
>>> OS.ARCH ADDITIONS
>>> -----------------------------
>>> 
>>> ...
>>> 
>>> 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."
>> (sun.arch.data.model, 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.

>>> OS.NAME ADDITIONS
>>> -----------------------------
>>> 
>>> My proposal below for os.name stands with the exception of Apple
>>> platforms.  For iPhone and iPad Java implementations, we will be
>>> setting os.name 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
>> "os.name" currently has the value "Linux".
>> 
>> In short form, Linux : Android :: Mac OS : iOS.
>> 
>> The "os.name" 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 " || os.name == "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 os.name 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 "os.name",
not "kernel.name".

> 3. Google sets the os.name == Linux for Android platforms, not "Android".

That's their mistake.

> 4. os.name is the operating system and not the specific platform.
> Android is built on top of a compatible implementation of Linux.  We
> don't set os.name to ubuntu or debian for those platforms so I don't
> think we should equate Android to os.name.

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