Jdk-8160676 Update Java Props Macosx.c For Mac

Jdk-8160676 Update Java Props Macosx.c For Mac Average ratng: 3,9/5 9918 reviews

This page describes how to install and uninstall JDK 8 for OS X computers.

Installing Java 8 and Eclipse on Mac OS X. This page tells you how to download and install Java 8 and Eclipse on Mac OS X, and how to configure Eclipse. Installing Java 8. Go to the Oracle website. You'll see something like this. JDK 7 Installation for Mac OS X. If you have not yet installed Apple's Java Mac OS X 2012-006 update, then you are still using a version of Apple Java 6 that includes the plug-in and the Java Preferences app. See Note for Users of Macs that Include Apple Java 6 Plug-in.

This page has these topics:

See 'JDK 8 and JRE 8 Installation Start Here' for general information about installing JDK 8 and JRE 8.

See 'OS X Platform Install FAQ' for general information about installing JDK 8 on OS X.

System Requirements

Observe the following requirements:

Any Intel-based computer running OS X 10.8 (Mountain Lion) or later.
Administrator privileges.
The Aluminum Slim Wireless Keyboard was created with the Mac in mind with function hot keys, a full numeric keyboard, and a USB-C port for convenient recharging. It connects via Bluetooth 3.0. 15906 - Slimline Aluminium Keyboard for Mac This product is no longer available in the current Trust assortment. Trust slimline aluminum keyboard for mac pro. I wanted an apple aluminum keyboard but they are just too expensive for me, so I got the Macally Ultra-Slim USB wired keyboard. I am pleasantly surprised with it - the keyboard response is nice and clean. I only wish it had a USB plug so I could plug in my mouse into the keyboard (like other apple keyboards) but that is not a deal killer.

Note that installing the JDK on OS X is performed on a system wide basis, for all users, and administrator privileges are required. You cannot install Java for a single user.

Installing the JDK also installs the JRE. The one exception is that the system will not replace the current JRE with a lower version. To install a lower version of the JRE, first uninstall the current version as described in 'Uninstalling the JRE'.

JDK Installation Instructions

When you install the Java Development Kit (JDK), the associated Java Runtime Environment (JRE) is installed at the same time. The JavaFX SDK and Runtime are also installed and integrated into the standard JDK directory structure.

Rufus for mac with wine. Depending on your processor, the downloaded file has one of the following names:

jdk-8uversion-macosx-amd64.dmg
jdk-8uversion-macosx-x64.dmg

Where version is 6 or later.

Download the file.
Before the file can be downloaded, you must accept the license agreement.
From either the Downloads window of the browser, or from the file browser, double click the .dmg file to launch it.
A Finder window appears containing an icon of an open box and the name of the .pkg file.

Double click the package icon to launch the Install app.

The Install app displays the Introduction window.

Note:

In some cases, a Destination Select window appears. This is a bug, as there is only one option available. If you see this window, select Install for all users of this computer to enable the Continue button.

Click Continue.
The Installation Type window appears.
Click Install.
A window appears that says 'Installer is trying to install new software. Type your password to allow this.'
Enter the Administrator login and password and click Install Software.
The software is installed and a confirmation window appears.
Refer to http://www.oracle.com/technetwork/java/javase/downloads/jdk-for-mac-readme-1564562.html for more information about the installation.
After the software is installed, delete the .dmg file if you want to save disk space.

Determining the Default Version of the JDK

If you have not yet installed Apple's Java OS X 2012-006 update, then you are still using a version of Apple Java 6 that includes the plug-in and the Java Preferences app. See 'Note for Users of OS X that Include Apple Java 6 Plug-in'.

There can be multiple JDKs installed on a system, as many as you wish.

When launching a Java application through the command line, the system uses the default JDK. It is possible for the version of the JRE to be different than the version of the JDK.

You can determine which version of the JDK is the default by typing java -version in a Terminal window. If the installed version is 8u6, you will see a string that includes the text 1.8.0_06. For example:

To run a different version of Java, either specify the full path, or use the java_home tool:

For more information, see the java_home(1) man page.

Uninstalling the JDK

To uninstall the JDK, you must have Administrator privileges and execute the remove command either as root or by using the sudo(8) tool.

For example, to uninstall 8u6:

Do not attempt to uninstall Java by removing the Java tools from /usr/bin. This directory is part of the system software and any changes will be reset by Apple the next time you perform an update of the OS.

This change has broken the os.version property - see JDK-8160370

noreg-other: The primary issue of this bug, the failure to start up the VM from JNI in the absence of the default Mac Java, can be tested by re-enabling existing VM tests. noreg-hard: The Locale-related changes would be difficult to regtest, as they would require test machines to be setup set to particular languages.

If needed for future reference, an explanation of Apple's language and locale identifiers: https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html (BCP 47 allows 3-digit UN M.49 codes for the region, e.g. 'es-419' for Latin American Spanish, though this possibility is not called out in the tables.)

Attached the code I uses to test locales. Also attached some basic C code to list the Preferred Languages (to list all available languages, one should add them to the 'Preferred languages' list in the Language & Region system preference).

This seems to have languished. But we also seem to have moved past this on the VM side for testing purposes - can someone clarify that please.

Excluding these tests until the bug is fixed.

This is part of what will be a larger project to stop reliance on Apple's JavaVM frameworks (JDK-8024281). I've converted this bug to a subtask.We are too late in the 8 product cycle to sufficiently test all environments and locales to ensure a change to the code in question works correctly in all cases.Given this is not a new issue in 8, we're going to hold off on this until a later release.

This should be possible to work around.From a conversation with Dave: 'you need to link libjli before JavaVM.framework (or any framework that pulls JavaVM in, like JNF/JRS), it will be loaded by the executable which will force dyld to use it's version of JNI_CreateJavaVM.'

Brent - can you look at this one, it looks like it has been moved from another group to core-libs/java.lang. It looks like they are changing the properties initialization, this is code that you recently changed and not clear if we still have an issue or not.

I had Anthony and Artem review the proposed fix at https://sthinfra10.se.oracle.com/cru/CR-JDK7UCPU-92

Removing myself from the issue as this is not a hotspot, but jdk (globalization) issue, however, I will remain watching it in case anyone has questions for me.

Attaching a patch with a proposed fix.

Here is my understanding of the issue: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 jdk/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 a single client - ie. us, Java. It is a 'black box' that wraps up those SPIs that are required by Apple provided implementation of JDK and exposes them to the JDK as APIs.Now that the JDK implementation ownership has changed from Apple to us, we are left with the following issue - we don't control the JRS implementation, yet rely on Apple to support it for our JDK to continue to run. According to Apple's own comments (file java_props_macosx.c): /* Don't rely on JRSCopyOSName because there's no guarantee the value will * remain the same, or even if the JRS functions will continue to be part of * Mac OS X. So hardcode os_name, and fill in os_version if we can. */so apparently there is no guarantee that JRS will continue to be part of OS X (?), but even if it did, depending on a private framework provided by a third party (ie. Apple) just for us (JDK is the only official client allowed to call into JSR) for our code to continue to run doesn't seem like a good long term bet.Proposed solution (jdk/java_props_macosx.c):Apple has suggested that we change the initialization order of our JDK code so that any access to JSR happens only after JLI_MemAlloc symbol is available. I haven't looked into this suggestion, however, as I believe that a much better solution is to simply re-implement the JSR APIs in question and drop our reliance on JSR altogether:1. We re-implement 'setOSNameAndVersion' and instead of calling 'JRSCopyOSVersion' we use CoreFoundation APIs to look up the OS version in similar way that Apple itself does (ie. see CFCopySystemVersionString in http://www.opensource.apple.com/source/CF/CF-744.19/CFUtilities.c)2. In 'getMacOSXLocale' we 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's code then calls into 'JRSCopyCanonicalLanguageForPrimaryLanguage' to map 'language' into 'language_REGION' (ex. 'en'-->'en_US', 'fr'-->'fr_FR', etc.) I have been unable to figure out the exact algorithm that matches the 'xx' code into 'xx_XX' one (it's not as trivial as it seems on the surface), but it seems that this is not actually necessary at this code level, as the region code gets added by the code implementation above it. I have verified this with all possible settings of the language that Mac OS X allows (see 'All Mac OS X Preferred Languages List.txt' in the bug), though I would appreciate it if others (especially those living in countries other than the US) could try the 'test' attached to the bug and make sure that the returned locales make sense.3. In 'setupMacOSXLocale' we simply drop the call to 'JRSSetDefaultLocalization' for now 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. My testing, however, 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 regression, though, we will need to look into this to see whether this is an actual issue ot not - filed JDK-8024279 to track this (please see 'JFileChooserTest' attached to the bug).Followup issues:JDK-8024279 Mac OS X: should CocoaUI elements (such as Dialog Chooser) use localized messages?JDK-8024280 Mac OS X: provide JDK framework for Mac developersJDK-8024281 Mac OS X: stop relaying on Apple's JavaRuntimeFramework

Note that there's a separate bug regarding the FileDialog l10n: JDK-8019464. I see that the above tests have been performed with the JFileChooser. Does the fix have any effect on the AWT FileDialog wrt. l10n?

Changed the component from 'Hotspot' to 'Globalization' - the actual file changed is in jdk7u/jdk/src/solaris/native/java/lang/java_props_macosx.c

I can't seem to be able to attach the list of available languages as an attachment because the system complains it might contain a malware, so I will include the list as a comment: 'af', 'af_ZA', 'Afrikaans (South Africa)', 'am', 'am', 'Amharic', 'ar', 'ar', 'Arabic', 'as', 'as', 'Assamese', 'ay', 'ay', 'Aymara', 'az-Cyrl', 'az-Cyrl', 'Azerbaijani (Cyrillic)', 'az-Latn', 'az', 'Azerbaijani', 'be', 'be_BY', 'Belarusian (Belarus)', 'bg', 'bg_BG', 'Bulgarian (Bulgaria)', 'bi', 'bi', 'Bislama', 'bn', 'bn', 'Bengali', 'bo', 'bo', 'Tibetan', 'br', 'br', 'Breton', 'bs', 'bs', 'Bosnian', 'ca', 'ca_ES', 'Catalan (Spain)', 'chr', 'chr', 'Cherokee', 'co', 'co', 'Corsican', 'cs', 'cs_CZ', 'Czech (Czech Republic)', 'cy', 'cy', 'Welsh', 'da', 'da_DK', 'Danish (Denmark)', 'de', 'de_DE', 'German (Germany)', 'de-AT', 'de_AT', 'German (Austria)', 'de-CH', 'de_CH', 'German (Switzerland)', 'dz', 'dz_BT', 'Dzongkha (Bhutan)', 'el', 'el_GR', 'Greek (Greece)', 'en', 'en_US', 'English (United States)', 'en-AU', 'en_AU', 'English (Australia)', 'en-CA', 'en_CA', 'English (Canada)', 'en-GB', 'en_GB', 'English (United Kingdom)', 'en-US', 'en_US', 'English (United States)', 'eo', 'eo', 'Esperanto', 'es', 'es_ES', 'Spanish (Spain)', 'es-419', 'es_XL', 'Spanish (XL)', 'es-ES', 'es_ES', 'Spanish (Spain)', 'et', 'et_EE', 'Estonian (Estonia)', 'eu', 'eu', 'Basque', 'fa', 'fa_IR', 'Persian (Iran)', 'fi', 'fi_FI', 'Finnish (Finland)', 'fo', 'fo_FO', 'Faroese (Faroe Islands)', 'fr', 'fr_FR', 'French (France)', 'fr-CA', 'fr_CA', 'French (Canada)', 'fr-CH', 'fr_CH', 'French (Switzerland)', 'ga', 'ga_IE', 'Irish (Ireland)', 'gd', 'gd', 'Scottish Gaelic', 'gl', 'gl', 'Galician', 'gn', 'gn', 'Guarani', 'gsw', 'gsw', 'Swiss German', 'gu', 'gu_IN', 'Gujarati (India)', 'gv', 'gv', 'Manx', 'haw', 'haw', 'Hawaiian', 'he', 'he_IL', 'Hebrew (Israel)', 'hi', 'hi_IN', 'Hindi (India)', 'hr', 'hr_HR', 'Croatian (Croatia)', 'ht', 'ht', 'Haitian', 'hu', 'hu_HU', 'Hungarian (Hungary)', 'hy', 'hy_AM', 'Armenian (Armenia)', 'id', 'id', 'Indonesian', 'io', 'io', 'Ido', 'is', 'is_IS', 'Icelandic (Iceland)', 'it', 'it_IT', 'Italian (Italy)', 'iu', 'iu_CA', 'Inuktitut (Canada)', 'ja', 'ja_JP', 'Japanese (Japan)', 'ka', 'ka_GE', 'Georgian (Georgia)', 'kk', 'kk', 'Kazakh', 'kl', 'kl', 'Kalaallisut', 'km', 'km', 'Khmer', 'kn', 'kn', 'Kannada', 'ko', 'ko_KR', 'Korean (South Korea)', 'kok', 'kok', 'Konkani', 'kw', 'kw', 'Cornish', 'ky', 'ky', 'Kirghiz', 'ky-Cyrl', 'ky', 'Kirghiz', 'la', 'la', 'Latin', 'lb', 'lb', 'Luxembourgish', 'lo', 'lo', 'Lao', 'lt', 'lt_LT', 'Lithuanian (Lithuania)', 'lv', 'lv_LV', 'Latvian (Latvia)', 'mg', 'mg', 'Malagasy', 'mi', 'mi', 'Maori', 'mk', 'mk_MK', 'Macedonian (Macedonia)', 'ml', 'ml', 'Malayalam', 'mn', 'mn', 'Mongolian', 'mr', 'mr_IN', 'Marathi (India)', 'ms', 'ms', 'Malay', 'mt', 'mt_MT', 'Maltese (Malta)', 'my', 'my', 'Burmese', 'nap', 'nap', 'Neapolitan', 'nb', 'nb_NO', 'Norwegian Bokm��l (Norway)', 'ne', 'ne_NP', 'Nepali (Nepal)', 'nl', 'nl_NL', 'Dutch (Netherlands)', 'nl-BE', 'nl_BE', 'Dutch (Belgium)', 'nn', 'nn_NO', 'Norwegian Nynorsk (Norway)', 'nv', 'nv', 'Navajo', 'oc', 'oc', 'Occitan', 'om', 'om', 'Oromo', 'or', 'or', 'Oriya', 'pa', 'pa', 'Punjabi', 'pl', 'pl_PL', 'Polish (Poland)', 'ps', 'ps', 'Pashto', 'pt', 'pt_BR', 'Portuguese (Brazil)', 'pt-BR', 'pt_BR', 'Portuguese (Brazil)', 'pt-PT', 'pt_PT', 'Portuguese (Portugal)', 'qu', 'qu', 'Quechua', 'rn', 'rn', 'Rundi', 'ro', 'ro_RO', 'Romanian (Romania)', 'ru', 'ru_RU', 'Russian (Russia)', 'rw', 'rw', 'Kinyarwanda', 'sa', 'sa', 'Sanskrit', 'scn', 'scn', 'Sicilian', 'se', 'se', 'Northern Sami', 'si', 'si', 'Sinhala', 'sk', 'sk_SK', 'Slovak (Slovakia)', 'sl', 'sl_SI', 'Slovenian (Slovenia)', 'so', 'so', 'Somali', 'sq', 'sq', 'Albanian', 'sr', 'sr_CS', 'Serbian (Serbia and Montenegro)', 'sv', 'sv_SE', 'Swedish (Sweden)', 'sw', 'sw', 'Swahili', 'ta', 'ta', 'Tamil', 'te', 'te', 'Telugu', 'tg', 'tg', 'Tajik', 'th', 'th_TH', 'Thai (Thailand)', 'tk-Cyrl', 'tk-Cyrl', 'Turkmen (Cyrillic)', 'tk-Latn', 'tk-Cyrl', 'Turkmen (Cyrillic)', 'tl', 'fil', 'Filipino', 'tlh', 'tlh', 'Klingon', 'to', 'to_TO', 'Tongan (Tonga)', 'tr', 'tr_TR', 'Turkish (Turkey)', 'tt-Cyrl', 'tt-Cyrl', 'Tatar (Cyrillic)', 'tt-Latn', 'tt-Cyrl', 'Tatar (Cyrillic)', 'ug', 'ug', 'Uighur', 'uk', 'uk_UA', 'Ukrainian (Ukraine)', 'ur', 'ur_PK', 'Urdu (Pakistan)', 'uz', 'uz_UZ', 'Uzbek (Uzbekistan)', 'uz-Cyrl', 'uz_UZ', 'Uzbek (Uzbekistan)', 'uz-Latn', 'uz_UZ', 'Uzbek (Uzbekistan)', 'vi', 'vi_VN', 'Vietnamese (Vietnam)', 'wa', 'wa', 'Walloon', 'yi', 'yi', 'Yiddish', 'zh-Hans', 'zh_CN', 'Chinese (China)', 'zh-Hant', 'zh_TW', 'Chinese (Taiwan)', 'zu', 'zu', 'Zulu'

Attaching JFileChooser showing whether the CocoaUI file dialog uses localized strings.

Adding basic Java test showing locales.

Adding NetBeans test printing locale and using Open File Dialog.

I have replaced the 3 out of 4 APIs we were using in JavaRuntimeSupport.The 4th API, ie. JRSSetDefaultLocalization, according to Apple is used to set locale of bundle, so that the strings in Cocoa components, such as Open File Dialog, show according to the locale, but from my testing this doesn't appear to work.Is JFileChooser using localized strings (ie. Open) if locale is set either using System Preferences (ie. 'Language & Text'), or overriden using Java command parameter (ie. -Duser.language=pl -Duser.country=PL):Java...........System Preferences......Java commandJDK6 (Apple).....YES.................NOJDK7..........NO..................NOJDK8 (original)....NO..................NOJDK8 (fix).......NO..................NOSo, it appears this used to work (using System Preferences to change the locale) for JDK6, but starting with JDK7, this no longer works, so this API seems to be a NOP in JDK7,JDK8The conclusion then are that this API does not need to be implemented at this time, though we do have a bigger issue with localization that seems to have regressed since JDK6. We'll need a new issue filed to address this.

This is the reason we end up invoking OS system Java warning - we pull in system JavaRuntimeSupport library by java_props_macosx.cstatic void *getJRSFramework() { static void *jrsFwk = NULL; if (jrsFwk NULL) { jrsFwk = dlopen('/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport', RTLD_LAZY RTLD_LOCAL); } return jrsFwk;}

Verified (using dladdr) that in fact the JNI_CreateJavaVM method called is the from our own jdk that we link against, ex: JNI_CreateJavaVM found in /Volumes/work/jdk/jdk8/build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/libjvm.dylibAfter debugging JNI_CreateJavaVM it seems that it does not return in the case where the OS reports it needs to install Java. Looking deeper into it, we exit from:Threads::threads_do at the time it tries to call: // The VM creates & returns objects of this class. Make sure it's initialized. initialize_class(vmSymbols::java_lang_Class(), CHECK_0);

A simple workaround would be to dynamically look up JNI calls using our own jvm directly.I will continue to investigate, however, how we can tell the OS to load our jvm before its own.

> otool -LD jnijni: @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)Even though we explicitly link against our own jvm lib using '-L /Volumes/work/bugs/7131356/jnimac/jre1.7.0_25.jre/Contents/Home/lib/server -ljvm' the linker uses @rpath to reference the library and later at the launch time again despite the fact that we set 'DYLD_INSERT_LIBRARIES=$JAVA_HOME/lib/server/libjvm.dylib DYLD_LIBRARY_PATH=$JAVA_HOME/lib/server' the system seems to prefer the OS built-in jvm lib, which throws the error about 'Java not installed' on vanillla OSes.

Please check if this is an installation issue or a runtime issue.