New CPU & OS Platform System Properties Updated

[Dmitry Samersoff]

Mark,

Unfortunately, the problem is harder than it should be.

If you write gui-less program in plain C it's just linux-arm program
with minimal difference.

But gui and high level api is of course absolutely different.  So final
decision depends mostly to the way Java customers will use this flag.

-Dmitry

On 2013-02-12 20:16, mark.reinhold at oracle.com wrote:
> (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
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer