New CPU & OS Platform System Properties Updated
Bob Vandette
bob.vandette at oracle.com
Wed Jan 23 10:00:07 PST 2013
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.
>
>> This will be set to the industry standard abi name that toolchain
>> vendors use.
>>
>> For Linux and Android these would be:
>>
>> gnueabi
>> gnueabihf (signifying the EABI hard float ABI)
>> androideabi
>
> 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.
>> 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.
2. OpenJDK community feedback. Mike Swingler from Apple agrees with my position that Android is a variant.
3. Google sets the os.name == Linux for Android platforms, not "Android".
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.
Bob.
>
> - Mark
>
>
> [1] http://download.java.net/jdk8/docs/api/java/lang/System.html#getProperties%28%29
More information about the porters-dev
mailing list