From brent.christian at oracle.com Mon Jun 13 20:58:23 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 13 Jun 2016 13:58:23 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] Message-ID: Hi, Please review this Mac-only fix: http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-7131356 Thanks go to Gerard Ziemski for the thorough investigation and detailed write-up in the bug report. The symptoms: On those OS X machines where the default system Java is not installed, any attempt to instantiate JVM from a local JDK (for example via JNI as shown in the bug) presents "No Java installed. Do you want to install Java?" dialog and refuses to run. Clearly, a valid local JDK should be able to run in this case. The problem: In java_props_macosx.c, there is code that dynamically looks up 4 methods in JavaRuntimeSupport.framework (JRS) and calls into them to find out localized OS version, default locale and the preferred language, but JRS checks for a system available Java and refuses to run if none found. Background: JavaRuntimeSupport.framework (JRS) is a framework implemented and provided by Apple for use by Java. It is a "black box" that wraps SPIs required by the Apple-provided implementation of JDK, exposing them to the JDK as APIs. Now that the JDK implementation ownership has changed from Apple to Oracle, we have the issue that we don't control the JRS implementation, but rely on Apple to support it for our JDK to continue to run. Depending on a private framework provided by a third party for our code to continue to run doesn't seem like a good long term bet (see also 8024281). Proposed solution: Apple suggested changing the JDK initialization order so any access to JRS happens only after the JLI_MemAlloc symbol is available. We believe a better solution is to re-implement the JSR APIs in question, as a move toward eventually dropping reliance on JSR altogether. The three main changes are: 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using "CFLocaleCopyPreferredLanguages", which gives us the preferred language as set in "System Preferences"->"Language & Text"->"Language" in the form of "xx" (ie. just the language code - ex. "en", "fr", etc.). The original Apple code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though this appears to be unnecessary. Following the call to setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map the language to a default country, per this comment: * If the locale name (without .encoding at variant, if any) matches * any of the names in the locale_aliases list, map it to the * corresponding full locale name. Most of the entries in the * locale_aliases list are locales that include a language name but * no country name, and this facility is used to map each language * to a default country if that's possible. I tried out a few locales, for English (en_US, en_GB), German (de_DE, de_CH) and French (fr_FR, fr_CA). Language/country system properties behave the same before and after this change, as does the java.util.Locale test attached to the bug. 2. In "setupMacOSXLocale" we simply drop the call to "JRSSetDefaultLocalization" as it appears to be a NOP. According to Apple, that API sets up native bundle locale, so that any access to native Cocoa UI (like FileOpenChooser) uses localized strings. Testing shows that this does not seem to work even in Apple's own JDK (ie. JDK 6), so dropping the call to this SPI here does not result in a regression. An issue was filed to investigate further (8024279, a dup of 8019464) which has since been closed as, "Not an Issue". 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using [NSProcessInfo operatingSystemVersion]. (Use of JRSCopyOSName was already removed by 7178922). Thanks, -Brent 1. http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c From naoto.sato at oracle.com Mon Jun 13 21:43:03 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 13 Jun 2016 14:43:03 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: Message-ID: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> Hi Brent, On 6/13/16 1:58 PM, Brent Christian wrote: > > Apple suggested changing the JDK initialization order so any access to > JRS happens only after the JLI_MemAlloc symbol is available. We believe > a better solution is to re-implement the JSR APIs in question, as a move > toward eventually dropping reliance on JSR altogether. The three main > changes are: > > 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using > "CFLocaleCopyPreferredLanguages", which gives us the preferred language > as set in "System Preferences"->"Language & Text"->"Language" in the > form of "xx" (ie. just the language code - ex. "en", "fr", etc.). The > original Apple code then calls into > "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into > "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though > this appears to be unnecessary. Following the call to > setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map > the language to a default country, per this comment: > > * If the locale name (without .encoding at variant, if any) matches > * any of the names in the locale_aliases list, map it to the > * corresponding full locale name. Most of the entries in the > * locale_aliases list are locales that include a language name but > * no country name, and this facility is used to map each language > * to a default country if that's possible. > > I tried out a few locales, for English (en_US, en_GB), German (de_DE, > de_CH) and French (fr_FR, fr_CA). Language/country system properties > behave the same before and after this change, as does the > java.util.Locale test attached to the bug. So does this mean the new code will not honor the "Region" in the OSX's system preference? For example, what happens if the user sets "UK" for the "Region" in the preference, then the new code return "US" for the country? Also, the array index "2" to assume the language length is 2 is not correct, as there are three letter language codes. So the code should literally look for "-" instead. Naoto From brent.christian at oracle.com Mon Jun 13 23:20:23 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 13 Jun 2016 16:20:23 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> Message-ID: <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> Hi, Naoto. Thank you for having a look. On 13/06/2016 14:43, Naoto Sato wrote: > On 6/13/16 1:58 PM, Brent Christian wrote: >> >> The original Apple code then calls into >> "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into >> "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though >> this appears to be unnecessary. Following the call to >> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map >> the language to a default country, per this comment: >> >> * If the locale name (without .encoding at variant, if any) matches >> * any of the names in the locale_aliases list, map it to the >> * corresponding full locale name. Most of the entries in the >> * locale_aliases list are locales that include a language name but >> * no country name, and this facility is used to map each language >> * to a default country if that's possible. >> >> I tried out a few locales, for English (en_US, en_GB), German (de_DE, >> de_CH) and French (fr_FR, fr_CA). Language/country system properties >> behave the same before and after this change, as does the >> java.util.Locale test attached to the bug. > > So does this mean the new code will not honor the "Region" in the OSX's > system preference? For example, what happens if the user sets "UK" for > the "Region" in the preference, then the new code return "US" for the > country? The new code has the same behavior as the existing code. OS X's Region preference is reflected as the locale's "format", through the "user.country.format" system property, and Locale.getDefault(Locale.FORMAT). The region is not reflected in the base "user.country" property or Locale.getDefault(). As the existing source comment indicates, the country is mapped to the default for the language, in this case, "US". It seemed a bit strange to me, too, but my testing indicates this has been the behavior since jdk 7u4. > Also, the array index "2" to assume the language length is 2 is not > correct, as there are three letter language codes. So the code should > literally look for "-" instead. Great, thanks. I will fix that. -Brent From astrange at apple.com Mon Jun 13 23:51:26 2016 From: astrange at apple.com (Alex Strange) Date: Mon, 13 Jun 2016 16:51:26 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: Message-ID: > On Jun 13, 2016, at 1:58 PM, Brent Christian wrote: > > Hi, > > Please review this Mac-only fix: > > http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-7131356 > > Thanks go to Gerard Ziemski for the thorough investigation and detailed write-up in the bug report. > > The symptoms: > > On those OS X machines where the default system Java is not installed, any attempt to instantiate JVM from a local JDK (for example via JNI as shown in the bug) presents "No Java installed. Do you want to install Java?" dialog and refuses to run. Clearly, a valid local JDK should be able to run in this case. > > The problem: > > In java_props_macosx.c, there is code that dynamically looks up 4 methods in JavaRuntimeSupport.framework (JRS) and calls into them to find out localized OS version, default locale and the preferred language, but JRS checks for a system available Java and refuses to run if none found. > > Background: > > JavaRuntimeSupport.framework (JRS) is a framework implemented and provided by Apple for use by Java. It is a "black box" that wraps SPIs required by the Apple-provided implementation of JDK, exposing them to the JDK as APIs. > > Now that the JDK implementation ownership has changed from Apple to Oracle, we have the issue that we don't control the JRS implementation, but rely on Apple to support it for our JDK to continue to run. Depending on a private framework provided by a third party for our code to continue to run doesn't seem like a good long term bet (see also 8024281). > > Proposed solution: > > Apple suggested changing the JDK initialization order so any access to JRS happens only after the JLI_MemAlloc symbol is available. We believe a better solution is to re-implement the JSR APIs in question, as a move toward eventually dropping reliance on JSR altogether. The three main changes are: > > 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using "CFLocaleCopyPreferredLanguages", which gives us the preferred language as set in "System Preferences"->"Language & Text"->"Language" in the form of "xx" (ie. just the language code - ex. "en", "fr", etc.). The original Apple code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though this appears to be unnecessary. Following the call to setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map the language to a default country, per this comment: > > * If the locale name (without .encoding at variant, if any) matches > * any of the names in the locale_aliases list, map it to the > * corresponding full locale name. Most of the entries in the > * locale_aliases list are locales that include a language name but > * no country name, and this facility is used to map each language > * to a default country if that's possible. > > I tried out a few locales, for English (en_US, en_GB), German (de_DE, de_CH) and French (fr_FR, fr_CA). Language/country system properties behave the same before and after this change, as does the java.util.Locale test attached to the bug. I think JRSCopyCanonicalLanguageForPrimaryLanguage() may be related to app bundles which don't have localizations in the user's language (for instance a Japanese-only app run on en_US). But I don't have an example of such an app or remember what the right behavior would be. > > 2. In "setupMacOSXLocale" we simply drop the call to "JRSSetDefaultLocalization" as it appears to be a NOP. According to Apple, that API sets up native bundle locale, so that any access to native Cocoa UI (like FileOpenChooser) uses localized strings. Testing shows that this does not seem to work even in Apple's own JDK (ie. JDK 6), so dropping the call to this SPI here does not result in a regression. An issue was filed to investigate further (8024279, a dup of 8019464) which has since been closed as, "Not an Issue". This was added a very long time ago so that 'java -jar x.jar' would show properly localized menus in the menubar, instead of English menus, on a non-English system. It might no longer be a problem. > > 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using [NSProcessInfo operatingSystemVersion]. (Use of JRSCopyOSName was already removed by 7178922). You shouldn't need to use objc_msgSend_stret here. If you're not getting a warning when you use @selector in the line above, you should just be able to call -operationgSystemVersion directly inside the if. If you are getting a warning, it'd be best to declare the selector yourself somewhere higher up: typedef struct { NSInteger majorVersion; NSInteger minorVersion; NSInteger patchVersion; } OSVerStruct; @interface NSProcessInfo () - (OSVerStruct)operatingSystemVersion; @end > > > Thanks, > -Brent > > 1. http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c > From naoto.sato at oracle.com Tue Jun 14 00:14:05 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 13 Jun 2016 17:14:05 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> Message-ID: <61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com> On 13/06/2016 16:20, Brent Christian wrote: > Hi, Naoto. Thank you for having a look. > > On 13/06/2016 14:43, Naoto Sato wrote: >> On 6/13/16 1:58 PM, Brent Christian wrote: >>> >>> The original Apple code then calls into >>> "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into >>> "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though >>> this appears to be unnecessary. Following the call to >>> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map >>> the language to a default country, per this comment: >>> >>> * If the locale name (without .encoding at variant, if any) matches >>> * any of the names in the locale_aliases list, map it to the >>> * corresponding full locale name. Most of the entries in the >>> * locale_aliases list are locales that include a language name but >>> * no country name, and this facility is used to map each language >>> * to a default country if that's possible. >>> >>> I tried out a few locales, for English (en_US, en_GB), German (de_DE, >>> de_CH) and French (fr_FR, fr_CA). Language/country system properties >>> behave the same before and after this change, as does the >>> java.util.Locale test attached to the bug. >> >> So does this mean the new code will not honor the "Region" in the OSX's >> system preference? For example, what happens if the user sets "UK" for >> the "Region" in the preference, then the new code return "US" for the >> country? > > The new code has the same behavior as the existing code. > > OS X's Region preference is reflected as the locale's "format", through > the "user.country.format" system property, and > Locale.getDefault(Locale.FORMAT). > > The region is not reflected in the base "user.country" property or > Locale.getDefault(). As the existing source comment indicates, the > country is mapped to the default for the language, in this case, "US". > > It seemed a bit strange to me, too, but my testing indicates this has > been the behavior since jdk 7u4. I think that is a bug. It should adopt "UK" for the default/display locale too. Probably this should be addressed in a separate bug. Naoto From brent.christian at oracle.com Tue Jun 14 16:35:21 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 14 Jun 2016 09:35:21 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> Message-ID: <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> On 6/13/16 4:20 PM, Brent Christian wrote: > On 13/06/2016 14:43, Naoto Sato wrote: >> >> Also, the array index "2" to assume the language length is 2 is not >> correct, as there are three letter language codes. So the code should >> literally look for "-" instead. > > Great, thanks. I will fix that. FYI, there will be a little more to this. Some language IDs include a script ID: a four-character code separated from the main language designator by a '-'. ("zh-Hans" for Simplified Chinese, for instance). In this case, the '-' at index 2 should be left alone. See [1]. -Brent 1. https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html From gerard.ziemski at oracle.com Tue Jun 14 19:50:26 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 14 Jun 2016 14:50:26 -0500 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: Message-ID: hi Brent, Thank you very much for tackling this. The code overall looks good (aside from the 3 code language sub tag case that we need to handle, as Naoto pointed out) Here are my 2 small comments: #1 63 CFRelease(languages); // was missing from original patch I think we can drop the comment from line 63? #2 131 void setOSNameAndVersion(java_props_t *sprops) { 132 /* Don't rely on JRSCopyOSName because there's no guarantee the value will 133 * remain the same, or even if the JRS functions will continue to be part of 134 * Mac OS X. So hardcode os_name, and fill in os_version if we can. 135 */ The comment from lines 132-135 should be dropped - we no longer use JSR - and just say that we're hardcoding the OS name? cheers > On Jun 13, 2016, at 3:58 PM, Brent Christian wrote: > > Hi, > > Please review this Mac-only fix: > > http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-7131356 > > Thanks go to Gerard Ziemski for the thorough investigation and detailed write-up in the bug report. > > The symptoms: > > On those OS X machines where the default system Java is not installed, any attempt to instantiate JVM from a local JDK (for example via JNI as shown in the bug) presents "No Java installed. Do you want to install Java?" dialog and refuses to run. Clearly, a valid local JDK should be able to run in this case. > > The problem: > > In java_props_macosx.c, there is code that dynamically looks up 4 methods in JavaRuntimeSupport.framework (JRS) and calls into them to find out localized OS version, default locale and the preferred language, but JRS checks for a system available Java and refuses to run if none found. > > Background: > > JavaRuntimeSupport.framework (JRS) is a framework implemented and provided by Apple for use by Java. It is a "black box" that wraps SPIs required by the Apple-provided implementation of JDK, exposing them to the JDK as APIs. > > Now that the JDK implementation ownership has changed from Apple to Oracle, we have the issue that we don't control the JRS implementation, but rely on Apple to support it for our JDK to continue to run. Depending on a private framework provided by a third party for our code to continue to run doesn't seem like a good long term bet (see also 8024281). > > Proposed solution: > > Apple suggested changing the JDK initialization order so any access to JRS happens only after the JLI_MemAlloc symbol is available. We believe a better solution is to re-implement the JSR APIs in question, as a move toward eventually dropping reliance on JSR altogether. The three main changes are: > > 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using "CFLocaleCopyPreferredLanguages", which gives us the preferred language as set in "System Preferences"->"Language & Text"->"Language" in the form of "xx" (ie. just the language code - ex. "en", "fr", etc.). The original Apple code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though this appears to be unnecessary. Following the call to setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map the language to a default country, per this comment: > > * If the locale name (without .encoding at variant, if any) matches > * any of the names in the locale_aliases list, map it to the > * corresponding full locale name. Most of the entries in the > * locale_aliases list are locales that include a language name but > * no country name, and this facility is used to map each language > * to a default country if that's possible. > > I tried out a few locales, for English (en_US, en_GB), German (de_DE, de_CH) and French (fr_FR, fr_CA). Language/country system properties behave the same before and after this change, as does the java.util.Locale test attached to the bug. > > 2. In "setupMacOSXLocale" we simply drop the call to "JRSSetDefaultLocalization" as it appears to be a NOP. According to Apple, that API sets up native bundle locale, so that any access to native Cocoa UI (like FileOpenChooser) uses localized strings. Testing shows that this does not seem to work even in Apple's own JDK (ie. JDK 6), so dropping the call to this SPI here does not result in a regression. An issue was filed to investigate further (8024279, a dup of 8019464) which has since been closed as, "Not an Issue". > > 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using [NSProcessInfo operatingSystemVersion]. (Use of JRSCopyOSName was already removed by 7178922). > > > Thanks, > -Brent > > 1. http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c > From brent.christian at oracle.com Mon Jun 20 21:34:49 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 20 Jun 2016 14:34:49 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com> Message-ID: On 6/13/16 5:14 PM, Naoto Sato wrote: > On 13/06/2016 16:20, Brent Christian wrote: >>>> >>>> Following the call to >>>> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map >>>> the language to a default country >>> >>> So does this mean the new code will not honor the "Region" in the OSX's >>> system preference? For example, what happens if the user sets "UK" for >>> the "Region" in the preference, then the new code return "US" for the >>> country? >> >> OS X's Region preference is reflected as the locale's "format", through >> the "user.country.format" system property, and >> Locale.getDefault(Locale.FORMAT). >> >> The region is not reflected in the base "user.country" property or >> Locale.getDefault(). As the existing source comment indicates, the >> country is mapped to the default for the language, in this case, "US". >> >> It seemed a bit strange to me, too, but my testing indicates this has >> been the behavior since jdk 7u4. > > I think that is a bug. It should adopt "UK" for the default/display > locale too. Probably this should be addressed in a separate bug. After some more investigation, I don't believe there is a bug here. The behavior I saw happened when using the basic "English"/"French"/"German" languages, and changing the country with Region. OS X also provides regional options for the language itself (e.g. "British English", "Canadian French", "Swiss German", etc) in Preferred languages. When using these languages, defaults are as expected (e.g. reflected in "user.country") without remapping with mapLookup(). Thanks, -Brent From naoto.sato at oracle.com Mon Jun 20 21:56:18 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 20 Jun 2016 14:56:18 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <61cd19d5-53cc-b8c6-d4cd-eea45fc850ed@oracle.com> Message-ID: Good! Wasn't aware there is "British English" in the language selection. Looks like all is working as expected. Naoto On 6/20/16 2:34 PM, Brent Christian wrote: > On 6/13/16 5:14 PM, Naoto Sato wrote: >> On 13/06/2016 16:20, Brent Christian wrote: >>>>> >>>>> Following the call to >>>>> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map >>>>> the language to a default country >>>> >>>> So does this mean the new code will not honor the "Region" in the OSX's >>>> system preference? For example, what happens if the user sets "UK" for >>>> the "Region" in the preference, then the new code return "US" for the >>>> country? >>> >>> OS X's Region preference is reflected as the locale's "format", through >>> the "user.country.format" system property, and >>> Locale.getDefault(Locale.FORMAT). >>> >>> The region is not reflected in the base "user.country" property or >>> Locale.getDefault(). As the existing source comment indicates, the >>> country is mapped to the default for the language, in this case, "US". >>> >>> It seemed a bit strange to me, too, but my testing indicates this has >>> been the behavior since jdk 7u4. >> >> I think that is a bug. It should adopt "UK" for the default/display >> locale too. Probably this should be addressed in a separate bug. > > After some more investigation, I don't believe there is a bug here. > > The behavior I saw happened when using the basic > "English"/"French"/"German" languages, and changing the country with > Region. > > OS X also provides regional options for the language itself (e.g. > "British English", "Canadian French", "Swiss German", etc) in Preferred > languages. When using these languages, defaults are as expected (e.g. > reflected in "user.country") without remapping with mapLookup(). > > Thanks, > -Brent From brent.christian at oracle.com Mon Jun 20 22:44:32 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 20 Jun 2016 15:44:32 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: Message-ID: <5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com> Alex - thanks for your response. More below... On 6/13/16 4:51 PM, Alex Strange wrote: >> 2. In "setupMacOSXLocale" we simply drop the call to >> "JRSSetDefaultLocalization" as it appears to be a NOP. According to >> Apple, that API sets up native bundle locale, so that any access to >> native Cocoa UI (like FileOpenChooser) uses localized strings. >> Testing shows that this does not seem to work even in Apple's own >> JDK (ie. JDK 6), so dropping the call to this SPI here does not >> result in a regression. An issue was filed to investigate further >> (8024279, a dup of 8019464) which has since been closed as, "Not an >> Issue". > > This was added a very long time ago so that 'java -jar x.jar' would > show properly localized menus in the menubar, instead of English > menus, on a non-English system. It might no longer be a problem. OK, thanks. 'java -jar x.jar' behavior is unchanged with this patch. (From the bug report, it hasn't worked since JDK 7). >> 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using >> [NSProcessInfo operatingSystemVersion]. (Use of JRSCopyOSName was >> already removed by 7178922). > > You shouldn't need to use objc_msgSend_stret here. If you're not > getting a warning when you use @selector in the line above, you > should just be able to call -operationgSystemVersion directly inside > the if. > > If you are getting a warning, it'd be best to declare the selector > yourself somewhere higher up: > > typedef struct { > NSInteger majorVersion; > NSInteger minorVersion; > NSInteger patchVersion; > } OSVerStruct; > > @interface NSProcessInfo () > - (OSVerStruct)operatingSystemVersion; > @end Thanks - this works for building w/ the 10.9 SDK (the officially supported Mac SDK for building JDK). But I believe people also build w/ the 10.10 SDK (I've not tried it myself). Won't this cause problems, since NSProcessInfo already has "operatingSystemVersion", and it returns an NSOperatingSystemVersion, not an OSVerStruct ? I'd prefer something that can build on SDK 10.9 and 10.10, etc. Once the official build moves to 10.10/later, objc_msgSend() can be removed and we can use [NSProcessInfo operatingSystemVersion] directly. Thanks, -Brent From brent.christian at oracle.com Mon Jun 20 23:38:57 2016 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 20 Jun 2016 16:38:57 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> Message-ID: Hi, I have an updated webrev at: http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ The comments have been updated as Gerard suggested. The code to process the languageString now accounts for 3-character language codes, and 4-char script designations (line 86). More extensive testing of languages with multiple scripts/regions revealed that more changes were needed to maintain current behavior. Without knowing the internal workings of how JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I believe the best options are to add a few more mappings as needed to locale_aliases (locale_str.h), and to add a special case for Portuguese (line 104). OS X has 3 language options for Portuguese: Portugues (Portugal) Portugues (Brasil) Portugues (Brasileiro) CFLocaleCopyPreferredLanguages() gives the expected language code for Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't include a region code (it's simply, "pt"), so gets mapped to the default country, Portugal. To maintain current behavior, I added a special case to map "pt" to "pt_BR" when the Region system preference is set to Brazil. This change introduces one notable behavior change, which I argue is actually a fix. The bug report and test case do not list the "Spanish (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was added to the OS since the original investigation). The old code mapped this to "es_XL", XL being one of the "user-assigned" ISO 3166 country codes. The new code maps to "es_MX", MX being the country code for Mexico. I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried every language that includes multiple scripts/locales. I also added a couple updated tests to the bug report. General testing has looked good so far. Thanks, -Brent From naoto.sato at oracle.com Tue Jun 21 21:48:24 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 21 Jun 2016 14:48:24 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> Message-ID: Hi Brent, I looked at the system preference setting panel and noticed there is "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as the designate region. Can you make changes to deal with it? (sorry I should have noticed this earlier, and it's unfortunate not to be able to upcall Locale.forLanguageTag()!) Naoto On 6/20/16 4:38 PM, Brent Christian wrote: > Hi, > > I have an updated webrev at: > http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ > > The comments have been updated as Gerard suggested. > > The code to process the languageString now accounts for 3-character > language codes, and 4-char script designations (line 86). > > More extensive testing of languages with multiple scripts/regions > revealed that more changes were needed to maintain current behavior. > Without knowing the internal workings of how > JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I > believe the best options are to add a few more mappings as needed to > locale_aliases (locale_str.h), and to add a special case for Portuguese > (line 104). > > OS X has 3 language options for Portuguese: > Portugues (Portugal) > Portugues (Brasil) > Portugues (Brasileiro) > > CFLocaleCopyPreferredLanguages() gives the expected language code for > Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't > include a region code (it's simply, "pt"), so gets mapped to the default > country, Portugal. To maintain current behavior, I added a special case > to map "pt" to "pt_BR" when the Region system preference is set to Brazil. > > > This change introduces one notable behavior change, which I argue is > actually a fix. The bug report and test case do not list the "Spanish > (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was > added to the OS since the original investigation). The old code mapped > this to "es_XL", XL being one of the "user-assigned" ISO 3166 country > codes. The new code maps to "es_MX", MX being the country code for Mexico. > > > I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried > every language that includes multiple scripts/locales. I also added a > couple updated tests to the bug report. > > General testing has looked good so far. > > Thanks, > -Brent From brent.christian at oracle.com Tue Jun 21 22:17:10 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 21 Jun 2016 15:17:10 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> Message-ID: <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> Hi, Naoto "Spanish (Latin America)" already works the same as it did before the change - it maps to "es_XL". Because "es-419" has more than 2 characters following the '-', no change is made and getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for "es-419" -> "es_XL" in locale_str.h. System property values are (still) set to: user.language: es user.country: XL user.country.format: (2-char country code for the selected Region) Thanks, -Brent On 21/06/16 14:48, Naoto Sato wrote: > Hi Brent, > > I looked at the system preference setting panel and noticed there is > "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as > the designate region. Can you make changes to deal with it? (sorry I > should have noticed this earlier, and it's unfortunate not to be able to > upcall Locale.forLanguageTag()!) > > Naoto > > On 6/20/16 4:38 PM, Brent Christian wrote: >> Hi, >> >> I have an updated webrev at: >> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >> >> The comments have been updated as Gerard suggested. >> >> The code to process the languageString now accounts for 3-character >> language codes, and 4-char script designations (line 86). >> >> More extensive testing of languages with multiple scripts/regions >> revealed that more changes were needed to maintain current behavior. >> Without knowing the internal workings of how >> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I >> believe the best options are to add a few more mappings as needed to >> locale_aliases (locale_str.h), and to add a special case for Portuguese >> (line 104). >> >> OS X has 3 language options for Portuguese: >> Portugues (Portugal) >> Portugues (Brasil) >> Portugues (Brasileiro) >> >> CFLocaleCopyPreferredLanguages() gives the expected language code for >> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >> include a region code (it's simply, "pt"), so gets mapped to the default >> country, Portugal. To maintain current behavior, I added a special case >> to map "pt" to "pt_BR" when the Region system preference is set to >> Brazil. >> >> >> This change introduces one notable behavior change, which I argue is >> actually a fix. The bug report and test case do not list the "Spanish >> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was >> added to the OS since the original investigation). The old code mapped >> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country >> codes. The new code maps to "es_MX", MX being the country code for >> Mexico. >> >> >> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried >> every language that includes multiple scripts/locales. I also added a >> couple updated tests to the bug report. >> >> General testing has looked good so far. >> >> Thanks, >> -Brent From naoto.sato at oracle.com Tue Jun 21 22:27:36 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 21 Jun 2016 15:27:36 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> Message-ID: Actually, j.u.Locale class' "country" code is defined as ISO-3166 alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying setting is "es-419" for the preferred language, "user.country" should be "419". Naoto On 6/21/16 3:17 PM, Brent Christian wrote: > Hi, Naoto > > "Spanish (Latin America)" already works the same as it did before the > change - it maps to "es_XL". Because "es-419" has more than 2 > characters following the '-', no change is made and > getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for > "es-419" -> "es_XL" in locale_str.h. > > System property values are (still) set to: > user.language: es > user.country: XL > user.country.format: (2-char country code for the selected Region) > > Thanks, > -Brent > > On 21/06/16 14:48, Naoto Sato wrote: >> Hi Brent, >> >> I looked at the system preference setting panel and noticed there is >> "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as >> the designate region. Can you make changes to deal with it? (sorry I >> should have noticed this earlier, and it's unfortunate not to be able to >> upcall Locale.forLanguageTag()!) >> >> Naoto >> >> On 6/20/16 4:38 PM, Brent Christian wrote: >>> Hi, >>> >>> I have an updated webrev at: >>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>> >>> The comments have been updated as Gerard suggested. >>> >>> The code to process the languageString now accounts for 3-character >>> language codes, and 4-char script designations (line 86). >>> >>> More extensive testing of languages with multiple scripts/regions >>> revealed that more changes were needed to maintain current behavior. >>> Without knowing the internal workings of how >>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I >>> believe the best options are to add a few more mappings as needed to >>> locale_aliases (locale_str.h), and to add a special case for Portuguese >>> (line 104). >>> >>> OS X has 3 language options for Portuguese: >>> Portugues (Portugal) >>> Portugues (Brasil) >>> Portugues (Brasileiro) >>> >>> CFLocaleCopyPreferredLanguages() gives the expected language code for >>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >>> include a region code (it's simply, "pt"), so gets mapped to the default >>> country, Portugal. To maintain current behavior, I added a special case >>> to map "pt" to "pt_BR" when the Region system preference is set to >>> Brazil. >>> >>> >>> This change introduces one notable behavior change, which I argue is >>> actually a fix. The bug report and test case do not list the "Spanish >>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was >>> added to the OS since the original investigation). The old code mapped >>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country >>> codes. The new code maps to "es_MX", MX being the country code for >>> Mexico. >>> >>> >>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried >>> every language that includes multiple scripts/locales. I also added a >>> couple updated tests to the bug report. >>> >>> General testing has looked good so far. >>> >>> Thanks, >>> -Brent From brent.christian at oracle.com Wed Jun 22 21:45:19 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 22 Jun 2016 14:45:19 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> Message-ID: On 6/21/16 3:27 PM, Naoto Sato wrote: > Actually, j.u.Locale class' "country" code is defined as ISO-3166 > alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying > setting is "es-419" for the preferred language, "user.country" should be > "419". OK, thanks - looks like another latent locale bug on Mac. I've uploaded output comparing the old [1] and new[2] behavior WRT java.util.Locale under Spanish (Latin America). It looks correct to me, based on my reading of Locale.toString()/getCountry()toLanguageTag(). The updated webrev is here: http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/ The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region designators. The es-419 mapping is no longer needed in locale_str.h. Thanks! -Brent 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt > On 6/21/16 3:17 PM, Brent Christian wrote: >> Hi, Naoto >> >> "Spanish (Latin America)" already works the same as it did before the >> change - it maps to "es_XL". Because "es-419" has more than 2 >> characters following the '-', no change is made and >> getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for >> "es-419" -> "es_XL" in locale_str.h. >> >> System property values are (still) set to: >> user.language: es >> user.country: XL >> user.country.format: (2-char country code for the selected Region) >> >> Thanks, >> -Brent >> >> On 21/06/16 14:48, Naoto Sato wrote: >>> Hi Brent, >>> >>> I looked at the system preference setting panel and noticed there is >>> "Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as >>> the designate region. Can you make changes to deal with it? (sorry I >>> should have noticed this earlier, and it's unfortunate not to be able to >>> upcall Locale.forLanguageTag()!) >>> >>> Naoto >>> >>> On 6/20/16 4:38 PM, Brent Christian wrote: >>>> Hi, >>>> >>>> I have an updated webrev at: >>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>>> >>>> The comments have been updated as Gerard suggested. >>>> >>>> The code to process the languageString now accounts for 3-character >>>> language codes, and 4-char script designations (line 86). >>>> >>>> More extensive testing of languages with multiple scripts/regions >>>> revealed that more changes were needed to maintain current behavior. >>>> Without knowing the internal workings of how >>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I >>>> believe the best options are to add a few more mappings as needed to >>>> locale_aliases (locale_str.h), and to add a special case for Portuguese >>>> (line 104). >>>> >>>> OS X has 3 language options for Portuguese: >>>> Portugues (Portugal) >>>> Portugues (Brasil) >>>> Portugues (Brasileiro) >>>> >>>> CFLocaleCopyPreferredLanguages() gives the expected language code for >>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >>>> include a region code (it's simply, "pt"), so gets mapped to the >>>> default >>>> country, Portugal. To maintain current behavior, I added a special >>>> case >>>> to map "pt" to "pt_BR" when the Region system preference is set to >>>> Brazil. >>>> >>>> >>>> This change introduces one notable behavior change, which I argue is >>>> actually a fix. The bug report and test case do not list the "Spanish >>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was >>>> added to the OS since the original investigation). The old code mapped >>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country >>>> codes. The new code maps to "es_MX", MX being the country code for >>>> Mexico. >>>> >>>> >>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried >>>> every language that includes multiple scripts/locales. I also added a >>>> couple updated tests to the bug report. >>>> >>>> General testing has looked good so far. >>>> >>>> Thanks, >>>> -Brent From astrange at apple.com Wed Jun 22 22:10:52 2016 From: astrange at apple.com (Alex Strange) Date: Wed, 22 Jun 2016 15:10:52 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com> References: <5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com> Message-ID: > On Jun 20, 2016, at 3:44 PM, Brent Christian wrote: > > > Alex - thanks for your response. More below... > > On 6/13/16 4:51 PM, Alex Strange wrote: >>> 2. In "setupMacOSXLocale" we simply drop the call to >>> "JRSSetDefaultLocalization" as it appears to be a NOP. According to >>> Apple, that API sets up native bundle locale, so that any access to >>> native Cocoa UI (like FileOpenChooser) uses localized strings. >>> Testing shows that this does not seem to work even in Apple's own >>> JDK (ie. JDK 6), so dropping the call to this SPI here does not >>> result in a regression. An issue was filed to investigate further >>> (8024279, a dup of 8019464) which has since been closed as, "Not an >>> Issue". >> >> This was added a very long time ago so that 'java -jar x.jar' would >> show properly localized menus in the menubar, instead of English >> menus, on a non-English system. It might no longer be a problem. > > OK, thanks. > > 'java -jar x.jar' behavior is unchanged with this patch. (From the bug report, it hasn't worked since JDK 7). That's unfortunate, since it probably means I broke it back then. Sorry about that. > >>> 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using >>> [NSProcessInfo operatingSystemVersion]. (Use of JRSCopyOSName was >>> already removed by 7178922). >> >> You shouldn't need to use objc_msgSend_stret here. If you're not >> getting a warning when you use @selector in the line above, you >> should just be able to call -operationgSystemVersion directly inside >> the if. >> >> If you are getting a warning, it'd be best to declare the selector >> yourself somewhere higher up: >> >> typedef struct { >> NSInteger majorVersion; >> NSInteger minorVersion; >> NSInteger patchVersion; >> } OSVerStruct; >> >> @interface NSProcessInfo () >> - (OSVerStruct)operatingSystemVersion; >> @end > > Thanks - this works for building w/ the 10.9 SDK (the officially supported Mac SDK for building JDK). > > But I believe people also build w/ the 10.10 SDK (I've not tried it myself). Won't this cause problems, since NSProcessInfo already has "operatingSystemVersion", and it returns an NSOperatingSystemVersion, not an OSVerStruct ? > > I'd prefer something that can build on SDK 10.9 and 10.10, etc. Once the official build moves to 10.10/later, objc_msgSend() can be removed and we can use [NSProcessInfo operatingSystemVersion] directly. Ah, I see. Your way is correct, then. There might be a way to #ifdef it out (not sure), but it's not worth it. > > Thanks, > -Brent From brent.christian at oracle.com Wed Jun 22 22:27:10 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 22 Jun 2016 15:27:10 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <5462a432-6ae9-cf89-f2eb-0324c70ac80e@oracle.com> Message-ID: <3c09bc21-0ad1-6387-7464-2d98fc7109f0@oracle.com> On 22/06/16 15:10, Alex Strange wrote: >> On Jun 20, 2016, at 3:44 PM, Brent Christian wrote: >> >> I'd prefer something that can build on SDK 10.9 and 10.10, etc. > > There might be a way to #ifdef it out (not sure), but it's not worth it. I came to the same conclusion. :) Thanks! -Brent From naoto.sato at oracle.com Wed Jun 22 22:58:27 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 22 Jun 2016 15:58:27 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> Message-ID: <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> Hi Brent, 1. It seems that the display language in the new code seems to have some problems. I see (in es-419.txt): --- locale[Default|Display|Format].getLanguage () is user.language: it is --- And in fact, display strings are no longer in Spanish in the new version (as the language is "is"). 2. I think mapping language/script combination to a typical locale is ok to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, right?) In the meantime, I would like to have "user.script" set to "Latn" in such a case. Naoto On 6/22/16 2:45 PM, Brent Christian wrote: > On 6/21/16 3:27 PM, Naoto Sato wrote: >> Actually, j.u.Locale class' "country" code is defined as ISO-3166 >> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying >> setting is "es-419" for the preferred language, "user.country" should be >> "419". > > OK, thanks - looks like another latent locale bug on Mac. I've uploaded > output comparing the old [1] and new[2] behavior WRT java.util.Locale > under Spanish (Latin America). It looks correct to me, based on my > reading of Locale.toString()/getCountry()toLanguageTag(). > > The updated webrev is here: > http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/ > > The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region > designators. The es-419 mapping is no longer needed in locale_str.h. > > Thanks! > -Brent > > 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt > 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt > >> On 6/21/16 3:17 PM, Brent Christian wrote: >>> Hi, Naoto >>> >>> "Spanish (Latin America)" already works the same as it did before the >>> change - it maps to "es_XL". Because "es-419" has more than 2 >>> characters following the '-', no change is made and >>> getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for >>> "es-419" -> "es_XL" in locale_str.h. >>> >>> System property values are (still) set to: >>> user.language: es >>> user.country: XL >>> user.country.format: (2-char country code for the selected Region) >>> >>> Thanks, >>> -Brent >>> >>> On 21/06/16 14:48, Naoto Sato wrote: >>>> Hi Brent, >>>> >>>> I looked at the system preference setting panel and noticed there is >>>> "Spanish (Latin America)", which I think uses UN M.49 code >>>> ("es-419") as >>>> the designate region. Can you make changes to deal with it? (sorry I >>>> should have noticed this earlier, and it's unfortunate not to be >>>> able to >>>> upcall Locale.forLanguageTag()!) >>>> >>>> Naoto >>>> >>>> On 6/20/16 4:38 PM, Brent Christian wrote: >>>>> Hi, >>>>> >>>>> I have an updated webrev at: >>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>>>> >>>>> The comments have been updated as Gerard suggested. >>>>> >>>>> The code to process the languageString now accounts for 3-character >>>>> language codes, and 4-char script designations (line 86). >>>>> >>>>> More extensive testing of languages with multiple scripts/regions >>>>> revealed that more changes were needed to maintain current behavior. >>>>> Without knowing the internal workings of how >>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I >>>>> believe the best options are to add a few more mappings as needed to >>>>> locale_aliases (locale_str.h), and to add a special case for >>>>> Portuguese >>>>> (line 104). >>>>> >>>>> OS X has 3 language options for Portuguese: >>>>> Portugues (Portugal) >>>>> Portugues (Brasil) >>>>> Portugues (Brasileiro) >>>>> >>>>> CFLocaleCopyPreferredLanguages() gives the expected language code for >>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >>>>> include a region code (it's simply, "pt"), so gets mapped to the >>>>> default >>>>> country, Portugal. To maintain current behavior, I added a special >>>>> case >>>>> to map "pt" to "pt_BR" when the Region system preference is set to >>>>> Brazil. >>>>> >>>>> >>>>> This change introduces one notable behavior change, which I argue is >>>>> actually a fix. The bug report and test case do not list the "Spanish >>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it was >>>>> added to the OS since the original investigation). The old code >>>>> mapped >>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country >>>>> codes. The new code maps to "es_MX", MX being the country code for >>>>> Mexico. >>>>> >>>>> >>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried >>>>> every language that includes multiple scripts/locales. I also added a >>>>> couple updated tests to the bug report. >>>>> >>>>> General testing has looked good so far. >>>>> >>>>> Thanks, >>>>> -Brent From brent.christian at oracle.com Thu Jun 23 04:48:28 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 22 Jun 2016 21:48:28 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> Message-ID: <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com> On 6/22/16 3:58 PM, Naoto Sato wrote: > Hi Brent, > > 1. It seems that the display language in the new code seems to have some > problems. I see (in es-419.txt): > > --- > locale[Default|Display|Format].getLanguage () is > user.language: it is > --- > > And in fact, display strings are no longer in Spanish in the new version > (as the language is "is"). Strange - something in your local environment? It looks right to me. > 2. I think mapping language/script combination to a typical locale is ok > to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, > right?) In the meantime, I would like to have "user.script" set to > "Latn" in such a case. Is this something that I could file a follow-on issue for? The existing code doesn't set "user.script" in these cases, either, and it looks like that would take some digging into java_props_md.c... -Brent > On 6/22/16 2:45 PM, Brent Christian wrote: >> On 6/21/16 3:27 PM, Naoto Sato wrote: >>> Actually, j.u.Locale class' "country" code is defined as ISO-3166 >>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying >>> setting is "es-419" for the preferred language, "user.country" should be >>> "419". >> >> OK, thanks - looks like another latent locale bug on Mac. I've uploaded >> output comparing the old [1] and new[2] behavior WRT java.util.Locale >> under Spanish (Latin America). It looks correct to me, based on my >> reading of Locale.toString()/getCountry()toLanguageTag(). >> >> The updated webrev is here: >> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/ >> >> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region >> designators. The es-419 mapping is no longer needed in locale_str.h. >> >> Thanks! >> -Brent >> >> 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt >> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt >> >>> On 6/21/16 3:17 PM, Brent Christian wrote: >>>> Hi, Naoto >>>> >>>> "Spanish (Latin America)" already works the same as it did before the >>>> change - it maps to "es_XL". Because "es-419" has more than 2 >>>> characters following the '-', no change is made and >>>> getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for >>>> "es-419" -> "es_XL" in locale_str.h. >>>> >>>> System property values are (still) set to: >>>> user.language: es >>>> user.country: XL >>>> user.country.format: (2-char country code for the selected Region) >>>> >>>> Thanks, >>>> -Brent >>>> >>>> On 21/06/16 14:48, Naoto Sato wrote: >>>>> Hi Brent, >>>>> >>>>> I looked at the system preference setting panel and noticed there is >>>>> "Spanish (Latin America)", which I think uses UN M.49 code >>>>> ("es-419") as >>>>> the designate region. Can you make changes to deal with it? (sorry I >>>>> should have noticed this earlier, and it's unfortunate not to be >>>>> able to >>>>> upcall Locale.forLanguageTag()!) >>>>> >>>>> Naoto >>>>> >>>>> On 6/20/16 4:38 PM, Brent Christian wrote: >>>>>> Hi, >>>>>> >>>>>> I have an updated webrev at: >>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>>>>> >>>>>> The comments have been updated as Gerard suggested. >>>>>> >>>>>> The code to process the languageString now accounts for 3-character >>>>>> language codes, and 4-char script designations (line 86). >>>>>> >>>>>> More extensive testing of languages with multiple scripts/regions >>>>>> revealed that more changes were needed to maintain current behavior. >>>>>> Without knowing the internal workings of how >>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I >>>>>> believe the best options are to add a few more mappings as needed to >>>>>> locale_aliases (locale_str.h), and to add a special case for >>>>>> Portuguese >>>>>> (line 104). >>>>>> >>>>>> OS X has 3 language options for Portuguese: >>>>>> Portugues (Portugal) >>>>>> Portugues (Brasil) >>>>>> Portugues (Brasileiro) >>>>>> >>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code for >>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >>>>>> include a region code (it's simply, "pt"), so gets mapped to the >>>>>> default >>>>>> country, Portugal. To maintain current behavior, I added a special >>>>>> case >>>>>> to map "pt" to "pt_BR" when the Region system preference is set to >>>>>> Brazil. >>>>>> >>>>>> >>>>>> This change introduces one notable behavior change, which I argue is >>>>>> actually a fix. The bug report and test case do not list the >>>>>> "Spanish >>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it >>>>>> was >>>>>> added to the OS since the original investigation). The old code >>>>>> mapped >>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 country >>>>>> codes. The new code maps to "es_MX", MX being the country code for >>>>>> Mexico. >>>>>> >>>>>> >>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried >>>>>> every language that includes multiple scripts/locales. I also >>>>>> added a >>>>>> couple updated tests to the bug report. >>>>>> >>>>>> General testing has looked good so far. >>>>>> >>>>>> Thanks, >>>>>> -Brent From naoto.sato at oracle.com Thu Jun 23 15:24:48 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 23 Jun 2016 08:24:48 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com> Message-ID: On 6/22/16 9:48 PM, Brent Christian wrote: > On 6/22/16 3:58 PM, Naoto Sato wrote: >> Hi Brent, >> >> 1. It seems that the display language in the new code seems to have some >> problems. I see (in es-419.txt): >> >> --- >> locale[Default|Display|Format].getLanguage () is >> user.language: it is >> --- >> >> And in fact, display strings are no longer in Spanish in the new version >> (as the language is "is"). > > Strange - something in your local environment? It looks right to me. Never mind. Thanks to Chrome, it was automatically converted to English :-) Funny thing was that the browser did not translate to English for es-419.old.txt... > >> 2. I think mapping language/script combination to a typical locale is ok >> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, >> right?) In the meantime, I would like to have "user.script" set to >> "Latn" in such a case. > > Is this something that I could file a follow-on issue for? The existing > code doesn't set "user.script" in these cases, either, and it looks like > that would take some digging into java_props_md.c... Fine by me. Naoto > > -Brent > >> On 6/22/16 2:45 PM, Brent Christian wrote: >>> On 6/21/16 3:27 PM, Naoto Sato wrote: >>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166 >>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying >>>> setting is "es-419" for the preferred language, "user.country" >>>> should be >>>> "419". >>> >>> OK, thanks - looks like another latent locale bug on Mac. I've uploaded >>> output comparing the old [1] and new[2] behavior WRT java.util.Locale >>> under Spanish (Latin America). It looks correct to me, based on my >>> reading of Locale.toString()/getCountry()toLanguageTag(). >>> >>> The updated webrev is here: >>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/ >>> >>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region >>> designators. The es-419 mapping is no longer needed in locale_str.h. >>> >>> Thanks! >>> -Brent >>> >>> 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt >>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt >>> >>>> On 6/21/16 3:17 PM, Brent Christian wrote: >>>>> Hi, Naoto >>>>> >>>>> "Spanish (Latin America)" already works the same as it did before the >>>>> change - it maps to "es_XL". Because "es-419" has more than 2 >>>>> characters following the '-', no change is made and >>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for >>>>> "es-419" -> "es_XL" in locale_str.h. >>>>> >>>>> System property values are (still) set to: >>>>> user.language: es >>>>> user.country: XL >>>>> user.country.format: (2-char country code for the selected Region) >>>>> >>>>> Thanks, >>>>> -Brent >>>>> >>>>> On 21/06/16 14:48, Naoto Sato wrote: >>>>>> Hi Brent, >>>>>> >>>>>> I looked at the system preference setting panel and noticed there is >>>>>> "Spanish (Latin America)", which I think uses UN M.49 code >>>>>> ("es-419") as >>>>>> the designate region. Can you make changes to deal with it? (sorry I >>>>>> should have noticed this earlier, and it's unfortunate not to be >>>>>> able to >>>>>> upcall Locale.forLanguageTag()!) >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 6/20/16 4:38 PM, Brent Christian wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have an updated webrev at: >>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>>>>>> >>>>>>> The comments have been updated as Gerard suggested. >>>>>>> >>>>>>> The code to process the languageString now accounts for 3-character >>>>>>> language codes, and 4-char script designations (line 86). >>>>>>> >>>>>>> More extensive testing of languages with multiple scripts/regions >>>>>>> revealed that more changes were needed to maintain current behavior. >>>>>>> Without knowing the internal workings of how >>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language >>>>>>> ID, I >>>>>>> believe the best options are to add a few more mappings as needed to >>>>>>> locale_aliases (locale_str.h), and to add a special case for >>>>>>> Portuguese >>>>>>> (line 104). >>>>>>> >>>>>>> OS X has 3 language options for Portuguese: >>>>>>> Portugues (Portugal) >>>>>>> Portugues (Brasil) >>>>>>> Portugues (Brasileiro) >>>>>>> >>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code >>>>>>> for >>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >>>>>>> include a region code (it's simply, "pt"), so gets mapped to the >>>>>>> default >>>>>>> country, Portugal. To maintain current behavior, I added a special >>>>>>> case >>>>>>> to map "pt" to "pt_BR" when the Region system preference is set to >>>>>>> Brazil. >>>>>>> >>>>>>> >>>>>>> This change introduces one notable behavior change, which I argue is >>>>>>> actually a fix. The bug report and test case do not list the >>>>>>> "Spanish >>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it >>>>>>> was >>>>>>> added to the OS since the original investigation). The old code >>>>>>> mapped >>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 >>>>>>> country >>>>>>> codes. The new code maps to "es_MX", MX being the country code for >>>>>>> Mexico. >>>>>>> >>>>>>> >>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried >>>>>>> every language that includes multiple scripts/locales. I also >>>>>>> added a >>>>>>> couple updated tests to the bug report. >>>>>>> >>>>>>> General testing has looked good so far. >>>>>>> >>>>>>> Thanks, >>>>>>> -Brent From naoto.sato at oracle.com Thu Jun 23 17:34:59 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 23 Jun 2016 10:34:59 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com> Message-ID: I reviewed webrev.04 thoroughly this time and comments below: - Although the OSX API returns the cases as in the spec, BCP 47 language tags are case insensitive, so it would be better to check [a-z] in line 94/95 as well. - Line 82: Does the API actually returns "zh-Hans_HK"? Underscore ('_') is not a part of language tags. Other than those, it looks good to me. Naoto On 6/23/16 8:24 AM, Naoto Sato wrote: > On 6/22/16 9:48 PM, Brent Christian wrote: >> On 6/22/16 3:58 PM, Naoto Sato wrote: >>> Hi Brent, >>> >>> 1. It seems that the display language in the new code seems to have some >>> problems. I see (in es-419.txt): >>> >>> --- >>> locale[Default|Display|Format].getLanguage () is >>> user.language: it is >>> --- >>> >>> And in fact, display strings are no longer in Spanish in the new version >>> (as the language is "is"). >> >> Strange - something in your local environment? It looks right to me. > > Never mind. Thanks to Chrome, it was automatically converted to English > :-) Funny thing was that the browser did not translate to English for > es-419.old.txt... > >> >>> 2. I think mapping language/script combination to a typical locale is ok >>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, >>> right?) In the meantime, I would like to have "user.script" set to >>> "Latn" in such a case. >> >> Is this something that I could file a follow-on issue for? The existing >> code doesn't set "user.script" in these cases, either, and it looks like >> that would take some digging into java_props_md.c... > > Fine by me. > > Naoto > >> >> -Brent >> >>> On 6/22/16 2:45 PM, Brent Christian wrote: >>>> On 6/21/16 3:27 PM, Naoto Sato wrote: >>>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166 >>>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying >>>>> setting is "es-419" for the preferred language, "user.country" >>>>> should be >>>>> "419". >>>> >>>> OK, thanks - looks like another latent locale bug on Mac. I've >>>> uploaded >>>> output comparing the old [1] and new[2] behavior WRT java.util.Locale >>>> under Spanish (Latin America). It looks correct to me, based on my >>>> reading of Locale.toString()/getCountry()toLanguageTag(). >>>> >>>> The updated webrev is here: >>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/ >>>> >>>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region >>>> designators. The es-419 mapping is no longer needed in locale_str.h. >>>> >>>> Thanks! >>>> -Brent >>>> >>>> 1. >>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt >>>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt >>>> >>>>> On 6/21/16 3:17 PM, Brent Christian wrote: >>>>>> Hi, Naoto >>>>>> >>>>>> "Spanish (Latin America)" already works the same as it did before the >>>>>> change - it maps to "es_XL". Because "es-419" has more than 2 >>>>>> characters following the '-', no change is made and >>>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for >>>>>> "es-419" -> "es_XL" in locale_str.h. >>>>>> >>>>>> System property values are (still) set to: >>>>>> user.language: es >>>>>> user.country: XL >>>>>> user.country.format: (2-char country code for the selected Region) >>>>>> >>>>>> Thanks, >>>>>> -Brent >>>>>> >>>>>> On 21/06/16 14:48, Naoto Sato wrote: >>>>>>> Hi Brent, >>>>>>> >>>>>>> I looked at the system preference setting panel and noticed there is >>>>>>> "Spanish (Latin America)", which I think uses UN M.49 code >>>>>>> ("es-419") as >>>>>>> the designate region. Can you make changes to deal with it? (sorry I >>>>>>> should have noticed this earlier, and it's unfortunate not to be >>>>>>> able to >>>>>>> upcall Locale.forLanguageTag()!) >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>> On 6/20/16 4:38 PM, Brent Christian wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have an updated webrev at: >>>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>>>>>>> >>>>>>>> The comments have been updated as Gerard suggested. >>>>>>>> >>>>>>>> The code to process the languageString now accounts for 3-character >>>>>>>> language codes, and 4-char script designations (line 86). >>>>>>>> >>>>>>>> More extensive testing of languages with multiple scripts/regions >>>>>>>> revealed that more changes were needed to maintain current >>>>>>>> behavior. >>>>>>>> Without knowing the internal workings of how >>>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language >>>>>>>> ID, I >>>>>>>> believe the best options are to add a few more mappings as >>>>>>>> needed to >>>>>>>> locale_aliases (locale_str.h), and to add a special case for >>>>>>>> Portuguese >>>>>>>> (line 104). >>>>>>>> >>>>>>>> OS X has 3 language options for Portuguese: >>>>>>>> Portugues (Portugal) >>>>>>>> Portugues (Brasil) >>>>>>>> Portugues (Brasileiro) >>>>>>>> >>>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code >>>>>>>> for >>>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >>>>>>>> include a region code (it's simply, "pt"), so gets mapped to the >>>>>>>> default >>>>>>>> country, Portugal. To maintain current behavior, I added a special >>>>>>>> case >>>>>>>> to map "pt" to "pt_BR" when the Region system preference is set to >>>>>>>> Brazil. >>>>>>>> >>>>>>>> >>>>>>>> This change introduces one notable behavior change, which I >>>>>>>> argue is >>>>>>>> actually a fix. The bug report and test case do not list the >>>>>>>> "Spanish >>>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it >>>>>>>> was >>>>>>>> added to the OS since the original investigation). The old code >>>>>>>> mapped >>>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 >>>>>>>> country >>>>>>>> codes. The new code maps to "es_MX", MX being the country code for >>>>>>>> Mexico. >>>>>>>> >>>>>>>> >>>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I >>>>>>>> tried >>>>>>>> every language that includes multiple scripts/locales. I also >>>>>>>> added a >>>>>>>> couple updated tests to the bug report. >>>>>>>> >>>>>>>> General testing has looked good so far. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Brent From brent.christian at oracle.com Thu Jun 23 17:39:03 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 23 Jun 2016 10:39:03 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com> Message-ID: <566324bd-19bf-3ec2-840d-2292f8264c0d@oracle.com> On 6/23/16 8:24 AM, Naoto Sato wrote: > On 6/22/16 9:48 PM, Brent Christian wrote: >> On 6/22/16 3:58 PM, Naoto Sato wrote: >>> >>> 2. I think mapping language/script combination to a typical locale is ok >>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, >>> right?) In the meantime, I would like to have "user.script" set to >>> "Latn" in such a case. >> >> Is this something that I could file a follow-on issue for? The existing >> code doesn't set "user.script" in these cases, either, and it looks like >> that would take some digging into java_props_md.c... > > Fine by me. I have filed 8160199, "Language's script should be reflected in user.script on Mac OS X". Thanks, -Brent From brent.christian at oracle.com Thu Jun 23 20:13:40 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 23 Jun 2016 13:13:40 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com> Message-ID: <9da91e57-ad56-bdbf-996e-e0a1a5b7a98a@oracle.com> On 23/6/16 ??10:34, Naoto Sato wrote: > I reviewed webrev.04 thoroughly this time and comments below: > > - Although the OSX API returns the cases as in the spec, BCP 47 language > tags are case insensitive, so it would be better to check [a-z] in line > 94/95 as well. Done (and I've simplified the assert code to use isalpha() and isdigit()). > - Line 82: Does the API actually returns "zh-Hans_HK"? Underscore ('_') > is not a part of language tags. Ah, thanks. No, "zh-Hans_HK" is not returned by CFLocaleCopyPreferredLanguages(). We do see it in the default switch case when we call CFLocaleGetIdentifier(), which I guess was the source of my confusion. I've removed that comment line, and reworked the comment a little bit. http://cr.openjdk.java.net/~bchristi/7131356/webrev.05/ Thanks, -Brent > On 6/23/16 8:24 AM, Naoto Sato wrote: >> On 6/22/16 9:48 PM, Brent Christian wrote: >>> On 6/22/16 3:58 PM, Naoto Sato wrote: >>>> Hi Brent, >>>> >>>> 1. It seems that the display language in the new code seems to have >>>> some >>>> problems. I see (in es-419.txt): >>>> >>>> --- >>>> locale[Default|Display|Format].getLanguage () is >>>> user.language: it is >>>> --- >>>> >>>> And in fact, display strings are no longer in Spanish in the new >>>> version >>>> (as the language is "is"). >>> >>> Strange - something in your local environment? It looks right to me. >> >> Never mind. Thanks to Chrome, it was automatically converted to English >> :-) Funny thing was that the browser did not translate to English for >> es-419.old.txt... >> >>> >>>> 2. I think mapping language/script combination to a typical locale >>>> is ok >>>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, >>>> right?) In the meantime, I would like to have "user.script" set to >>>> "Latn" in such a case. >>> >>> Is this something that I could file a follow-on issue for? The existing >>> code doesn't set "user.script" in these cases, either, and it looks like >>> that would take some digging into java_props_md.c... >> >> Fine by me. >> >> Naoto >> >>> >>> -Brent >>> >>>> On 6/22/16 2:45 PM, Brent Christian wrote: >>>>> On 6/21/16 3:27 PM, Naoto Sato wrote: >>>>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166 >>>>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying >>>>>> setting is "es-419" for the preferred language, "user.country" >>>>>> should be >>>>>> "419". >>>>> >>>>> OK, thanks - looks like another latent locale bug on Mac. I've >>>>> uploaded >>>>> output comparing the old [1] and new[2] behavior WRT java.util.Locale >>>>> under Spanish (Latin America). It looks correct to me, based on my >>>>> reading of Locale.toString()/getCountry()toLanguageTag(). >>>>> >>>>> The updated webrev is here: >>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/ >>>>> >>>>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region >>>>> designators. The es-419 mapping is no longer needed in locale_str.h. >>>>> >>>>> Thanks! >>>>> -Brent >>>>> >>>>> 1. >>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt >>>>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt >>>>> >>>>>> On 6/21/16 3:17 PM, Brent Christian wrote: >>>>>>> Hi, Naoto >>>>>>> >>>>>>> "Spanish (Latin America)" already works the same as it did before >>>>>>> the >>>>>>> change - it maps to "es_XL". Because "es-419" has more than 2 >>>>>>> characters following the '-', no change is made and >>>>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping >>>>>>> for >>>>>>> "es-419" -> "es_XL" in locale_str.h. >>>>>>> >>>>>>> System property values are (still) set to: >>>>>>> user.language: es >>>>>>> user.country: XL >>>>>>> user.country.format: (2-char country code for the selected Region) >>>>>>> >>>>>>> Thanks, >>>>>>> -Brent >>>>>>> >>>>>>> On 21/06/16 14:48, Naoto Sato wrote: >>>>>>>> Hi Brent, >>>>>>>> >>>>>>>> I looked at the system preference setting panel and noticed >>>>>>>> there is >>>>>>>> "Spanish (Latin America)", which I think uses UN M.49 code >>>>>>>> ("es-419") as >>>>>>>> the designate region. Can you make changes to deal with it? >>>>>>>> (sorry I >>>>>>>> should have noticed this earlier, and it's unfortunate not to be >>>>>>>> able to >>>>>>>> upcall Locale.forLanguageTag()!) >>>>>>>> >>>>>>>> Naoto >>>>>>>> >>>>>>>> On 6/20/16 4:38 PM, Brent Christian wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have an updated webrev at: >>>>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>>>>>>>> >>>>>>>>> The comments have been updated as Gerard suggested. >>>>>>>>> >>>>>>>>> The code to process the languageString now accounts for >>>>>>>>> 3-character >>>>>>>>> language codes, and 4-char script designations (line 86). >>>>>>>>> >>>>>>>>> More extensive testing of languages with multiple scripts/regions >>>>>>>>> revealed that more changes were needed to maintain current >>>>>>>>> behavior. >>>>>>>>> Without knowing the internal workings of how >>>>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language >>>>>>>>> ID, I >>>>>>>>> believe the best options are to add a few more mappings as >>>>>>>>> needed to >>>>>>>>> locale_aliases (locale_str.h), and to add a special case for >>>>>>>>> Portuguese >>>>>>>>> (line 104). >>>>>>>>> >>>>>>>>> OS X has 3 language options for Portuguese: >>>>>>>>> Portugues (Portugal) >>>>>>>>> Portugues (Brasil) >>>>>>>>> Portugues (Brasileiro) >>>>>>>>> >>>>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code >>>>>>>>> for >>>>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't >>>>>>>>> include a region code (it's simply, "pt"), so gets mapped to the >>>>>>>>> default >>>>>>>>> country, Portugal. To maintain current behavior, I added a >>>>>>>>> special >>>>>>>>> case >>>>>>>>> to map "pt" to "pt_BR" when the Region system preference is set to >>>>>>>>> Brazil. >>>>>>>>> >>>>>>>>> >>>>>>>>> This change introduces one notable behavior change, which I >>>>>>>>> argue is >>>>>>>>> actually a fix. The bug report and test case do not list the >>>>>>>>> "Spanish >>>>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 (presumably it >>>>>>>>> was >>>>>>>>> added to the OS since the original investigation). The old code >>>>>>>>> mapped >>>>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 >>>>>>>>> country >>>>>>>>> codes. The new code maps to "es_MX", MX being the country code >>>>>>>>> for >>>>>>>>> Mexico. >>>>>>>>> >>>>>>>>> >>>>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I >>>>>>>>> tried >>>>>>>>> every language that includes multiple scripts/locales. I also >>>>>>>>> added a >>>>>>>>> couple updated tests to the bug report. >>>>>>>>> >>>>>>>>> General testing has looked good so far. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -Brent From naoto.sato at oracle.com Thu Jun 23 20:42:59 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 23 Jun 2016 13:42:59 -0700 Subject: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx] In-Reply-To: <9da91e57-ad56-bdbf-996e-e0a1a5b7a98a@oracle.com> References: <2e01f888-972a-d77b-a8b8-a548db567595@oracle.com> <5a4e0f57-6455-627f-993a-ec853eaf8895@oracle.com> <7d70a9f0-a0ab-f4b2-5e20-c3d5e7cd6258@oracle.com> <41fa5106-25b5-359c-baa8-6e5677d24cd8@oracle.com> <7ae552e1-13d2-7cfe-bf95-9d5b76d80420@oracle.com> <885bf1d1-f61f-7770-3731-bccae3f8dba7@oracle.com> <9da91e57-ad56-bdbf-996e-e0a1a5b7a98a@oracle.com> Message-ID: <493c3a33-0cec-22e9-1a39-5a26186ce1ca@oracle.com> +1 > On 23/6/16 ??10:34, Naoto Sato wrote: I see that you tested thoroughly :-) Naoto On 6/23/16 1:13 PM, Brent Christian wrote: > On 23/6/16 ??10:34, Naoto Sato wrote: >> I reviewed webrev.04 thoroughly this time and comments below: >> >> - Although the OSX API returns the cases as in the spec, BCP 47 language >> tags are case insensitive, so it would be better to check [a-z] in line >> 94/95 as well. > > Done (and I've simplified the assert code to use isalpha() and isdigit()). > >> - Line 82: Does the API actually returns "zh-Hans_HK"? Underscore ('_') >> is not a part of language tags. > > Ah, thanks. No, "zh-Hans_HK" is not returned by > CFLocaleCopyPreferredLanguages(). We do see it in the default switch > case when we call CFLocaleGetIdentifier(), which I guess was the source > of my confusion. > > I've removed that comment line, and reworked the comment a little bit. > > http://cr.openjdk.java.net/~bchristi/7131356/webrev.05/ > > Thanks, > -Brent > >> On 6/23/16 8:24 AM, Naoto Sato wrote: >>> On 6/22/16 9:48 PM, Brent Christian wrote: >>>> On 6/22/16 3:58 PM, Naoto Sato wrote: >>>>> Hi Brent, >>>>> >>>>> 1. It seems that the display language in the new code seems to have >>>>> some >>>>> problems. I see (in es-419.txt): >>>>> >>>>> --- >>>>> locale[Default|Display|Format].getLanguage () is >>>>> user.language: it is >>>>> --- >>>>> >>>>> And in fact, display strings are no longer in Spanish in the new >>>>> version >>>>> (as the language is "is"). >>>> >>>> Strange - something in your local environment? It looks right to me. >>> >>> Never mind. Thanks to Chrome, it was automatically converted to English >>> :-) Funny thing was that the browser did not translate to English for >>> es-419.old.txt... >>> >>>> >>>>> 2. I think mapping language/script combination to a typical locale >>>>> is ok >>>>> to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the >>>>> JRS, >>>>> right?) In the meantime, I would like to have "user.script" set to >>>>> "Latn" in such a case. >>>> >>>> Is this something that I could file a follow-on issue for? The >>>> existing >>>> code doesn't set "user.script" in these cases, either, and it looks >>>> like >>>> that would take some digging into java_props_md.c... >>> >>> Fine by me. >>> >>> Naoto >>> >>>> >>>> -Brent >>>> >>>>> On 6/22/16 2:45 PM, Brent Christian wrote: >>>>>> On 6/21/16 3:27 PM, Naoto Sato wrote: >>>>>>> Actually, j.u.Locale class' "country" code is defined as ISO-3166 >>>>>>> alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying >>>>>>> setting is "es-419" for the preferred language, "user.country" >>>>>>> should be >>>>>>> "419". >>>>>> >>>>>> OK, thanks - looks like another latent locale bug on Mac. I've >>>>>> uploaded >>>>>> output comparing the old [1] and new[2] behavior WRT java.util.Locale >>>>>> under Spanish (Latin America). It looks correct to me, based on my >>>>>> reading of Locale.toString()/getCountry()toLanguageTag(). >>>>>> >>>>>> The updated webrev is here: >>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/ >>>>>> >>>>>> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region >>>>>> designators. The es-419 mapping is no longer needed in locale_str.h. >>>>>> >>>>>> Thanks! >>>>>> -Brent >>>>>> >>>>>> 1. >>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt >>>>>> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt >>>>>> >>>>>>> On 6/21/16 3:17 PM, Brent Christian wrote: >>>>>>>> Hi, Naoto >>>>>>>> >>>>>>>> "Spanish (Latin America)" already works the same as it did before >>>>>>>> the >>>>>>>> change - it maps to "es_XL". Because "es-419" has more than 2 >>>>>>>> characters following the '-', no change is made and >>>>>>>> getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping >>>>>>>> for >>>>>>>> "es-419" -> "es_XL" in locale_str.h. >>>>>>>> >>>>>>>> System property values are (still) set to: >>>>>>>> user.language: es >>>>>>>> user.country: XL >>>>>>>> user.country.format: (2-char country code for the selected >>>>>>>> Region) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Brent >>>>>>>> >>>>>>>> On 21/06/16 14:48, Naoto Sato wrote: >>>>>>>>> Hi Brent, >>>>>>>>> >>>>>>>>> I looked at the system preference setting panel and noticed >>>>>>>>> there is >>>>>>>>> "Spanish (Latin America)", which I think uses UN M.49 code >>>>>>>>> ("es-419") as >>>>>>>>> the designate region. Can you make changes to deal with it? >>>>>>>>> (sorry I >>>>>>>>> should have noticed this earlier, and it's unfortunate not to be >>>>>>>>> able to >>>>>>>>> upcall Locale.forLanguageTag()!) >>>>>>>>> >>>>>>>>> Naoto >>>>>>>>> >>>>>>>>> On 6/20/16 4:38 PM, Brent Christian wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have an updated webrev at: >>>>>>>>>> http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/ >>>>>>>>>> >>>>>>>>>> The comments have been updated as Gerard suggested. >>>>>>>>>> >>>>>>>>>> The code to process the languageString now accounts for >>>>>>>>>> 3-character >>>>>>>>>> language codes, and 4-char script designations (line 86). >>>>>>>>>> >>>>>>>>>> More extensive testing of languages with multiple scripts/regions >>>>>>>>>> revealed that more changes were needed to maintain current >>>>>>>>>> behavior. >>>>>>>>>> Without knowing the internal workings of how >>>>>>>>>> JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language >>>>>>>>>> ID, I >>>>>>>>>> believe the best options are to add a few more mappings as >>>>>>>>>> needed to >>>>>>>>>> locale_aliases (locale_str.h), and to add a special case for >>>>>>>>>> Portuguese >>>>>>>>>> (line 104). >>>>>>>>>> >>>>>>>>>> OS X has 3 language options for Portuguese: >>>>>>>>>> Portugues (Portugal) >>>>>>>>>> Portugues (Brasil) >>>>>>>>>> Portugues (Brasileiro) >>>>>>>>>> >>>>>>>>>> CFLocaleCopyPreferredLanguages() gives the expected language code >>>>>>>>>> for >>>>>>>>>> Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" >>>>>>>>>> doesn't >>>>>>>>>> include a region code (it's simply, "pt"), so gets mapped to the >>>>>>>>>> default >>>>>>>>>> country, Portugal. To maintain current behavior, I added a >>>>>>>>>> special >>>>>>>>>> case >>>>>>>>>> to map "pt" to "pt_BR" when the Region system preference is >>>>>>>>>> set to >>>>>>>>>> Brazil. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This change introduces one notable behavior change, which I >>>>>>>>>> argue is >>>>>>>>>> actually a fix. The bug report and test case do not list the >>>>>>>>>> "Spanish >>>>>>>>>> (Mexico)" language, but it is present on MaxOS 10.9 >>>>>>>>>> (presumably it >>>>>>>>>> was >>>>>>>>>> added to the OS since the original investigation). The old code >>>>>>>>>> mapped >>>>>>>>>> this to "es_XL", XL being one of the "user-assigned" ISO 3166 >>>>>>>>>> country >>>>>>>>>> codes. The new code maps to "es_MX", MX being the country code >>>>>>>>>> for >>>>>>>>>> Mexico. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I >>>>>>>>>> tried >>>>>>>>>> every language that includes multiple scripts/locales. I also >>>>>>>>>> added a >>>>>>>>>> couple updated tests to the bug report. >>>>>>>>>> >>>>>>>>>> General testing has looked good so far. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -Brent From brent.christian at oracle.com Wed Jun 29 19:36:51 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 29 Jun 2016 12:36:51 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac Message-ID: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> Hi, Please review the following change for JDK 9: Bug: https://bugs.openjdk.java.net/browse/JDK-8160370 Webrev: http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available starting in Mac OS 10.9. While JDK 9 will not support versions of Mac OS prior to 10.9 [1], not all testing infrastructure has been updated, and we've seen failures of java/lang/System/OsVersionTest.java The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. Thanks, -Brent 1. https://jdk9.java.net/jdk9_supported_platforms.html 2. https://bugs.openjdk.java.net/browse/JDK-8156132 From gerard.ziemski at oracle.com Wed Jun 29 19:54:25 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 29 Jun 2016 14:54:25 -0500 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> Message-ID: hi Brent, Thank you for fixing the original issue and for putting in this follow-up fix! Looks good! (for full disclosure I proposed the workaround) cheers > On Jun 29, 2016, at 2:36 PM, Brent Christian wrote: > > Hi, > > Please review the following change for JDK 9: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160370 > Webrev: > http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ > > The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available starting in Mac OS 10.9. > > While JDK 9 will not support versions of Mac OS prior to 10.9 [1], not all testing infrastructure has been updated, and we've seen failures of > > java/lang/System/OsVersionTest.java > > The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. > > Thanks, > -Brent > > 1. https://jdk9.java.net/jdk9_supported_platforms.html > 2. https://bugs.openjdk.java.net/browse/JDK-8156132 From david.dehaven at oracle.com Wed Jun 29 20:08:30 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 29 Jun 2016 13:08:30 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> Message-ID: <31217EB7-D63B-4C99-9FD2-01142426E567@oracle.com> Fix looks good to me too. -DrD- > On Jun 29, 2016, at 12:54 PM, Gerard Ziemski wrote: > > hi Brent, > > Thank you for fixing the original issue and for putting in this follow-up fix! > > Looks good! (for full disclosure I proposed the workaround) > > > cheers > >> On Jun 29, 2016, at 2:36 PM, Brent Christian wrote: >> >> Hi, >> >> Please review the following change for JDK 9: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8160370 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ >> >> The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available starting in Mac OS 10.9. >> >> While JDK 9 will not support versions of Mac OS prior to 10.9 [1], not all testing infrastructure has been updated, and we've seen failures of >> >> java/lang/System/OsVersionTest.java >> >> The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. >> >> Thanks, >> -Brent >> >> 1. https://jdk9.java.net/jdk9_supported_platforms.html >> 2. https://bugs.openjdk.java.net/browse/JDK-8156132 > From brent.christian at oracle.com Wed Jun 29 23:33:30 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 29 Jun 2016 16:33:30 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: <31217EB7-D63B-4C99-9FD2-01142426E567@oracle.com> References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> <31217EB7-D63B-4C99-9FD2-01142426E567@oracle.com> Message-ID: <57745ACA.70709@oracle.com> Thank you, Dave and Gerard. I believe I still need to hear from a JDK9 Reviewer. Thanks, -Brent On 06/29/2016 01:08 PM, David DeHaven wrote: > > Fix looks good to me too. > > -DrD- > >> On Jun 29, 2016, at 12:54 PM, Gerard Ziemski wrote: >> >> hi Brent, >> >> Thank you for fixing the original issue and for putting in this follow-up fix! >> >> Looks good! (for full disclosure I proposed the workaround) >> >> >> cheers >> >>> On Jun 29, 2016, at 2:36 PM, Brent Christian wrote: >>> >>> Hi, >>> >>> Please review the following change for JDK 9: >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8160370 >>> Webrev: >>> http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ >>> >>> The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available starting in Mac OS 10.9. >>> >>> While JDK 9 will not support versions of Mac OS prior to 10.9 [1], not all testing infrastructure has been updated, and we've seen failures of >>> >>> java/lang/System/OsVersionTest.java >>> >>> The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. >>> >>> Thanks, >>> -Brent >>> >>> 1. https://jdk9.java.net/jdk9_supported_platforms.html >>> 2. https://bugs.openjdk.java.net/browse/JDK-8156132 >> > From mandy.chung at oracle.com Wed Jun 29 23:47:52 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jun 2016 16:47:52 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> Message-ID: > On Jun 29, 2016, at 12:36 PM, Brent Christian wrote: > > Hi, > > Please review the following change for JDK 9: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160370 > Webrev: > http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ > > The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available starting in Mac OS 10.9. > > While JDK 9 will not support versions of Mac OS prior to 10.9 [1], not all testing infrastructure has been updated, and we've seen failures of > > java/lang/System/OsVersionTest.java > > The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. I think we should move away from testing on unsupported platforms. Is this just temporary? when will this be removed? Mandy From gerard.ziemski at oracle.com Thu Jun 30 14:33:25 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 30 Jun 2016 09:33:25 -0500 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> Message-ID: > On Jun 29, 2016, at 6:47 PM, Mandy Chung wrote: > >> >> On Jun 29, 2016, at 12:36 PM, Brent Christian wrote: >> >> Hi, >> >> Please review the following change for JDK 9: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8160370 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ >> >> The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available starting in Mac OS 10.9. >> >> While JDK 9 will not support versions of Mac OS prior to 10.9 [1], not all testing infrastructure has been updated, and we've seen failures of >> >> java/lang/System/OsVersionTest.java >> >> The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. > > I think we should move away from testing on unsupported platforms. Is this just temporary? when will this be removed? I think we should leave the workaround code in forever - it will never execute on newer/supported OS X and will do the right thing on earlier ones. cheers From brent.christian at oracle.com Thu Jun 30 16:48:26 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 30 Jun 2016 09:48:26 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: <5A548A60-F765-477C-8BA3-44FFBD882753@oracle.com> References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> <31217EB7-D63B-4C99-9FD2-01142426E567@oracle.com> <57745ACA.70709@oracle.com> <5A548A60-F765-477C-8BA3-44FFBD882753@oracle.com> Message-ID: <01c80370-fbfd-9d46-51de-e8d0b88488ed@oracle.com> Thanks, Brian On 6/29/16 4:35 PM, Brian Burkhalter wrote: > Approved. > > Brian > > On Jun 29, 2016, at 4:33 PM, Brent Christian > wrote: > >> Thank you, Dave and Gerard. >> I believe I still need to hear from a JDK9 Reviewer. > From brent.christian at oracle.com Thu Jun 30 16:53:34 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 30 Jun 2016 09:53:34 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> Message-ID: <4bfcc3a7-59a2-fb87-f06f-e3da5c433b48@oracle.com> On 6/29/16 4:47 PM, Mandy Chung wrote: >> On Jun 29, 2016, at 12:36 PM, Brent Christian wrote: >> >> The code to restore behavior on older Mac systems is only a few >> lines, so that seems like a good way to get testing going again. > > I think we should move away from testing on unsupported platforms. > Is this just temporary? when will this be removed? When the minimum Mac build platform is SDK 10.10, we'll be able to call operatingSystemVersion directly without using msgSend. We can also consider removing this then. Thanks, -Brent From mandy.chung at oracle.com Thu Jun 30 16:56:29 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 30 Jun 2016 09:56:29 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> Message-ID: <2F331918-CB08-46BE-9BF4-4A24812F763B@oracle.com> > On Jun 30, 2016, at 7:33 AM, Gerard Ziemski wrote: > > >> On Jun 29, 2016, at 6:47 PM, Mandy Chung wrote: >> >> I think we should move away from testing on unsupported platforms. Is this just temporary? when will this be removed? > > I think we should leave the workaround code in forever - it will never execute on newer/supported OS X and will do the right thing on earlier ones. I disagree to leave dead code in our source forever (imagine the amount of code that we removed in the past were left in the source base). It may be fine to add this temporarily until our infrastructure completes migrating to supported platforms. We should track this and remove it in the future. Mandy From brent.christian at oracle.com Thu Jun 30 18:23:44 2016 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 30 Jun 2016 11:23:44 -0700 Subject: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac In-Reply-To: <4bfcc3a7-59a2-fb87-f06f-e3da5c433b48@oracle.com> References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> <4bfcc3a7-59a2-fb87-f06f-e3da5c433b48@oracle.com> Message-ID: On 6/30/16 9:53 AM, Brent Christian wrote: > > When the minimum Mac build platform is SDK 10.10, we'll be able to call > operatingSystemVersion directly without using msgSend. We can also > consider removing this then. FYI: https://bugs.openjdk.java.net/browse/JDK-8160676 -Brent