This topic provides information on additional deployment features that are supported for rich Internet applications, such as protocols, multiple JRE versions, and special applet attributes.
This topic contains the following sections:
Support for the following common protocols is built into the Java Plug-in:
Java Plug-in supports HTTP and FTP protocols, including built-in proxy configuration support.
HTTPS is supported in Java Plug-in through Java Secure Socket Extension (JSSE), which provides a Java implementation of SSL and HTTPS for the Java platform.
When accessing an HTTPS server, errors might occur. Java Plug-in has hooked into JSSE to provide the following types of error handling:
Hostname mismatch: If the HTTPS server host name does not match the name on the server certificate, a warning dialog will appear.
Untrusted server certificate: If the server certificate can not be verified during the SSL handshaking, a warning dialog will appear.
Untrusted client certificate: In case client authentication is required by the server and the client certificate cannot be verified, a warning dialog will be appear.
Server authentication: If the client accesses a protected directory on the HTTPS server, the users will be prompted for a username and password. Note: Only basic authentication is currently supported.
Although support of HTTPS through JSSE eliminates many browser-specific problems, the following issues could occur:
Untrusted server certificate: When SSL handshaking takes place in establishing an HTTPS connection, the server certificate is verified against the root CA store in Java SE. However, Java SE supports fewer root CA certificates than does the browser. As a result, you may have problems with untrusted server certificates.
Client authentication: Java Plug-in supports browser keystore in JRE 1.5 or later. With browser keystore, client authentication of HTTPS server is performed differently for Internet Explorer and Mozilla family browsers. For Internet Explorer the certificate is not imported into the JRE keystore. For Mozilla family browsers, a JSS package should be installed to read the certificate from the Mozilla keystore. By default browser keystore support is turned on.
Level of error handling: Java Plug-in currently handles the types of error listed in the previous section. However, if the Java Plug-in encounters errors that it does not recognize, Java applet code might break.
Java Plug-in currently supports SOCKS version 4.
Note: For HTTP/HTTPS, a SOCKS proxy server can be used with a web proxy server to add caching. The behavior, however, might differ from that observed when running a similar configuration in a browser without Java Plug-in.
Java Plug-in supports NTLM authentication protocol for HTTP/HTTPS. When attempting to access a server requiring NTLM authentication, the user is prompted to enter User Name, Password and the Domain.
The following sections describe the methods used to support multiple versions of the JRE on a single system.
Every new and update version of Java Plug-in has a unique MIME type. MIME type identifies the type or version of the Java executable to be loaded and initialized by Java Plug-in. It is specified with the element type in the embed tag with Firefox and with <param name="type"> in the object tag for Internet Explorer. If you want to use a minimum version of Java Plug-in with Firefox, specify the unique MIME type in the embed tag.
The MIME type corresponding to the version of Java Plug-in installed in your computer looks like the following:
application/x-java-applet;jpi-version=<version>
where version includes the major, minor and patch version numbers.
The Java Plug-in supports the latest MIME type version (corresponding to the version of the Java Plug-in) and all previous MIME type versions.
Other MIME types supported by the Java Plug-in look like the following:
application/x-java-applet;version=<version>
To determine which MIME types are supported by the version of the Java Plug-in installed on your computer, enter about:plugins in the Firefox location bar. This displays a list of installed and detected plugins. Look for the Java Plug-in entry; it will list all supported MIME types. See about:plugins in the MozillaZine Knowledge Base for more information.
For Java Plug-in 1.7.0, the unique MIME type is application/x-java-applet;jpi-version=1.7.
|
Note: Note: If you have different versions of the JRE installed, only the latest version of the Java Plug-in is installed. As mentioned previously, this version of the Java Plug-in supports all previous versions of the Java Plug-in MIME type. These MIME types are supported by the filenpjp2.dll. The location of this file is listed in the about:plugins page. |
Every new and update version of Java Plug-in has a unique Java Plug-in registry key. The main Java Plug-in registry key is as follows:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\<version number>
|
Note: Note: If you installed a 32-bit JRE in a 64-bit operating system, then the Java Plug-in registry key isHKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Plug-in\<version number>. |
To determine <version number>, refer to the Java Plug-in entry in the Firefox about:plugins page.
The Java Plug-in that comes with JRE 7u3, has the following registry key:
HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Plug-in\10.3.0
The property file is named deployment.properties. It is located in the following directory:
<User Application Data Folder>\Sun\Java\Deployment
<User Application Data Folder> is an application data folder specific to the user.
As an example, for a user testuser on a Windows 7 system, the value of <User Application Data Folder> would be C:\Users\testuser\AppData\LocalLow
The value of <User Application Data Folder> is obtained from the Win32 API function call SHGetFolderPath() with CSIDL_APPDATA.
The default location for trace and log files is <User Application Data Folder>\Sun\Java\Deployment\log, where <User Application Data Folder> is as defined in Section 32.2.3, "Unique Java Plug-in Property File."
See Section 22.2, "Tracing and Logging" for more information.
Every new and update release has a unique Java Control Panel. The filename for the Java Control Panel is javacpl.exe, which is located in the directory <JRE installation directory>\bin.
Only the latest installed version of the Java Control Panel is available from the Windows Control Panel.
Every new and update release of the JRE/JDK has unique registry keys. These registry keys are in the following locations:
HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Runtime Environment\<version number> HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Development Kit\<version number>
where the <version number> includes the major, minor and the patch version numbers; for example: 1.7.40.
|
Note: Note: If you installed a 32-bit JRE in a 64-bit operating system, then the registry keys are located in Java Plug-in registry key isHKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft. |
These keys enable Java Plug-in to locate the proper version of the JRE.
Multiple JRE versions can be installed on the Windows platform. With multiple JRE's applets using MIME type jpi-version will work with Firefox browsers only if you enable the following option:
To enable the Mozilla Family option for JRE 6 and later, open Java Control Panel and click the Advanced tab. Under Default Java for browsers, select Mozilla family.
To invoke Java Control Panel for a specific version of the JRE, go to the <JRE_HOME>/bin directory for that version and run javacpl.exe.
|
Note: Note: Multiple versions of the JRE can be run in different browser sessions. However, multiple versions cannot be run in the same browser session. Should this be attempted, the user is warned and the attempt will fail. |
Previously, when a new JRE was installed, JAR and native libraries for the old release were not visible to the new one. Thus applications and applets that relied on those libraries would not work, and developers were forced to redeploy their libraries to the new JRE. The System-Wide Repository is the solution to that problem. It provides a global or system-wide location where the VM can search for libraries, JAR or native, independent of the JRE location. It provides functionality similar to the repository in the Microsoft VM.
|
Note: The system-wide repository is supported by Java Plug-in only on Windows. |
The table below shows the location of the new System-Wide Repository:
| Type of Library | System-Wide Location |
|---|---|
| DLL | Any directory in the System Path environment variable. |
| Untrusted JAR | <Windows Directory>\Sun\Java\Deployment\Lib\Untrusted |
| Trusted JAR | <Windows Directory>\Sun\Java\Deployment\Lib\Trusted |
<Windows Directory> is the Windows OS directory on the drive where Windows was installed (also called %SystemRoot%).
For example, on Windows 7, where Windows has been installed on the C drive (typical), the locations of these libraries would be as follows:
| Type of Library | System-Wide Location |
| DLL | Any directory in the System Path variable; e.g., C:\WINDOWS\repository if C:\WINDOWS\repository has been set in the System Path variable. |
| Untrusted JAR | C:\WINDOWS\Sun\Java\Deployment\Lib\Untrusted |
| Trusted JAR | C:\WINDOWS\Sun\Java\Deployment\Lib\Trusted |
The classes in the JAR files from the system-wide trusted repository are loaded by the extension class loader, whereas the classes in the JAR files from system-wide untrusted repository are loaded by the applet class loader. Thus the former classes are given the AllPermission permissions, while the latter are given only default applet permissions.
The system-wide trusted repository implementation is based on the system property java.ext.dirs. If users select their own java.ext.dirs system property via the Java Control Panel, the JAR files in the system-wide trusted repository will not be loaded by Java Plug-in.
The repository does not provide version or name spaces control. It is up to the deployer to avoid version and name spaces conflicts at deployment time.
Two methods in the interface java.Applet.AppletContext enable applet persistence across browser sessions:
These methods enable you to stream data and objects from one browser session so that they can be reused in subsequent browser sessions. This provides applet persistence and makes it unnecessary to use static objects in applets for this same purpose.
The setStream(key, stream) method maps a key to a stream. The getStream(key) method returns the stream mapped to the key. If the AppletContext already has a stream mapped to the key when the setStream(key, stream) method is invoked, the mapping is updated.
Applets have default attributes associated with them. Special attributes like image and boxmessage can be associated with applets and used for customizing the applet window during downloading of an applet. JavaBeans component can also be customized using these special attributes.
imageThe image attribute allows you to replace the default animation with a custom graphic. The format with the standard applet element is:
<applet ...> <param name="image" value="my_image.gif"> </applet>
See Using applet, object and embed Tags in Java Plug-in for how this would be mapped to the object or the embed tags.
If a custom graphic is specified, it should be the same size as the area of the applet window. If these sizes do not match, the graphic will be placed in the upper left corner of the area specified for applet. If it is larger than the applet window, part of it will get chopped off. If it is smaller than the applet window, white, or whatever color is specified for boxbgcolor, will appear around it.
The image can be either a GIF or JPEG, and it should reside in the same directory where other resources for the applet reside; i.e., if the applet uses the codebase attribute, then this image should be in the codebase directory.
Note: The image file should not be in a packaged jar file with other applet resources, since the image needs to be displayed while downloading resources.
The status bar of the browser will display "Loading Java Applet ..." when the mouse is pointed at the applet window.
boxmessageWith the boxmessage attribute you can customize the text displayed in the status bar of the browser. This attribute will be in effect when image attribute is used. The format for using this with the standard APPLET element is:
<APPLET ...> <PARAM name="boxmessage" value="<your custom message goes here>"> </APPLET>
boxbgcolor, boxfgcolorThese attributes can be used to customize colors in the applet window.
These attributes will be in effect when the image attribute is used. Custom colors cannot be specified for the default appearance of the applet viewing area.
By default the applet window background color is white. The attribute boxbgcolor can be used to specify a different background color. The format for use with the standard APPLET element is:
<APPLET ...> <PARAM name="boxbgcolor" value="<value>"> </APPLET>
where <value> may be:
any Color from java.awt.Color;
r,g,b where r, g, and b are integers in the range of 0-255 that would render an opaque standard RGB (sRGB) color in the Color constructor Color(int r, int g, int b);
standard HTML colors: silver, green, maroon, purple, navy, teal, and olive; or
hexadecimal color format
Examples of each item above:value="cyan", value="111,222,145", value="silver", value="#33FF33"
By default the applet window foreground color is black. The attribute boxfgcolor can be used to specify a different foreground color. The color values are the same as described above. The format for use with the standard APPLET element is:
<APPLET ...> <PARAM name="boxfgcolor" value="<value>"> </APPLET>
The order of precedence for these attributes in applets is as follows:
If no parameters are provided, the default appearance is used.
If a custom graphic is specified for the image attribute, then the custom graphic appears as described for image.
If custom text is provided for the boxmessage attribute, then custom text is displayed as described for boxmessage.
With any combination of image and boxmessage attributes, custom colors can always be provided with the boxbgcolor and boxfgcolor attributes.
If an applet fails to load the following actions are performed:
The applet window displays error information.
The applet window has a single pixel border using white for the foreground color, and a small "broken" graphic occupies the upper left corner.
The user can click the link for more details about the error.
