The Java Control Panel includes the following tabs:
Every tab contains a search field. Use this field to find settings related to the search term entered.
The Java Control Panel maintains settings that manage how Java and JavaFX applications embedded in or launched from a browser are run.
Note:
Although available and supported in JDK 9, the Applet API and the Java Plug-in are marked as deprecated in preparation for removal in a future release. Alternatives for applets and embedded JavaFX applications include Java Web Start and self-contained applications.In JDK 9, the Java Control Panel was rewritten as a JavaFX application and the location of some functions has changed.
To start the Java Control Panel from the command line, enter <JRE installation home>\bin\javacpl.exe on Windows, or <JRE installation home>/bin/jcontrol on macOS or Linux. The Java Control Panel provides the following capabilities:
View and delete temporary files used by the Java Plug-in, which runs applets and JavaFX applications that are embedded in a browser, and by Java Web Start, which enables you to run Java and JavaFX applications over the network.
Update your version of the Java platform so that you always have the latest Java Runtime Environment (JRE).
Manage the JREs on your system and set runtime parameters for them.
Manage certificates.
View the active deployment rule set on your system, if any.
Manage the exception site list for your system.
Configure proxy settings.
Enable enhanced security restrictions for Java and JavaFX applications embedded in or launched from a browser.
Configure settings for debugging, applet handling, and other functions.
Search the Java Control Panel for settings to configure.
The General tab shows the version of the Java runtime (JRE) that you are running and the security status of the JRE.
The JRE that is running is identified by the Java version number and the build number. Security status is determined by the following attributes:
Security Baseline - Minimum recommended update for Java.
Expiration Date - Date related to the scheduled release of the next Critical Patch Update. After the expiration date, additional security fixes might be available.
If your JRE is below the security baseline or past the expiration date, you are encouraged to upgrade to the latest version.
The Update tab shows when the check for updates is done and enables you to change the settings for the update process.
Automatic updates are supported only on Microsoft Windows and macOS. The update feature works with the Java Update Scheduler (jusched.exe) to provide you with the latest Java updates. You must have Administrative privileges to update the JRE.
From this tab, you can automatically or manually update the system JRE that is installed. If you have more than one JRE installed, the Desktop Settings tab shows you which JRE is considered the system JRE. See Desktop Settings Tab in the Java Control Panel.
The Update tab provides the options shown in the following table, not all options are available on both platforms:
| Option | Description |
|---|---|
|
Notify me before an update is |
Indicates when you want to be notified that an update is available. The options are:
|
|
Automatically check for updates (Recommended) |
Indicates if the check for updates is done automatically. This option is enabled by default. The time when the check is scheduled is shown. See Scheduling the Check for Updates to set the schedule. |
|
Check Now |
Checks for updates when clicked. The time of the last check is shown above the button. |
|
Download the latest version of Java from |
Provides a link to where you can download the latest JRE. |
Set the time and frequency for automatic updates of your JRE from the Update tab of the Java Control Panel. A manual check can be done at any time from the same tab.
You must have Administrative privileges to update the JRE. The following instructions are for Microsoft Windows. Not all options are available for macOS. To check for an update:
To immediately check for an update, click Check Now. The time of the last check is shown above the button.
To schedule an automatic check for updates:
Select Automatically Check for Updates. Your JREs are updated automatically on a schedule that you set.
From the Notify Me Before an Update is drop-down list, choose to be notified either before the update is downloaded, or after the update is downloaded but before the update is installed.
Click the date and time shown for Check for Updates to set up the schedule for updates.
The Automatic Update Advanced Settings window is shown.
Select how often you want the check to run and the day and time to run it.
Choose Daily, Weekly, or Monthly. For daily updates, select the time of the day for the update. For weekly updates, select the day of the week and the time of the day. For monthly updates, select the day of the week and the time of the day. Monthly updates check weekly and notify you within 30 days that an update is available. However, if an update is considered critical, you are notified within a week of its release.
Close the Automatic Update Advanced Settings window to see your selection in the Update tab.
Click Apply to save your changes, or OK to save your changes and close the Java Control Panel.
On Microsoft Windows platforms, the Java Update Scheduler, jusched.exe, is used to launch automatic updates when the option to update automatically is selected in the Update tab. jusched.exe runs as a background process that launches the Update Manager at predefined intervals set by the in the Update tab of the Java Control Panel. The Update Manager coordinates the update process.
jusched.exe is launched when the user reboots the computer after installing the JDK or JRE. It is normally transparent to the user, but can be viewed in the Processes tab of the Windows Task Manager. If you do not want the scheduler to run, use the End Process button of the Processes tab to kill the process.
The Desktop Settings tab shows information about the JREs that are installed on your system and enables you to choose the JREs that you want to use to run applications that are embedded in a web page or launched from a browser.
The following table describes the information that is shown for each JRE found on your computer:
| Setting | Description |
|---|---|
|
Web Enabled |
Flag that indicates which of the JRE versions are considered when running an application using Java Plug-in or Java Web Start. Settings in the Java Control Panel do not apply to standalone or self-contained applications. If the check box for a JRE is not selected, then Java Plug-in and Java Web Start will not use the JRE to launch Java applications. However, the current JRE might be used even if it is not marked as enabled. Note: If Java content in the browser is disabled in the Security tab of the Java Control Panel, enabling the JRE in the Desktop Settings tab has no effect. |
|
Platform |
Java platform number for the JRE, for example, |
|
Product |
Full version number of the JRE, including the update number, for example, |
|
Architecture |
Architecture of the JRE |
|
Type |
Type of JRE found, which is one of the following values:
|
|
Path |
Full path to the JRE |
|
Runtime Parameters |
Optional custom options used to override the Java Plug-in default startup parameters, see Java Runtime Parameters |
The table always has at least one entry, which is the most recently installed JRE. This is the JRE that is associated with the Java Control Panel.
On Microsoft Windows all of the JREs that are installed on a computer are shown. The Java Control Panel finds the JREs by looking in the registry. On Solaris, Linux, and macOS, the JRE that Java Web Start or Java Plug-in is using to deploy applications is the JRE that is considered registered. Use the Add and Remove buttons to change which JREs are listed in the table, see Editing Desktop Settings. On macOS, only the currently installed JRE is displayed, JDKs are not included.
JREs can be added and removed from the table in the Desktop Settings tab and runtime parameters can be set for each JRE.
The following functions are available for managing JREs on a computer:
To change the runtime parameters for a user JRE, select the JRE, click the cell in the Runtime Parameters column, and edit the value.
To add a JRE to the table, click Add. Browse to the location of the JRE and select the home folder.
To remove a JRE from the table, select the JRE and click Remove.
The System JRE cannot be removed.
To override Java Plug-in default startup parameters, specify custom options in the Runtime Parameters column for a JRE shown in the Desktop Settings tab of the Java Control panel.
Note:
Although available and supported in JDK 9, the Java Plug-in has been marked as deprecated in preparation for removal in a future release. Alternatives for applets and embedded JavaFX applications, which require the plug-in, include Java Web Start and self-contained applications.With the exception of setting classpath and cp, the syntax is the same as that used with parameters for the java command line invocation.
The following sections provide examples of Java runtime parameters:
See the java command in Java Platform, Standard Edition Tools Reference for a full list of command line options.
The following format should be used for setting classpath or cp in Java Plug-in. It differs slightly from the java command line format, which uses a space instead of the equal (=) sign.
-classpath=path -cp=path
-cp=C:\apps\java\MyClasses;C:\java\OtherClasses
-cp=apps/java/MyClasses:/java/OtherClasses
System properties are used to enable and disable assertion support.
The following system property is used to enable assertion support:
-[ enableassertions | ea ][:<package name>"..." | : <class name> ]
The following system property is used to disable assertion in the Java Plug-in:
-[ disableassertions | da ][:<package name>"..." | : <class name> ]
Assertion is disabled in Java Plug-in code by default. The effect of assertion is determined during Java Plug-in startup. If you change the assertion settings in the Java Plug-in Control Panel, you must restart the browser for the new settings to take effect.
Because Java code in Java Plug-in also has built-in assertion, it is possible to enable the assertion in Java Plug-in code using the following parameter:
-[ enableassertions | ea ]:sun.plugin
Tracing is a facility to redirect any output in the Java Console to a trace file (plugin<random-number>.trace or javaws<random-number>.trace). Use the following parameters to turn on tracing:
-Ddeployment.trace=true -Ddeployment.trace.option=basic|net|security|ext|liveconnect
If you do not want to use the default trace file name, use the following parameter to specify a different name:
-Ddeployment.trace.filename=<tracefilename>
Similar to tracing, logging is a facility to redirect any output in the Java Console to a log file (plugin<random-number>.log or javaws<random-number>.log) using the Java Logging API. Use the following parameter to turn on logging:
-Ddeployment.logging=true
If you do not want to use the default log file name, use the following parameter to specify a different name:
-Ddeployment.log.filename=<logfilename>
Furthermore, if you do not want to overwrite the trace and log files each session, you can use the following parameter:
-Ddeployment.outputfiles.overwrite=false
Tracing and logging set through the Java Control Panel take effect when the Plug-in is launched. However, changes made through the Java Control Panel while a Plug-in is running have no effect until a restart.
The following parameters are used when debugging applets in the Java Plug-in:
-Djava.compiler=NONE -Xnoagent -Xdebug -Xrunjdwp:transport=dt_shmem,address=<connect-address>,server=y,suspend=n
The <connect-address> can be any string, for example, 2502, which is used by the Java Debugger (jdb) later to connect to the JVM.
Note:
Although available and supported in JDK 9, the Applet API and the Java Plug-in are marked as deprecated in preparation for removal in a future release. Alternatives for applets and embedded JavaFX applications include Java Web Start and self-contained applications.The default network timeout value for all HTTP connections is two minutes. You can override this setting by using the following parameter:
-Dsun.net.client.defaultConnectTimeout=value-in-milliseconds
Another networking property that you can set is sun.net.client.defaultReadTimeout, as shown in the following example:
-Dsun.net.client.defaultReadTimeout=value-in-milliseconds
Note:
Java Plug-in does not set sun.net.client.defaultReadTimeout by default. If you want to set it, do so through the Java Runtime Parameters as shown above.
The following networking parameters can also be used to set the connect and read timeout values for the protocol handlers used by java.net.URLConnection. The default value set by the protocol handlers is -1, which means there is no timeout set.
sun.net.client.defaultConnectTimeout specifies the timeout in milliseconds to establish the connection to the host. For example, for HTTP connections, it is the timeout when establishing the connection to the HTTP server. For FTP connections it is the timeout when establishing the connection to FTP servers.
sun.net.client.defaultReadTimeout specifies the timeout in milliseconds when reading from an input stream when a connection is established to a resource.
The Web Settings tab contains the following tabs:
The Exception Site List tab in the Web Settings tab enables you to manage Rich Internet Applications (RIAs) that users want to run even if the RIAs are normally blocked by security checks.
RIAs from the locations listed are allowed to run with applicable security prompts. Use the following controls to manage the list:
Click Add to add a location.
Select an entry and click Remove to remove a location.
Double-click an entry to edit it.
Use the Filter field to search the list for sites that contain the search term.
The following rules apply to the format of the location URL:
A protocol is required.
Supported protocols are HTTPS (https://), HTTP (http://), and FILE (file:///). HTTPS is recommended. FILE and HTTP protocols are considered a security risk.
A domain is required.
Wildcards are not supported. If only a domain is provided, any RIA from that domain is allowed to run. A domain can have multiple entries, for example, https://www.example.com and http://www.example.com.
A port number is required only if the default port is not used.
A path is optional.
Wildcards are not supported. If the path ends with a slash, for example, file:///C:\local\apps\, RIAs in that directory and any subdirectory are allowed to run. If the path does not end with a slash, for example, file:///C:\local\apps\applet.html, only that specific RIA is allowed to run.
The format must be the same as the format used for the RIA URL or href attribute.
For example, https://www.example.com/sample/app/sample1/../sample2 and https://www.example.com/sample//app/sample2 are not considered matches to https://www.example.com/sample/app/sample2.
The Deployment Rule Set tab in the Web Settings tab shows the active deployment rule set, which manages the running and blocking of Rich Internet Applications (RIAs).
If an active deployment rule set is installed on the system, the following information is shown:
Notice that the rule set is valid or a warning that it is not valid
Text box that shows the rules in the Rules tab and information about the certificate used to sign the rule set in the Certificate Details tab
Timestamp of the rule set signature
Location of the rule set
Expiration date of the rule set signature
When a rule set is available, the rules determine if a RIA is run without security prompts, run with security prompts, or blocked. Deployment rules and rule sets are described in Deployment Rule Set.
The Temporary Files Settings tab in the Web Settings tab enables you to manage files that are cached for applications that are embedded in a web page or launched from a web page.
From this tab, you can perform the following actions:
Select if you want to keep temporary files on your computer.
Set the location where temporary files are kept.
Set the compression level for JAR files that are cached. The higher the compression level, the more compressed the file.
Set the amount of disk space for storing temporary files.
Delete temporary files by clicking Delete Files , which shows the Delete Files and Applications dialog. From this dialog, you can select the types of files that you want to delete:
Trace and Log Files
Cached Applications and Applets
Installed Applications and Applets
Restore default settings for the Temporary Files Settings dialog by clicking Restore Defaults .
The Network Settings tab in the Web Settings tab enables you to configure your connection to the network.
The available options are shown in the following table:
| Setting | Description |
|---|---|
|
Use browser settings |
Select this option to use the browser default proxy settings. This is the default setting. |
|
Use proxy server |
Select this option to provide the address and port number of the proxy server that you want to use. The option to bypass the proxy server for local addresses is available. To provide separate addresses for different protocols, click Advanced. You can also specify address that bypass the proxy server. |
|
Use automatic proxy configuration script |
Select this option to specify the URL for the JavaScript file ( |
|
Direct Connection |
Select this option if you do not want to use a proxy. |
The Java Cache Viewer tab in the Web Settings tab shows the applications, resources, and deleted applications stored in the Java cache.
From this tab, you can perform the following actions for users or for the system by using the icons or by right-clicking an application:
For applications:
Run applications.
Visit the Web page of applications.
View the JNLP file of applications.
Install shortcuts to applications.
Remove applications from the list. Applications are moved to the list of deleted applications.
For resources:
View JNLP file resources.
Remove resources.
For deleted applications:
Install deleted applications.
Remove applications from the cache.
View JNLP file resources.
Install deleted applications.
The Security tab contains the following tabs:
The General tab of the Security tab shows the security settings that are in place. This tab also enables you to restore security prompts.
The following table shows the options that are available.
| Option | Description |
|---|---|
|
Enable Java Content in the Browser |
Enables Java applications to be run in a browser or launched from a browser. To prevent these types of applications from running, do not select this option. This option is selected by default. |
|
Enable enhanced security restrictions |
Adds the additional restriction of requiring that the system must be able to check the revocation status of the certificate used to sign the application, or the application is blocked. If not selected, applications that are signed with a valid certificate that is located in the Signer CA keystore, and include the Permissions attribute in the manifest for the main JAR file are allowed to run with security prompts. This option is not selected by default. |
|
Restore Security Prompts |
Restores the security prompts that were previously hidden. When asked to confirm the selection, click Restore All. The next time an application is started, the security prompt is shown. To insure the continued security of your system, it is recommended that you periodically restore the prompts that were hidden. Seeing the prompts again provides an opportunity to review the applications and ensure that you still want them to run. |
User-level and system-level certificates used to verify RIAs that you run can be managed from the Manage Certificates tab of the Security tab.
From this tab, you can import, export, remove, and view the details for certificates. Information is provided for the following types of certificates:
Trusted Certificates - Certificates for signed RIAs that are trusted.
Secure Site - Certificates for secure sites.
Signer CA - Certificates of Certificate Authorities (CAs) who issue the certificates to the signers of trusted certificates.
Secure Site CA - Certificates of CAs who issue the certificates for secure sites.
Client Authentication - Certificates used by a client to authenticate itself to a server.
You can export, import, remove, and view the details of user-level certificates using the buttons provided in the Certificates dialog. To export, remove, or view the details, first select a certificate from the list.
The following table shows the default location of the keystore files.
Table 9-1 Default Keystore Location
| Operating System | Location |
|---|---|
|
Solaris, Linux, macOS |
|
|
Microsoft Windows |
|
For example, the default location on Microsoft Windows 7 for user jsmith is
C:\Users\jsmith\AppData\LocalLow\Sun\Java\Deployment\security
To specify a user-level keystore in a location other than the default location, set properties in the user-level deployment.properties file. The following table describes the property to set for each type of certificate.
Table 9-2 Properties for User-Level Keystore Locations
| Certificate Type | Property Name |
|---|---|
|
Trusted Certificates |
|
|
Secure site |
|
|
Signer CA |
|
|
Secure site CA |
|
|
Client Authentication |
|
You can export and view the details of system-level certificates using the buttons provided in the Certificates dialog. System-level certificates cannot be imported or removed by an end user.
Trusted, Secure Site, and Client Authentication certificate keystore files do not exist by default. The following table shows the default location for the Signer CA keystore file.
Table 9-3 Default Location for the Signer CA Keystore
| Operating System | Location |
|---|---|
|
Linux, or macOS |
|
|
Microsoft Windows |
|
The following table shows the default location for the Secure Site CA keystore.
Table 9-4 Default Location for the Secure Site CA Keystore
| Operating System | Location |
|---|---|
|
Solaris, Linux, or macOS |
|
|
Microsoft Windows |
|
To specify a system-level keystore in a location other than the default location, set properties in the system-level deployment.properties file. The System-Level deployment.properties file does not exist by default. The following table describes the property to set for each type of certificate.
Table 9-5 Properties for System-Level Keystore Locations
| Certificate Type | Property Name |
|---|---|
|
Trusted Certificates |
|
|
Secure site |
|
|
Signer CA |
|
|
Secure site CA |
|
|
Client Authentication |
|
The following options are available:
Enable tracing, logging, and the showing of applet lifecycle exceptions by selecting the appropriate check boxes. If the boxes are not checked, the options are disabled.
The Java Console is a debugging aid for Java applets and Java Web Start applications. System.out and System.err messages and tracing and logging output are shown in the console.
The following choices for viewing the console are available:
Show the console
Hide the console (default)
Do not start the console
This option provides the following choices for Java Web Start for creating shortcuts on the desktop, select only one:
Always allow
Ask user if untrusted (default)
Always ask user
Never allow
This option enables you to associate files with the JNLP MIME type. The following choices are available, select only one:
Always allow
Prompt user (default)
Never allow
The following choices are available, select only one:
Install if hinted (default)
Install if shortcut created
Install if hinted and shortcut
Never install
A Java application or applet that is launched with Java Web Start can either be installed or cached on the client computer. If the Java application is cached, then Java Web Start stores the entire application in its cache; the application is removed from the client computer when Java Web Start empties its cache. If the Java application is installed, then the application has an entry in the Add or Remove Programs applet in Windows Control Panel.
A Java application or applet can specify if it prefers to be cached or installed; if the Java application specifies that it prefers to be installed, then it is hinted. By default, Java applications that are hinted are installed on the client computer. You can also specify that a Java application is installed if it creates a shortcut on the client computer's desktop.
The following choices are available, more than one can be selected:
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 from server even if it is valid (not checked by default)
The following choices are available, select only one:
Enable - show warning if needed (selected by default)
Enable - hide warning and run with protections
Enable - hide warning and don't run untrusted code
Disable verification (not recommended)
Before a signed applet or Java Web Start application is run, the certificates used to sign the JAR file can be checked to ensure that none have been revoked. You can have all certificates checked, or only the certificate from the publisher of the app. If a certificate has been revoked, any RIA that is signed with the certificate is not allowed to run. This check can be disabled, but that is not recommended. The following choices are available, select only one:
Publisher's certificate only
All certificates in the chain of trust (selected by default)
Do not check (not recommended)
The following options indicate what to use to determine if a certificate has been revoked, select only one:
Certificate Revocations Lists (CRLs)
Online Certificate Status Protocol (OCSP)
Both CRLs and OCSP (selected by default)
If Do Not Check is selected for Perform signed code certificate revocation checks on, this setting is ignored.
Before a signed applet or Java Web Start application is run from a secure server, the certificates used to authenticate the secure server can be checked to ensure that none have been revoked. You can have all certificates checked, or only the certificate from the server. If a certificate has been revoked, any RIA that is signed with the certificate is not allowed to run. This check can be disabled, but that is not recommended. The following choices are available, select only one:
Server certificate only
All certificates in the chain of trust (selected by default)
Do not check (not recommended)
The following options indicate what to use to determine if the certificate for a secure server has been revoked, select only one:
Certificate Revocations Lists (CRLs)
Online Certificate Status Protocol (OCSP)
Both CRLs and OCSP (selected by default)
If Do Not Check is selected for Perform TLS certificate revocation checks on, this setting is ignored.
The following choices are available, more than one can be selected:
Enable the operating system’s restricted environment (native sandbox) (Windows only, not checked by default)
Use certificates and keys in browser keystore
Enable blacklist revocation check
Enable caching password for authentication
Use SSL 2.0 compatible ClientHello format (not checked by default)
Use TLS 1.0
Use TLS 1.1
Use TLS 1.2
Native Sandbox
The native sandbox option is available only on Windows. When the native sandbox is enabled, sandbox applets and Java Web Start applications run in a restricted environment that is provided by the operating system. All-permission applications are not affected and continue to run as before.
The following conditions apply:
The native sandbox is disabled for applications included in the Exception Site List or when a Deployment Rule Set is used.
Sandbox applets deployed with the HTML applet tag, which includes all-permissions JAR files from the Class-Path manifest attribute, run in the native sandbox. In this case, a special warning dialog is shown to inform the user that the applet might not work properly when it tries to access the all-permission JAR files.
The custom preloader is disabled in the following cases when the native sandbox is enabled:
The custom preloader is disabled when a sandbox applet or Java Web Start application is initializing. The default preloader is used instead. After the application is initialized, Java VM restarts with the native sandbox enabled and the custom preloader is used.
For all-permission applications, the custom preloader is disabled if it is located in a JNLP file that has sandbox permission, until the user agrees to run the application from the Security Dialog, which grants unrestricted access (privileged) to the application.
The following choices are available depending on your platform, none are checked by default:
Store user settings in the roaming profile (Windows only)
By default, user settings are stored in user_home\AppData\LocalLow\Sun\Java\Deployment. Select this option to store user settings in user_home\AppData\Roaming\Sun\Java\Deployment. When selected, the deployment.properties file is copied to the Roaming directory. When deselected, the file is removed from the Roaming directory. In addition, when the option is selected, the following items are also stored in the Roaming directory:
Local application properties
Security baselines
Blacklisted certificates
Blacklisted JAR files
User certificate stores
Exception site list
Place Java icon in system tray
Suppress sponsor offers when installing or updating Java
Select this option if you do not want to be provided with offers from sponsors during the installation or update process.