New CPU & OS Platform System Properties Updated (original) (raw)

mark.reinhold at oracle.com mark.reinhold at oracle.com
Tue Feb 12 08:16:41 PST 2013


(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.



More information about the jdk8-dev mailing list