RFR: 7178922 : (props) re-visit how os.name is determined on Mac
swingler at apple.com
Wed Nov 14 18:26:17 UTC 2012
On Nov 14, 2012, at 1:59 AM, Alan Bateman <Alan.Bateman at ORACLE.COM> wrote:
> On 13/11/2012 22:50, Brent Christian wrote:
>> At present, the JDK port for OS X gets its value for os.name from a JRS function exported by the Apple Java Runtime Support framework.
>> Historically this has either been "Mac OS X", or "Mac OS X Server", but there have been reports that this could change at any time, e.g.
>> to just "OS X". This would break any app that relies on this property
>> to detect the Mac platform using something like:
>> To ensure compatibility going forward, the os.name System property on Mac should be hard-coded to the value that is expected, "Mac OS X". (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of the OS).
>> Webrev is here:
>> Note: the setUnknownOSAndVersion() function is unused following my change, so I went ahead and removed it.
> This might be a question for the MacOSX folks but is it safe to continue to depend on JavaRuntimeSupport period? I'm just wondering if we really need to use it to determine the OS version and locale?
JavaRuntimeSupport.framework was explicitly created to make API for OpenJDK and 3rd party JVMs to do everything that the Apple Java SE 6 did using private SPI. To prove that it worked, we re-implemented Java SE 6 on top of it. It's purpose is to expose a stable API for functionality that is generally inappropriate for Cocoa applications, but is necessary for the Java to cooperate with the OS X graphical environment.
We currently have no plans to expand JavaRuntimeSupport, and no plans to deprecate it.
More information about the core-libs-dev