os.arch "amd64" or "x86_64"?

[Michael McMahon]

Yes, I think people are missing the point that it is currently amd64
and we have to change it, to restore the old behavior. But, it seems to 
be clear all right
that compatibility for existing code is the primary consideration. So, I 
agree
we should change it back to x86_64. However, even though Oracle's RE is 
pushing
in the same direction in relation to the naming of the bundles, I'd 
think it is very unlikely
that the other platforms will be changing their os.arch from amd64 any 
time soon.

Thanks,
Michael.

On 07/02/12 00:33, Kelly O'Hair wrote:
> When you say don't change this, could you be clear what os.arch setting you want?
>
> I'm advocating changing the existing code to use x86_64, so we match Apple's JDK6.
>
> -kto
>
> On Feb 6, 2012, at 4:05 PM, steve.x.northover at oracle.com wrote:
>
>> Please don't change this.  People rely on values like this and you will break them -- guaranteed.
>>
>> Steve
>>
>> On 06/02/2012 6:07 PM, Scott Kovatch wrote:
>>> On Feb 6, 2012, at 2:51 PM, Michael McMahon wrote:
>>>
>>>> Following from the last message, I just want to get opinions on this question.
>>>> Currently, the os.arch system property is set to "amd64" in common with the
>>>> other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU.
>>>> However, the property is set to "x86_64" in Apple's Java 6 runtime.
>>>>
>>>> So, the question is, what/if any compatibility issues could there be, if we maintain
>>>> this behavior? On the other hand there probably should be a good reason to change it
>>>> so it's different from the other 64 bit platforms.
>>> Web Start is the main area of compatibility that I know of. By changing it to 'amd64' developers would need to rev their JNLP files to handle the new value for os.arch on the Mac.
>>>
>>> For bundled applications Apple supported per-architecture JVM options in the application's Info.plist, but developers will need to rebundle with JDK 7 anyway. It won't be an issue unless we need to support universal binaries for non-Oracle-provided JDK distributions.
>>>
>>> -- Scott K.
>>>