New CPU & OS Platform System Properties Updated

Dmitry Samersoff dmitry.samersoff at
Tue Feb 12 08:35:44 PST 2013


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.


On 2013-02-12 20:16, 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

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

More information about the porters-dev mailing list