<i18n dev> RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]
brent.christian at oracle.com
Mon Jun 13 20:58:23 UTC 2016
Please review this Mac-only fix:
Thanks go to Gerard Ziemski for the thorough investigation and detailed
write-up in the bug report.
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.
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.
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
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
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(), 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).
More information about the i18n-dev