I've withdrawn my request to add a new os.variant. We'll just set os.name to Android. I will use sun.arch.abi to identify platform specific ABI differences. Bob. On Feb 12, 2013, at 11:16 AM, 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4