New CPU & OS Platform System Properties Updated
dmitry.samersoff at oracle.com
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 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.
>>> This makes sense, but since you're not proposing to add this new property
>>> to the Platform Specification  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
>> 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
>> 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
>>> 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"
> - Mark
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
More information about the porters-dev