RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6

[Michael McMahon]

Jim,

Thanks for doing this. Some minor comments on the JDK changes.

1) the amd64 definitions in make/common/Defs-macosx.gmk are redundant now.
Maybe we should just delete them (though I agree with keeping the 
runtime checks
in the .java sources)

2) the (Mac) checks for os.name have generally been using 
String.startsWith() instead of equals()
so they will work with a future "Mac OS X Server" 
(java/awt/GraphicsEnvironment.java).
I think there are similar checks in hotspot too. I see Mike Swingler is 
suggesting
String.contains("OS X"). I'd be ok with that too.

3) one other location where a check needs to be added is: 
java/nio/Bits.java

Also, I don't see any code in Hotspot that checks for the new "x86_64" 
value.
So, is it actually necessary for the hotspot change to be integrated first?

- Michael,

On 20/02/12 21:02, James Melvin wrote:
> Hi,
>
> To maintain compatibility with Apple JDKs, a proposal will be made to
> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS
> X. Minor changes are required to the following repositories, for which
> I've provided webrevs...
>
> WEBREV:
> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00
> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00
>
> TESTING:
>   JPRT job (2012-02-20-203901.jmelvin.hotspot)
>   Notepad, SwingSet2, SPECjbb2005
>
> This change will also impact a small number of internal tests and RE
> scripts. The bundle names will also reflect the change amd64 -> x86_64.
> HotSpot changes can be integrated first, with the JDK changes in the
> following promotion. Should the proposal be rejected for 7u4, I
> obviously withdraw the bugfix.
>
> Feedback welcome,
>
> Jim