Mac How To Edit Info.Plist For Java 1.7

These documentation pages are no longer current. They remain available for archival purposes. Please visit https://docs.oracle.com/javase for the most up-to-date documentation.

Mac How To Edit Info.plist For Java 1.7 32-bit
Mac How To Edit Info.plist For Java 1.7.10

I got an Java application that does run under Java 1.8 without problems when I start its JAR directly. However on my Mac the JAR is wrapped within an app that demands me to install Java 1.6 - which I really do not want to do! The Info.plist file in the Contents folder is probably the most significant element of any Mac OS X application. For Java applications, this file is used to specify information for the JVM execution of the application. Icons for the Mac OS X Finder are placed in the Resources folder. The preferred format is the proprietary Mac OS X file type designated by the.icns suffix, as this file type.

Contents

JRE Expiration Date

As of the JDK 7u10 release, a user may control, via the Java Control Panel, the level of security that will be used when running Java apps in a browser. The user may select from four levels of security, including disabled, where no Java apps are allowed to run in the browser.

These security levels apply to running Java in the browser, which includes plugin applets, Java Web Start applications, embedded JavaFX applications, and access to the native deployment toolkit plugins. Setting the security level does not affect desktop (also called stand-alone) applications. Note that applets and these various types of applications are collectively referred to as apps or Java apps.

Ensuring the Most Secure JRE

Before the browser plugin software attempts to run a Java app, it verifies that the JRE version is at or above the security baseline for that family and that the age of the JRE is recent. If the JRE is determined to be below the security baseline, or if unable to verify the baseline and the current date is past the JRE Expiration Date, additional security warnings are displayed, or in some cases, the app is blocked. If the app is not automatically blocked, the user has the option to block the app, to continue running the app, or to go to java.com to download the latest release. The JRE Expiration Date can be found in the release notes for JDK Update releases starting with JDK 7u21.

JRE Expiration Date

The JRE relies on periodic checks with an Oracle Server to determine if the JRE is still considered up-to-date with all the available security fixes (above the security baseline). In the past, if the JRE was unable to contact the Oracle Server, the JRE continued to behave as though it is the most recent version with regard to security for an indefinite period.

To avoid this problem, a secondary mechanism that does not rely on external communication has been added to the JDK 7u10 release. From the 7u10 release onwards, all JREs contain a hard-coded expiration date. The expiration date is calculated to end after the scheduled release of the next Critical Patch Update.

JREs that are unable to contact Oracle Servers for an extended period of time now offer additional protection after a reasonable period and do not continue to behave as if they were up-to-date with regard to security fixes.

To test what happens when the JRE falls below the security baseline or expires, see Testing a JRE Below the Security Baseline and Testing an Expired JRE.

Testing a JRE Below the Security Baseline

To see how applications behave when the JRE falls below the Security Baseline, follow these steps:

Install the JRE that you want to test.
Remove the following files, if they exist:
- <user-deployment-home>/deployment.properties
- <user-deployment-home>/security/baseline.versions
- <user-deployment-home>/security/update.timestamp
See Deployment Configuration File for the location of the deployment.properties file on each supported platform.
From the command line, run the following command:
javaws -SSVBaselineUpdate
The <user-deployment-home>/security/baseline.versions file is downloaded.
Edit the <user-deployment-home>/security/baseline.versions file.
Set the version number of the JRE for the JRE family that you are testing to a value greater than the version that you are testing. For example, if you are testing JRE version 7u45, set the version in the file to 1.7.0_99. The JRE periodically updates this file, so make the file read-only to prevent your changes from being overwritten.
Run any Java applet or Java Web Start application.
The Java Update Needed prompt is shown. Click Later to continue running the application. See Why do I see the Java Update Needed messages? on java.com for information on this prompt.
When you are done testing, repeat Step 2 and Step 3 to restore the correct version of the files.

Testing an Expired JRE

To see how applications behave after the JRE has expired, follow these steps:

Install the JRE that you want to test.
Remove the following files, if they exist:
- <user-deployment-home>/deployment.properties
- <user-deployment-home>/security/baseline.versions
See Deployment Configuration File for the location of the deployment.properties file on each supported platform.
Set the system to a future date beyond the expiration date of the JRE. Get the expiration date from the Release Notes for the release that you are testing.
Run any Java applet or Java Web Start application.
The Java Update Needed prompt is shown. Click Later to continue running the application. See Why do I see the Java Update Needed messages? on java.com for information on this prompt.

Disabling Java in the Browser

If you prefer to completely disable access to Java through the browser, de-select the Enable Java content in the browser option in the Java Control Panel under the Security tab. If you do not need to run Java through a browser, consider installing the Server JRE, which does not contain the Java Plug-In. See Server JRE (Java SE Runtime Environment) 7 Downloads for information.

Setting the Security Level

Note: These settings affect all browsers that use Oracle's Java browser plug-in. They do not affect stand-alone Java apps.

The Security tab of the Java Control Panel contains a Security Level slider that controls the restrictions placed on any app that is run from the web or from the local system. The user can select medium, high or very high security settings. The settings determine if an app is allowed to run and if so, the warnings you must accept before the app is launched. The warnings contain information about the signing status of the app, the location of the app, and whether the app is requesting enhanced permissions to run outside the security sandbox.

Unsigned apps that request enhanced permissions are not allowed to run, regardless of the Security Level setting. At the Very High setting, only apps signed with a valid certificate are allowed to run. For information on all security levels, see the Security section of the Java Control Panel documentation.

The default security level is High.

The ability to run applications is also affected by the settings of the Security Options for a Secure Execution Environment.

Security Options for a Secure Execution Environment

To select the behavior when attempting to run an app, there are several checkboxes available in the Java Control Panel (under the Advanced tab):

Allow user to grant permissions to signed content
Show sandbox warning banner
Allow user to accept JNLP security requests
Don't prompt for client certificate selection when no certificates or only one exists
Warn if site certificate does not match hostname
Show site certificate even if it is valid

Install Options

In the JDK 7u10 release, new arguments for command line installation are available for setting the security level for Java in the browser. Admin privileges are required to install the JRE. These arguments are available only on Microsoft Windows.

On installation, the WEB_JAVA argument has the following effect:
WEB_JAVA=1 enables Java in the browser
WEB_JAVA=0 disables Java in the browser
On installation, the WEB_JAVA_SECURITY_LEVEL argument has the following effect:
WEB_JAVA_SECURITY_LEVEL=VH sets the security level to very high
WEB_JAVA_SECURITY_LEVEL=H sets the security level to high
WEB_JAVA_SECURITY_LEVEL=M sets the security level to medium

After installation of the JRE, you can check the Java Control Panel to verify that the security level settings are correct.

Apps with Mixed Code

This information also applies to untrusted apps that have signed trusted extensions, but not to signed trusted apps that have unsigned untrusted extensions. For more information, see Mixing Privileged Code and Sandbox Code.