Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
The full internal version number for this update release is 1.6.0_05-b13 (where "b" means "build"). The external version number is 6u5. Included in JDK 6u5 is version 10.0 of the Java HotSpot Virtual Machine.
This update release specifies the following security baselines:
|JRE Family Version||Security Baseline|
For more information about the security baseline, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer .
After installing the 32-bit JRE on a 64-bit Windows Vista system, no Java Control Panel is present. See 6668808 for possible workarounds.
The following issues with deployment on Vista apply to JRE 1.6.0_05 and prior releases.
If you run a signed applet on a Windows OS other than Vista, you are prompted with a security warning dialog box and will need to specify an action. If you click on "Yes", the applet will have AllPermission to run on your machine; this includes permission to write/delete a file from local disk.
On Windows Vista OS, this is no longer true. Instead, AllPermission is limited to Java Applet scope. Because the process running in IE has a low integrity level, it won't be able to write/delete a file from a medium/high integrity level directory.
A signed applet running on Windows Vista has limited file access privileges compared to an applet running on another Windows OS.
Granting AllPermission in a Java Web Start application only permits the Security Manager to allow operations that it would otherwise deny by throwing SecurityExceptions. It does not in any way elevate the permissions the user or the process have on the system. A normal (non-admin) user would typically only be able to read and write files within his own home directory (unless other directories are specifically created to allow permissions to all users.)
On Windows Vista, several new behaviors were introduced in the areas of security and user experience for HTTPS connections; they are:
IE7 blocks navigation to HTTPS sites that present a digital certificate that has any of the following problems:
Upon encountering a certificate problem, IE7 presents an error page that explains the problem with the digital certificate. You may choose to ignore the warning and proceed in spite of the certificate error (unless the certificate was revoked). If you click through a certificate error page, the address bar flood fills with red to serve as a persistent notification of the problem.
You will no longer see the so-called Mixed-Content prompt, which read: This page contains both secure and nonsecure items. Do you want to see the nonsecure items?Instead, IE7 renders only the secure content and offers the user the opportunity to unblock the nonsecure content using the Information Bar.
In IE7 on Windows Vista, the default HTTPS protocol setting is changed to disable the weaker SSLv2 protocol and to enable the stronger TLSv1 protocol.
With the above changes in IE7 on Windows Vista, the user of our (Sun Microsystems Inc.) Java Plug-in will see different behavior when running their applet.
Since the posted autodl bundles cannot run on Vista (without being re-written, and re-staged for all releases), the autodl feature is turned off by default, and the entry is disabled in the advanced tab of the Control Panel.
Since the cache location must be set to a low-integrity directory, changing it is disabled in the control panel.
The extension install mechanism added to Plug-in in 1.4.2 uses Runtime.exec() to run a java extension installer (running "java -jar file"), or to run a native extension (running "file"). Normally these installers do things like write files to the lib/ext directory of the jre. These processes will run with the same limited privileges the user has, so may fail when (for example) writing a file where the user has no permission to write.
This problem would also apply to any Java Web Start application that attempts to install an extension in lib/ext (though this is not a common practice).
This new feature allows you to register your JDK installation when you interactively install the JDK with a supported browser. And it applies to the JDK for all supported OSs, both 32-bit and 64-bit.
Typically JDK Registration begins with the JDK Registration Login page that is launched in your browser after the installation completes. Log into your existing Sun Developer Network (or other Sun Online account) to register the JDK. If you do not have an existing account, you can create one during the registration process.
You can also complete JDK registration at any time after installation by opening the register.html file located in the directory where the JDK is located on your system, for example:
In the case that your system doesn't have internet connection or is in a headless environment, you can complete JDK registration from another system that supports a browser and has internet connectivity by opening the register.html file as described in the prior paragraph. You may need to copy the register.html file to the other system if it is not accessible.
Note, there is no change to the installation experience and no prompt for JDK registration when installing the JDK in the following formats:
On Windows, the checkbox with a button to launch the Readme file is no longer displayed. For a default installation, the Readme is located at C:\Program Files\Java\jdk1.6.0_05\README.html, and can be opened from a browser window at any time you wish.Known Limitation
On Solaris and Linux, the JDK registration implementation is dependent on Gnome libraries. If those libraries are unavailable, no browser will be opened. It is a known problem that Solaris 8 doesn't have the Gnome libraries unless they are explicitly installed (see 6652483).
Refer to the following for further information about JDK Product Registration:
This release contains fixes for one or more security vulnerabilities.
Other bug fixes are listed in the following table.
|6647251||java||classes_security||Add DigiCert root CA certs to JDK|
|6647254||java||classes_security||Add TrustCenter root CA certificates to the JDK|
|6651160||java||classes_security||Add AOL root CA certs to JDK|
|6624769||java||classes_util_i18n||(tz) Support tzdata2007i|
|6646197||java||classes_util_i18n||(tz) Support tzdata2007k|
|6637304||java||install||Obsolete XPIs and replace them with new jinstall.exe to cover Java Stat's xpi and jxpi metrics.|
|6622366||java||sunservicetags||JDK Product Registration Support|