Java Plugin Detector




Download PluginDetect and the jarfile here...

In order to do Java detection, you will need several things:

1) download the getJavaInfo.jar applet along with a few Java detection examples. The applet is used by PluginDetect in order to accomplish Java detection. [This download also includes the source code for the applet and instructions on how to customize it. Customization is recommended for security reasons. All this is discussed in the download.]

2) download the PluginDetect script itself. The download page will allow you to customize the PluginDetect script to include whatever features you desire. [Or, you can simply use the sample PluginDetect script used by the detector at the top of this page.]

3) write the Javascript code that calls the appropriate PluginDetect commands. [Or, you can use the sample script used by the detector at the top of this page.] Make sure that the jarfile input argument in your Javascript code specifies the correct filename and path.



A brief introduction to Java detection

PluginDetect uses a number of different methods when trying to detect Java in your browser. These Java detection methods can be divided into 2 groups: a) the non-applet methods and b) the applet methods.

The non-applet detection methods are those techniques that do not use any Java applets to do Java detection. These methods do not require the Java browser plugin to be active. Examples of non-applet methods would be: searching thru the navigator.mimeTypes array for a Java mimetype, searching thru the navigator.plugins array for the Java plugin, trying to instantiate certain ActiveX objects associated with Java, and so on.

The applet detection methods are those techniques that instantiate a Java applet(s) in the browser, and then query that applet to get the Java version and vendor. An example of this method would be to insert an <applet> tag into the HTML document, run a Java applet (jar file or class file) in that <applet> tag, and then query the applet to get the installed Java version & vendor.

When doing Java detection, PluginDetect will usually try the non-applet methods first. If those methods are unable to find anything, then PluginDetect will try the applet methods.

The tradeoffs between the 2 groups of methods are speed, reliability, and timing. The non-applet methods are very fast, which is why they are the first to be used. The applet methods, on the other hand, are more reliable but relatively slow. The applet methods force the Java plugin to run. And that way you know for sure whether the plugin is installed and enabled in your browser.

Finally, PluginDetect allows some flexibility in how it accomplishes Java plugin detection. You can tell PluginDetect to only use the non-applet methods. Or, you can tell it to only use the applet methods. Or, you can specify some combination thereof.



A list of PluginDetect commands for Java detection

The PluginDetect commands for Java detection are as follows:

PluginDetect.getVersion('Java', jarfile, verifyTagsArray): [Returns string or null]
   Returns the version (as a string) of the installed plugin. If multiple Java versions are detected, then the highest installed version is returned. When getVersion( ) returns a version, it only means that Java is installed. It does NOT necessarily mean that Java is enabled.
   Returns null when the version could not be determined (when plugin is not installed/not enabled, or plugin is installed but the version information is unavailable).

By default, the returned version string is comma delimited and has the format of "A,B,C,D". If you wish to change the getVersion( ) delimiter, then use:
   PluginDetect.getVersion(delimiter) where delimiter is a string with exactly 1 character.

For example,
   PluginDetect.getVersion(".");   // set delimiter
   var version = PluginDetect.getVersion("Java", jarfile, verifyTagsArray);    // version has format "A.B.C.D"

PluginDetect.isMinVersion('Java', minVersion, jarfile, verifyTagsArray): [Returns number]
   Returns 1 if plugin is installed & enabled and plugin version is >= minVersion. The <applet> and/or <object> tag can be used to run a Java applet.

   Returns 0.5 if plugin detection has been initiated but is not yet completed. At this point in time, the plugin appears to be installed & enabled (but this is not a certainty). Detection is occurring NOTF (Not On The Fly), so you will have to wait until the detection has completed. Only certain plugins (on certain browsers and platforms) require NOTF.
   In order to handle NOTF detection, it is recommended that you use the onDetectionDone( ) method. This method will call an event handler after plugin detection has fully completed. The handler can call the isMinVersion( ), getVersion( ) and getInfo( ) methods to obtain the final plugin detection results.

   Returns 0 if plugin installed & enabled. The plugin version is unknown, and thus we are unable to determine if version >= minVersion.

   Returns -0.1 if plugin is installed & enabled, but plugin version is < minVersion.

   Returns -0.2 if Java is installed but not enabled. This detection result only occurs for some browsers, and only when those browsers reveal enough information to PluginDetect to make this determination. There are two reasons why this detection result can occur.
   The first reason is that the browser may have automatically disabled the Java plugin due to security reasons. In this case, the browser may require the user to click on something in the web page in order to enable/activate the Java plugin.
   The second reason is that the user may have intentionally disabled the plugin in the browser addons menu.

   Returns -0.5 if plugin detection has been initiated but is not yet completed. At this point in time, it is unknown whether the plugin is installed or not. Detection is occurring NOTF (Not On The Fly), so you will have to wait until the detection has completed. Only certain plugins (on certain browsers and platforms) require NOTF.
   In order to handle NOTF detection, it is recommended that you use the onDetectionDone( ) method. This method will call an event handler after plugin detection has fully completed. The handler can call the isMinVersion( ), getVersion( ) and getInfo( ) methods to obtain the final plugin detection results.

   Returns -1 if plugin is not installed or not enabled.

   Returns -3 if you supplied a bad input argument to the isMinVersion( ) method.

PluginDetect.onDetectionDone('Java', f, jarfile, verifyTagsArray): [Returns number]
   This method will initiate plugin detection if needed, and will execute the event handler f after the plugin detection results become available. The event handler f automatically receives the PluginDetect object as an input argument such that we have f(PluginDetect){ ... }. You are free to use the getVersion( ), isMinVersion( ) and getInfo( ) methods inside event handler f.
   onDetectionDone( ) is capable of doing both OTF and NOTF plugin detection. NOTF detection is required for certain browser/platform/Java version combinations. You must specify the jarfile input argument in order for NOTF detection to occur.
   Returns 1 if plugin detection is done (OTF) and handler f has been executed.
   Returns 0 if plugin detection is not done yet (NOTF) and handler f has not been called yet. Handler f will be called after detection has been completed.
   Returns -1 if error (plugin name input argument not specified correctly).

PluginDetect.onBeforeInstantiate('Java', f):
   Executes the event handler f immediately before PluginDetect attempts to instantiate the plugin. [By instantiate, we mean that an instance of the plugin is inserted into your web page. This will cause the plugin to start up and run, assuming it is installed.] The event handler automatically receives the PluginDetect object as an input argument such that we have f(PluginDetect){ ... }.
  Sometimes during detection, it may be necessary for PluginDetect to instantiate (or attempt to instantiate) the plugin. Should this attempt be neccessary, the event handler f will run first, and then the plugin will attempt to instantiate. [Note: If the plugin is installed and enabled, then it instantiates. If it is not installed or not enabled, then it will not instantiate. Either way, the handler f will run before the attempt is made.]
  In order for the onBeforeInstantiate( ) method to work correctly, you must place it BEFORE detection is started for the plugin. In other words, use it before getVersion(pluginName), isMinVersion(pluginName), and onDetectionDone(pluginName). As an example:
       var PD = PluginDetect;
       var F1 = function($){ ... };        // $ input arg is PluginDetect object
       PD.onBeforeInstantiate('Java', F1);
       var F2 = function($){ var version = $.getVersion('Java'); alert(version); };
       PD.onDetectionDone('Java', F2, 'getJavaInfo.jar');

PluginDetect.onWindowLoaded( f ):
   Executes the event handler f after the browser window has fully loaded. The event handler f automatically receives the PluginDetect object as an input argument such that we have f(PluginDetect){ ... }. You are free to use getVersion( ), isMinVersion( ), onDetectionDone( ), and onBeforeInstantiate( ) inside event handler f.

Event handler f without user input arguments: If the user does not specify any input arguments for event handler f, then the relevant PluginDetect methods are in the format of
       PluginDetect.onDetectionDone(pluginName, f, ...)
       PluginDetect.onWindowLoaded(f)
       PluginDetect.onBeforeInstantiate(pluginName, f)

When the handler f is executed it automatically receives the PluginDetect object as input such that we have f(PluginDetect){ ... }.

Event handler f with user input arguments: You may specify up to 3 inputs (ie. arg1, arg2, and arg3) for the event handler. The trick is to use an array such as [f, arg1, arg2, arg3]. The relevant PluginDetect methods are in the format of
       PluginDetect.onDetectionDone(pluginName, [f, arg1, arg2, arg3], ...)
       PluginDetect.onWindowLoaded( [f, arg1, arg2, arg3] )
       PluginDetect.onBeforeInstantiate(pluginName, [f, arg1, arg2, arg3])

When the handler f is executed it automatically receives the PluginDetect object as input such that we have f(PluginDetect, arg1, arg2, arg3){ ... }.


PluginDetect.getInfo('Java', jarfile, verifyTagsArray): [object or null]
   Returns null if no information is available for this plugin.
   Returns an object with several useful properties and methods. The properties/methods are listed below. To simplify matters, we assign this object to a variable:
    var INFO = PluginDetect.getInfo('Java', jarfile, verifyTagsArray);

INFO.isPlugin2: [number] This tells us if the next generation Java plugin is installed in your browser. A brief description is given by Oracle.
   Returns 1 if Next Generation Java Plugin2 is installed and enabled in your browser.
   Returns 0 if unable to determine status of Plugin2 in your browser.
   Returns -1 if Next Generation Java Plugin2 is not installed or not enabled in your browser.

INFO.JavaAppletObj: [object or null]
   Returns a Java applet object when that applet was used by PluginDetect to perform Java detection. During the course of Java plugin detection, it is sometimes necessary to insert one or more Java applets into the web page, and then to query those applets. The JavaAppletObj property gives you access to one of these applets. [BTW, you can force PluginDetect to insert and query one or more applets during plugin detection by specifying the verifyTagsArray, should you need to do so.]
   Returns null when no Java applets have been inserted into the web page by PluginDetect.

INFO.OTF: [number]
   Returns 0 if Java detection has been performed on the fly (OTF).
   Returns 1 if Java detection is being performed not on the fly (NOTF) but is not completed yet.
   Returns 2 if Java detection has been performed not on the fly (NOTF) and is complete.

INFO.getDeploymentToolkitObj( ): [object, 0 or null]
   This function attempts to insert a Java Deployment Toolkit object into the web page, queries that object, and then returns that object. All the properties of the PluginDetect.getInfo('Java') object are also updated to reflect any information provided by the Deployment Toolkit object.
[Note: the Deployment Toolkit browser plugin currently is only available for Oracle Java 1.6.0.10+ for Windows.]
[Note: when the Toolkit object is created by PluginDetect, the Toolkit (or browser) may generate a popup warning message asking you to upgrade your Java. This is a Java security feature which some users may find to be annoying. PluginDetect has no control over this popup. So consider carefully before using the getDeploymentToolkitObj( ) method.]
   Returns the Java Deployment Toolkit plugin object if the Toolkit plugin is installed and enabled.
   Returns 0 if the Deployment Toolkit is not installed/not enabled.
   Returns null if no attempt was made to detect the Toolkit. Thus it is unknown whether the Toolkit is installed or not.

INFO.DeployTK_versions: [Array of strings]
   If the Deployment Toolkit browser plugin is installed, then this array will contain a sorted list of all Java versions that were detected by the Deployment Toolkit plugin. The purpose of this array is to detect multiple JREs. The version strings are in the exact same format used by the Deployment Toolkit plugin (ie. "1.5.0_04", "1.6.0._03", etc...).

INFO.All_versions: [Array of strings]
   This array contains a sorted list of all detected Java versions from all possible sources (including the DeployTK_versions array).

INFO.vendor: [string]
   The Java vendor. Possible value are Oracle Corporation, Sun Microsystems, Apple Inc, Microsoft Corp., etc...

INFO.name: [string]
   The plugin name as given in the navigator.plugins array. This is only for non-Internet Explorer browsers.

INFO.description: [string]
   The plugin description as given in the navigator.plugins array. This is only for non-Internet Explorer browsers.

INFO.objectTag: [null or number] tells you if an HTML5 compatible <object> tag can be used to run/display a Java applet in your browser.
   Returns null if no information is available on whether this <object> tag can be used to run a Java applet.
   Returns 1 if Java is installed and enabled and this <object> tag can run a Java applet. The Javascript to Java bridge is functional for this <object> tag. The path/filename given for jarfile is correct.
   Returns 0 if Java is installed and enabled and this <object> tag can run a Java applet. Additional information on the tag is not available, because: a) the Javascript to Java bridge is perhaps not functioning, or b) the path/filename given for jarfile is incorrect, or c) PluginDetect did not bother waiting for more info on the tag because verifyObjectTag ==1 and any Java applet(s) running in the other tag(s) already detected the Java version.
   Returns -1 if this <object> tag is unable to run a Java applet, because Java is not installed or Java is not enabled for this tag.

INFO.appletTag: [null or number] tells you if an <applet> tag can be used to run/display a Java applet in your browser.
   Returns null if no information is available on whether this <applet> tag can be used to run a Java applet.
   Returns 1 if Java is installed and enabled and this <applet> tag can run a Java applet. The Javascript to Java bridge is functional for this <applet> tag. The path/filename given for jarfile is correct.
   Returns 0 if Java is installed and enabled and this <applet> tag can run a Java applet. Additional information on the tag is not available, because: a) the Javascript to Java bridge is perhaps not functioning, or b) the path/filename given for jarfile is incorrect, or c) PluginDetect did not bother waiting for more info on the tag because verifyAppletTag ==1 and any Java applet(s) running in the other tag(s) already detected the Java version.
   Returns -1 if this <applet> tag is unable to run a Java applet, because Java is not installed or Java is not enabled for this tag.

INFO.objectTagActiveX: [null or number] tells you if an <object> tag with a classid (which specifies a Java ActiveX control) can be used to run/display a Java applet in your browser. This particular <object> tag uses Oracle Java ActiveX to run Java and only applies to Internet Explorer.
   Returns null if no information is available on whether this <object> tag can be used to run a Java applet.
   Returns 1 if Java is installed and enabled and this <object> tag can run a Java applet. The Javascript to Java bridge is functional for this <object> tag. The path/filename given for jarfile is correct.
   Returns 0 if Java is installed and enabled and this <object> tag can run a Java applet. Additional information on the tag is not available, because: a) the Javascript to Java bridge is perhaps not functioning, or b) the path/filename given for jarfile is incorrect, or c) PluginDetect did not bother waiting for more info on the tag because verifyObjectTagActiveX==1 and any Java applet(s) running in the other tag(s) already detected the Java version.
   Returns -1 if this <object> tag is unable to run a Java applet using ActiveX, because Java is not installed or Java is not enabled for this tag, or because the <object> tag has been disabled somehow in Internet Explorer, or ActiveX is disabled.


minVersion: [string or number input argument]
   This is the minimum plugin version.
   Can be a string such as  '1,5,0,0' or '1.5' or '1,5,0,1' or '1.5.0.1' etc...
   Can be a number such as 0 or 1.5 or 1.50 etc...
   If minVersion is not specified, then PluginDetect will assume minVersion is '0'.
   Strings are more versatile than numbers since '1,5,0,1' cannot be expressed as a number.

jarfile: [string input argument, optional but strongly recommended]
   This is the [path/]filename to the getJavaInfo.jar applet for Java detection. Even though it is an optional input, it is strongly recommended that you use the jarfile input argument when doing Java detection. Otherwise a number of Java cases will not be detectable.
   The jarfile path can be relative or absolute. If the path is relative, then it is relative to the web page itself, not relative to any external javascript file you may be using. For example,
           jarfile = 'getJavaInfo.jar' means the applet is in the same folder as your web page.
           jarfile = 'ABC/getJavaInfo.jar' means the applet is in a subfolder ABC.

   The getJavaInfo.jar applet allows PluginDetect to query the JRE directly to determine the Java version and Java vendor, as well as other Java related properties.
   You are free to rename the getJavaInfo.jar applet to whatever you wish, as long as the .jar extension remains the same.

verifyTagsArray: [Array input argument, optional]
   An array of 3 numbers [verifyObjectTag, verifyAppletTag, verifyObjectTagActiveX] that controls when the 3 applet detection methods are used for Java detection***. The verifyTagsArray is optional and usually does not need to be set by the user.
   The verifyObjectTag parameter controls the HTML5 compatible <object> tag detection method (ie. one of the applet detection methods). It determines when an HTML5 compatible <object> tag along with the jarfile are used for Java detection. The result of this detection is given by INFO.objectTag.
   
The verifyAppletTag parameter controls the <applet> tag detection method (ie. one of the applet detection methods). It determines when an <applet> tag along with the jarfile are used for Java detection. The result of this detection is given by INFO.appletTag.
   The verifyObjectTagActiveX parameter controls the <object> tag ActiveX detection method (ie. one of the applet detection methods). It determines when an <object> tag with classid (which specifies the Java ActiveX control) and jarfile are used for Java detection. The result of this detection is given by INFO.objectTagActiveX. This parameter is only used by Internet Explorer.

The verifyTagsArray is discussed in more detail later on.


[**Note: PluginDetect uses the developer version numbers for Java instead of the product version numbers. Digits will be separated by "," commas. For example, Java 1,5,0,0 is the developer version and Java 5 is the corresponding product version. So when using PluginDetect, you refer to the Java versions as Java 1,5,0,0 (not Java 5) or Java 1,6,0,0 (not Java 6) or Java 1,7,0,0 (instead of Java 7) or Java 1,4,2,0 or Java 1,3,0,0 and so on. This applies to the input argument minVersion, the output value for PluginDetect.getVersion('Java', jarfile), and the contents of the PluginDetect.java.All_versions array.

The PluginDetect.getInfo('Java', jarfile).DeployTK_versions array also uses the developer version numbers. But the digits will be separated by "." dot and "_" underscore.]

[*** Note: When PluginDetect tries to detect Java, it will start out by using the non-applet detection methods. If the non-applet methods fail to detect anything, then PluginDetect resorts to using Java applets. The applets are inserted into your web page using one or more HTML tags. Each HTML tag specifies the jarfile 'getJavaInfo.jar'. The applets are queried to determine the Java version, and then they are deleted from the page. We call this the applet detection method.]

Please remember that any output values supplied by PluginDetect are read-only.



A few examples to detect Java

Suppose you wanted to check that JRE (Java Runtime Environment) 1.5 or higher was installed. The way you could do that is as follows:

// Example # 1
// We assume here that getJavaInfo.jar is in the same folder as the web page.

var status = PluginDetect.isMinVersion('Java', '1.5', 'getJavaInfo.jar');
var version = PluginDetect.getVersion('Java', 'getJavaInfo.jar');


If the status variable receives a value of 1, then plugin detection was initiated and completed by the isMinVersion( ) method. Java is installed and the version of Java is >= 1.5. The version variable will be a string that contains the Java version. We say that plugin detection was completed "on the fly", or OTF.

If the status variable receives a value of -0.1, then plugin detection was initiated and completed by the isMinversion( ) method. Java is installed, but the Java version is < 1.5. The version variable will be a string that contains the Java version. Plugin detection was completed OTF.

If status is 0, then detection was initiated and completed. Java is installed, but the Java version could not be determined. The version variable will be simply be null in this case. Plugin detection was completed OTF.

If status is -0.2, then detection was initiated and completed. Java is installed, but not enabled. It is possible that the Java plugin was disabled by the user via the browser's add-ons menu. Or, the plugin may have been disabled automatically by the browser due to security reasons (ie. if the plugin is too outdated). The version variable may or may not contain the Java version, depending on the browser/platform/Java version. Plugin detection was performed OTF.

If status is -1, then detection was initiated and completed. The Java plugin could not be detected by PluginDetect, which means that Java is either not installed, or installed but not enabled. The version variable will be be null. Plugin detection was performed OTF.

If the status variable receives a value of +0.5, then Java detection was initiated by the isMinVersion( ) method, but the detection was NOT completed. The isMinVersion( ) method was unable to obtain the final detection result. Java appears to be installed and enabled at this point in time, but that is not 100% certain. The version variable may or may not receive the Java version result at this time. Plugin detection is occuring "not on the fly", or NOTF. What this means is that we need to wait until detection has completed, and then we can use the isMinVersion( ) and getVersion( ) methods again to obtain the final Java detection results.

If status is -0.5, then Java detectionwas initiated by the isMinVersion( ) method, but the detection was NOT completed. The isMinVersion( ) method was unable to obtain the final detection result. We do not know yet whether Java is present or not. The version variable will be null at this point in time. Plugin detection is occuring "not on the fly", or NOTF. We need to wait until detection has completed, and then we can use the isMinVersion( ) and getVersion( ) methods to obtain the final Java detection results.


The point of Example 1 was to demonstrate that sometimes we can get the detection results right away (OTF detection), and sometimes we cannot (NOTF detection). The NOTF case occurs for certain browser/platform/Java version combinations. And so the real question is, how can we obtain the final Java detection results for both OTF and NOTF?

The following example demonstrates how the onDetectionDone( ) method can handle both OTF and NOTF detection:

// Example # 2

var status, version;

// Event handler automatically receives PluginDetect object as input
function displayResults($$){

   // We do not need to specify the 'getJavaInfo.jar' input argument here,
   // because it was already specified in the onDetectionDone( ) method.
   // You can specify it again if you wish, but it is not necessary.

   status = $$.isMinVersion('Java', '1.5');
   version = $$.getVersion('Java');

   alert('Java status: ' + status);
   alert('Java version: ' + version);
   alert('Java installed and enabled: ' + (status >= -0.1 ? true : false));
};

// Initiate Java detection, and call the event handler displayResults( )
// as soon as Java detection has completed.

var tmp = PluginDetect.onDetectionDone('Java', displayResults, 'getJavaInfo.jar');

// If tmp is 1, then Java detection was completed OTF. The event handler has been called.
// If tmp is 0, then detection is NOTF. The event handler will be called when detection
// has completed.


The onDetectionDone( ) method will initiate Java detection, it will wait until Java detection has fully completed, and then it will call an event handler. The status variable will therefore never be +0.5 or -0.5. status will always be 1, 0, -0.1, -0.2, or -1. The return value of onDetectionDone( ) will also tell you whether the detection is OTF or NOTF. I strongly recommend this method for performing your OTF & NOTF Java detection.



The jarfile input argument

The use of the jarfile input argument is strongly recommended because it greatly enhances plugin detection reliability.

The jarfile argument only needs to be used in the very first PluginDetect method that is executed in your script. The best way to illustrate this is with a few examples.

Example #1:

var Java0Status = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar');
var JavaVersion = PluginDetect.getVersion('Java');
var obj = PluginDetect.getInfo('Java');
var AllVersions = obj.All_versions; // array


Example #2:

var JavaVersion = PluginDetect.getVersion('Java', 'getJavaInfo.jar');
var Java0Status = PluginDetect.isMinVersion('Java', '0');
var obj = PluginDetect.getInfo('Java');
var AllVersions = obj.All_versions; // array


Example #3:

var Java142Status, JavaVersion;

// Begin Java detection
PluginDetect.onDetectionDone('Java', 0, 'getJavaInfo.jar');

function displayResults( ){
   Java142Status = PluginDetect.isMinVersion('Java', '1.4.2.0');
   JavaVersion = PluginDetect.getVersion('Java');
   alert('Java Version : ' + JavaVersion);
   alert('Java 1.4.2.0 Status : ' + Java142Status);
};

// Run displayResults( ) when Java detection is done
PluginDetect.onDetectionDone('Java', displayResults);


Example #4:

var Java142Status, JavaVersion;

function displayResults( ){
   Java142Status = PluginDetect.isMinVersion('Java', '1.4.2.0');
   JavaVersion = PluginDetect.getVersion('Java');
   alert('Java Version : ' + JavaVersion);
   alert('Java 1.4.2.0 Status : ' + Java142Status);
};

// Begin Java detection. Run displayResults( ) when Java detection done.
PluginDetect.onDetectionDone('Java', displayResults, 'getJavaInfo.jar');


Example #5:

var Java142Status, JavaVersion;

// Begin Java detection
var tmp = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar');

function displayResults( ){
   Java142Status = PluginDetect.isMinVersion('Java', '1.4.2.0');
   JavaVersion = PluginDetect.getVersion('Java');
   alert('Java Version : ' + JavaVersion);
   alert('Java 1.4.2.0 Status : ' + Java142Status);
};

// Call displayResults( ) when Java detection is done
PluginDetect.onDetectionDone('Java', displayResults);



Of course, you are free to specify the jarfile in all your PluginDetect methods if you wish. But to do so would be redundant.


If your jarfile path is relative, then it is always relative to the web page itself. For example, if the getJavaInfo.jar file is located in the same directory as your web page, then jarfile would simply be 'getJavaInfo.jar'. If the getJavaInfo.jar file is in a subdirectory 'ABC' relative to the web page, then jarfile would be 'ABC/getJavaInfo.jar'.

To be on the safe side, you might even want to test the jarfile to make sure that your specified jarfile path/name is correct. The easiest way to do this is to go to the PluginDetect download page, select the "Java" option, select the "verify jarfile" option, and then press the "Create Script" button. The resulting script should then be used in your Java detection web page. The script will test to see if your jarfile path/name is correct, and it will display the results of that test at the top of your Java detection web page.



The verifyTagsArray input argument

We previously mentioned that when PluginDetect tries to detect Java, it will start out by using the non-applet detection methods.

If the non-applet methods fail to detect anything, then PluginDetect resorts to using the applet detection methods (ie. Java applets). The applets are inserted into your web page using HTML tags. Each of these HTML tags uses the jarfile 'getJavaInfo.jar'. The applets are queried to determine the Java version, and then they are deleted from the page.

There are 3 applet detection methods. We call them the <object> tag method, the <applet> tag method, and the <object> tag ActiveX method. INFO.objectTag (discussed at the top of this page) reveals the detection results given by the <object> tag method. INFO.appletTag reveals the detection results given by the <applet> tag method. And INFO.objectTagActiveX reveals the detection results given by the <object> tag ActiveX method.

The verifyTagsArray (which is an optional input argument) determines when these 3 applet methods are to be used for Java detection. The array contains 3 numbers:

verifyTagsArray = [verifyObjectTag, verifyAppletTag, verifyObjectTagActiveX]


where verifyObjectTag controls when the <object> tag method is used, verifyAppletTag controls when the <applet> tag method is used, and verifyObjectTagActiveX controls when the <object> tag ActiveX method is used.

The numbers in verifyTagsArray can be 0, 1, 2, 2.8, or 3. For instance, the array could be [1,1,1] or [0,1,2] or [3,3,3] or [3,1,1] or whatever. If the user does not specify a value for the array, then PluginDetect assumes a default value. This default is sufficient for most users. You therefore do not even need to bother with setting verifyTagsArray at all.

To illustrate how these numbers work, we look at the possible values for verifyAppletTag (which controls the <applet> tag method):

   verifyAppletTag = 0: means that the <applet> tag method is never permitted to be used for Java detection.

   verifyAppletTag = 1: means that the <applet> tag method is used, but only if a) all non-applet detection methods have failed to detect Java, and the other 2 applet detection methods have failed (so far) to detect the Java version, or b) navigator.javaEnabled( ) is false, or c) ActiveX is disabled (Internet Explorer only).

   verifyAppletTag = 2: means that the <applet> tag method is used, but only if a) all non-applet detection methods have failed to detect Java, or b) navigator.javaEnabled( ) is false, or c) ActiveX is disabled (Internet Explorer only).

   verifyAppletTag = 2.8: means that the <applet> tag method is used, but only if the other 2 applet detection methods have failed (so far) to detect the Java version.

   verifyAppletTag = 3: means that the <applet> tag method is always used to do Java detection.

Note:  The value of INFO.appletTag will be a number if the <applet> tag method was used, and null if it was not used for detection.



We now give a few examples of what happens with different values of verifyTagsArray:

verifyTagsArray = [0, 0, 0]: Only the non-applet methods are used for Java detection. None of the applet methods will ever be used.

verifyTagsArray = [1, 1, 1]: If the non-applet methods detect Java, then detection is done and the applet methods are not used.
   If the non-applet methods fail to detect Java, then the <object> tag method will be used first. If it succeeds in detecting the Java version, then we are done. If it does not give any result on the fly (OTF), then the <applet> tag method is used. If it succeeds in detecting the Java version, then we are done. If it does not give any result on the fly (OTF), then the <object> tag ActiveX method will be used (for Internet Explorer only). If it succeeds in detecting the Java version, then we are done. If none of the 3 methods gave any result on the fly (OTF), then we wait for a NOTF result from any one of these applets. PluginDetect will only wait long enough for results from any one of the applets, though it is possible (most likely) that results for all 3 are obtained.

verifyTagsArray = [2, 2, 2]: If the non-applet methods detect Java, then detection is done and the applet methods are not used.
   If the non-applet methods fail to detect Java, then the <object> tag method and the <applet> tag method and the <object> tag ActiveX method will be used. Results may be obtained OTF or NOTF. Either way, PluginDetect will try to get detection results for all 3 tags.

verifyTagsArray = [0, 3, 0]: The <applet> tag method will always be used to do Java detection, regardless of whether the non-applet methods have detected Java. This will verify that a Java applet is actually capable of running in your browser using the <applet> tag (ie. verifyAppletTag).
   The other 2 applet methods are never used.

verifyTagsArray = [3, 3, 3]: the <object> tag method and the <applet> tag method and the <object> tag ActiveX method will be used for Java detection, regardless of what the non-applet methods may detect.


Note: if you want to verify that the path and filename of jarfile 'getJavaInfo.jar' is correct in your webpage, then temporarily set verifyTagsArray = [3,3,3]. This will force the jarfile to be used with the applet detection methods. If the detection results show that Java is installed/enabled for the <object> and <applet> tags, then you know that the path and filename were correctly specified. After that, you can return verifyTagsArray to whatever value you want.


If you do not give any value to verifyTagsArray, then it a default value is used. This default value is usually sufficient for most detection needs.



We now show the specific HTML tags that are used for each of the applet detection methods...

The <object> tag method involves inserting an HTML5 compatible <object> tag into the web page (all browsers):

<object type="application/x-java-applet" width="1" height="1">
<param name="codebase" value="[path]" />
<param name="archive" value="getJavaInfo.jar" />
<param name="code" value="A.class" />
<param name="scriptable" value="true" />
<param name="mayscript" value="true" />
</object>


Once this Java applet has been inserted into the page, the applet is queried to see if the Java version can be detected. The applet is deleted from the document after detection has been completed. The verifyObjectTag parameter determines if and when this method may be used for Java detection.

The <applet> tag method involves inserting an <applet> tag into the web page:

For Internet Explorer:

<applet archive="getJavaInfo.jar" code="A.class" mayscript="true" width="1" height="1">
<param name="codebase" value="[path]" />
<param name="mayscript" value="true" />
</applet>


For all other browsers:

<applet codebase="[path]" archive="getJavaInfo.jar" code="A.class" mayscript="true" width="1" height="1">
<param name="mayscript" value="true" />
</applet>


Once this Java applet has been inserted into the page, the applet is queried to see if the Java version can be detected. The applet is deleted from the document after detection has been completed. The verifyAppletTag parameter determines if and when this method may be used for Java detection.

The <object> tag ActiveX method involves inserting an <object> tag into the web page (for Internet Explorer only, ActiveX):

<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="1" height="1">
<param name="codebase" value="[path]" />
<param name="archive" value="getJavaInfo.jar" />
<param name="code" value="A.class" />
<param name="scriptable" value="true" />
<param name="mayscript" value="true" />
</object>


Once this Java applet has been inserted into the page, the applet is queried to see if the Java version can be detected. The applet is deleted from the document after detection has been completed. The verifyObjectTagActiveX parameter determines if and when this method may be used for Java detection.


The verifyTagsArray input argument appears right after the jarfile input argument. Since jarfile only needs to be specified in the very first PluginDetect method that runs, you would therefore only need to specify verifyTagsArray in that first PluginDetect method. For example, we could have:

var Java142Status, JavaVersion;
var tmp = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar', [3, 3, 3]); // verifyTagsArray = [3,3,3]

function displayResults( ){
   Java142Status = PluginDetect.isMinVersion('Java', '1.4.2.0');
   JavaVersion = PluginDetect.getVersion('Java');
   alert('Java Version : ' + JavaVersion);
   alert('Java 1.4.2.0 Status : ' + Java142Status);
};

PluginDetect.onDetectionDone('Java', displayResults); // run displayResults( ) when Java detection is done


You have complete flexibility in what values you wish to assign to the array. You could, for example, choose verifyTagsArray = [0, 0, 2] for Internet Explorer and verifytagsArray = [2, 0, 0] for all other browsers. Or, you could use verifyTagsArray = [1, 1, 1] for all browsers.

Or, you could choose to not specify any value at all. The array then goes to it's default value.



Default value for verifyTagsArray

A default value is used for the verifyTagsArray if the user does not specify any value. In fact, most people should not have any need to specify their own verifyTags array. I recommend the default for most users.

For all modern browsers, the default for verifyTagsArray is [1,0,1]. This means that PluginDetect will only use <object> tags when trying to run a Java applet. The <applet> tag is not used because it is deprecated, and because it tends to cause a popup message in some browsers when Java is not present.

For older browsers, the default for verifyTagsArray is [1,1,1]. PluginDetect will use either the <object> tag or the <applet> tag to run a Java applet. The reason for this is that some older browsers may only be capable of using <applet> tags to run an applet, hence we allow the <applet> tag in outdated browsers.



Java installed but not enabled (non-Internet Explorer browsers)

Suppose that we are using the following plugin detection code:

function displayResults( ){
     var STATUS = PluginDetect.isMinVersion('Java', '0');
     var INFO = PluginDetect.getInfo('Java');
     alert('Java STATUS: ' + STATUS);
};

// run displayResults when Java detection is done
PluginDetect.onDetectionDone('Java', displayResults, 'getJavaInfo.jar'); 


The code shown above can detect 2 separate cases where Java cannot run in your browser. In this 1st case, we don't know exactly why Java will not run:

STATUS: -1 (Java cannot run. Java is either not installed, or installed but not enabled)

non-applet detection methods: unable to detect Java
applet detection methods: unable to detect or run Java

There isn't enough information from the browser to figure out why Java won't run.


And in this 2nd case, we DO know why Java will not run:

STATUS: -0.2 (Java cannot run. The reason why is that Java is installed but not enabled)

non-applet detection methods: detect that Java is installed
applet detection methods: unable to detect or run Java


From my own testing, I have only found a few cases where PluginDetect will give you a STATUS == -0.2 for the non-IE browsers. Assuming that Java is installed, the most obvious example is:

In Firefox / Windows, you disable Java in the browser's options.The Deployment Toolkit plugin needs to be installed & enabled in this case.


As a general rule, PluginDetect should be able to reliably detect when Java cannot run in your browser. But it will only occaisonally be able to tell you WHY Java cannot run. It all depends on the browser, the browser settings, the info that the browser makes available, the Java version, and the value of verifyTagsArray.



Java installed but not enabled (Internet Explorer)
& the Internet Options Menu


Disabling Java in the non-Internet Explorer browsers is fairly simple. We just go into the browser preferences and uncheck a single checkbox for Java. And that usually disables Java for all the HTML tags in a web page.

But Internet Explorer is a totally different story. There are alot of settings you can change in this browser that affects Java and Java detection. For example, you can selectively disable Java for some HTML tags while leaving Java enabled for the remaining tags. You can disable Java for all the tags. You can even selectively disable all the non-applet detection methods, while leaving the applet methods enabled.

Suppose we have Java installed on our computer, and we use the following plugin detection code:

function displayResults( ){
     var STATUS = PluginDetect.isMinVersion('Java', '0');
     var INFO = PluginDetect.getInfo('Java');
     alert('Java STATUS: ' + STATUS);
     alert('INFO.appletTag: ' + INFO.appletTag);
     alert('INFO.objectTag: ' + INFO.objectTag);
     alert('INFO.objectTagActiveX: ' + 'INFO.objectTagActiveX);
};

// run displayResults when Java detection is done
PluginDetect.onDetectionDone('Java', displayResults, 'getJavaInfo.jar', [2, 2, 2]);


The above code can detect 3 special cases where a user disables certain settings in the "Internet Options" Menu (Security Settings Tab / Advanced Tab).

Case # 1 is where you go into the Internet Explorer Security settings and set the "Java Permissions" to "Disable Java". The PluginDetect results of this setting are:

Security Settings: "Java Permissions" set to "Disable Java"

navigator.javaEnabled( ): false
PluginDetect.browser.ActiveXEnabled: true
INFO.appletTag: -1 (Java not able to run using <applet> tag)
INFO.objectTag: 1  (Java able to run using <object> tag)
INFO.objectTagActiveX: 1  (Java able to run using <object> tag with Oracle Java ActiveX)
STATUS: 1  (Java can run. Java is installed & enabled)
verifyTagsArray: can be [2,2,2] or [3,3,3] to get this result

Disabling "Java Permissions" in the Security settings appears to only disable the <applet> tag. The <object> tag will still be able to run/display Java applets.


Case # 2 is where you go into the Security Settings and set the "Run ActiveX Controls and Plugins" to "Disable". The PluginDetect results of this setting are:

Security Settings: "Run ActiveX Controls and Plugins" set to "Disable"

navigator.javaEnabled( ): true
PluginDetect.browser.ActiveXEnabled: false
INFO.appletTag: 1 (Java able to run using <applet> tag)
INFO.objectTag: -1  (Java not able to run using <object> tag)
INFO.objectTagActiveX: -1  (Java not able to run using <object> tag with Oracle Java ActiveX)
STATUS: 1  (Java can run. Java is installed & enabled)
verifyTagsArray: can be [2,2,2] or [3,3,3] to get this result

Disabling ActiveX in the Security settings appears to only disable the <object> tag. The <applet> tag will still be able to run/display Java applets.


Case # 3 is a combination of cases # 1 and # 2. We go into the Security Settings and disable Java and ActiveX:

Security Settings: "Java Permissions" set to "Disable Java", and "Run ActiveX Controls and Plugins" set to "Disable"

navigator.javaEnabled( ): false
PluginDetect.browser.ActiveXEnabled: false
INFO.appletTag: -1 (Java not able to run using <applet> tag)
INFO.objectTag: -1  (Java not able to run using <object> tag)
INFO.objectTagActiveX: -1  (Java not able to run using <object> tag with Oracle Java ActiveX)
STATUS: -1  (Java cannot run. It is either not installed, or installed but not enabled)
verifyTagsArray: can be [2,2,2] or [3,3,3] to get this result

Both the <applet> and <object> tags are unable to run Java. It would have been nice if STATUS were -0.2, to actually reveal that Java is "installed but not enabled". But the browser does not reveal enough information to do that.




Java installed but not enabled (Internet Explorer)
& the Manage Add-ons Menu


There is one additional way in which a user may disable Java in Internet Explorer. And that is thru the "Manage Add-ons" Menu. The problem here is that only the applet detection methods are capable of telling when Java is disabled thru this menu. By necessity, you could only use verifyTagsArray = [3, 3, 3] if you want to see if Java is disabled thru the Manage Add-ons menu. Let's say we start with the following detection code:

function displayResults( ){
     var STATUS = PluginDetect.isMinVersion('Java', '0');
     var INFO = PluginDetect.getInfo('Java');
     alert('Java STATUS: ' + STATUS);
     alert('INFO.appletTag: ' + INFO.appletTag);
     alert('INFO.objectTag: ' + INFO.objectTag);
     alert('INFO.objectTagActiveX: ' + 'INFO.objectTagActiveX);
};

// run displayResults when Java detection is done
PluginDetect.onDetectionDone('Java', displayResults, 'getJavaInfo.jar', [3, 3, 3]);


The above code is sufficient to detect 4 special cases where a user disables certain settings in the "Manage Add-ons" Menu.

Case # 1 is where we disable the "Java Plugin" as found in the "Manage Add-ons" Menu. Then the results of the detection code above would yield the following:

Manage Add-ons: "Java Plugin" set to "Disabled"

navigator.javaEnabled( ): true
PluginDetect.browser.ActiveXEnabled: true
INFO.appletTag: 1 (Java able to run using <applet> tag)
INFO.objectTag: 1  (Java able to run using <object> tag)
INFO.objectTagActiveX: -1  (Java not able to run using <object> tag with Oracle Java ActiveX)
STATUS: 1  (Java can run. It is installed and enabled.)
verifyTagsArray: can only be [3,3,3] to get this result.

In order to detect when Java is disabled for any tag in the Manage Add-ons menu, we have to use [3, 3, 3]. In this example, Oracle Java ActiveX is disabled for the <object> tag.


Case # 2 is where we disable just the "Java Runtime Environment":

Manage Add-ons: "Java Runtime Environment" set to "Disabled"

navigator.javaEnabled( ): true
PluginDetect.browser.ActiveXEnabled: true
INFO.appletTag: -1 (Java not able to run using <applet> tag)
INFO.objectTag: -1  (Java not able to run using <object> tag)
INFO.objectTagActiveX: 1  (Java able to run using <object> tag with Oracle Java ActiveX)
STATUS: 1  (Java can run. It is installed and enabled.)
verifyTagsArray: can only be [3,3,3] to get this result.

In order to detect when Java is disabled for any tag in the Manage Add-ons menu, we have to use [3, 3, 3]. In this example, Java is disabled for the <object> and <applet> tags, but the ActiveX in <object> tag still works.


Case # 3 is where we disable both the "Java Plugin" and the "Java Runtime Environment":

Manage Add-ons: "Java Plugin" set to "Disabled", and "Java Runtime Environment" set to "Disabled"

navigator.javaEnabled( ): true
PluginDetect.browser.ActiveXEnabled: true
INFO.appletTag: -1 (Java not able to run using <applet> tag)
INFO.objectTag: -1  (Java not able to run using <object> tag)
INFO.objectTagActiveX: -1  (Java not able to run using <object> tag with Oracle Java ActiveX)
STATUS: -0.2  (Java cannot run. It is installed but not enabled.)
verifyTagsArray: can only be [3,3,3] to get this result.

In order to detect when Java is disabled for any tag in the Manage Add-ons menu, we have to use [3, 3, 3]. In this example, Java is disabled for all tags. We assume here that at least one of the non-applet methods are left enabled in the Manage Add-ons Manu, such as the Java "isInstalled Class", or the "Deployment Toolkit plugin".


And finally, case # 4:

Manage Add-ons: "Java Plugin" set to "Disabled", and "Java Runtime Environment" set to "Disabled", Java "isInstalled Class" set to "Disabled", and "Deployment Toolkit plugin" set to "Disabled"

navigator.javaEnabled( ): true
PluginDetect.browser.ActiveXEnabled: true
INFO.appletTag: -1 (Java not able to run using <applet> tag)
INFO.objectTag: -1  (Java not able to run using <object> tag)
INFO.objectTagActiveX: -1  (Java not able to run using <object> tag with Oracle Java ActiveX)
STATUS: -1  (Java cannot run. Java is either not installed, or installed but not enabled.)
verifyTagsArray: can only be [3,3,3].

In order to detect when Java is disabled for any tag in the Manage Add-ons menu, we have to use [3, 3, 3]. In this example, Java is disabled for all tags.


In summary, to detect when Java is disabled from the Manage Add-ons Menu, you will have to use verifyTagsArray = [3, 3, 3]. The disadvantage to using [3, 3, 3] is that this forces Java to start up and run every time. Unfortunately Java can sometimes take a long time to start up. The user will have to decide whether it is important to them or not to be able to detect these settings in the Manage Add-ons Menu.



Java Detection for Firefox/Opera/Mozilla/Safari

PluginDetect's Java detection has been tested on Windows [Firefox / Netscape / Mozilla / Opera / SeaMonkey / Flock / K-Meleon / Safari], Ubuntu Linux [Firefox], and Macintosh [Safari / Firefox / Opera].

Because Java runs as a plugin in a variety of browsers on different platforms, we find it necessary to use a number of different techniques for plugin detection. Some of these techniques are fast and the end user won't notice any time delay. Others are slow and force the end user to wait for the JRE to initialize.

PluginDetect will use the fastest Java detection methods first (ie. the non-applet methods). If those fail, then slower methods (ie. the applet methods) are used.

One of the slowest techniques involves querying an external applet (ie. getJavaInfo.jar). The applet is only used if the user specifies it, and if all other java detection methods fail to find any installed java.


There are a few cases where the performance of PluginDetect may be limited:

A) Opera 9.0 thru 9.1 on Macintosh appear to have some problems working correctly with Java. This will cause PluginDetect to say that Java is not installed for those browsers. Oddly enough, Opera 8.5 and 9.22 on Macintosh seem to be just fine and PluginDetect has no difficulties with those Opera versions.

B) Firefox in Rosetta mode on Intel Macintosh will not be able to use Java. Java will not run in Rosetta mode, even though Java is installed on your computer. PluginDetect will tell you that Java is not installed/enabled for Firefox in Rosetta mode.

C) IcedTea Java under Linux seems to have some problems with navigator.javaEnabled( ) in Firefox 2, and so PluginDetect may think that java is enabled when in fact the user may have disabled it in his browser settings.


Note that LiveConnect in FireFox/Mozilla will eventually be eliminated, but it will be replaced with NPAPI support so that javascript to java communication is still possible. As such I do not anticipate that this would greatly affect Java detection.



Java Detection for Windows Internet Explorer

The PluginDetect script can determine the Java version for Internet Explorer 5.5 and higher.

If you are viewing this page with Internet Explorer, you may notice at the very top of this page that Java is detected for the <applet> tag and the <object> tag separately. Usually when Java is installed, both the <applet> and the <object> tag are capable of being used to display a Java applet in a web page - usually, but not always. Sometimes it is possible that only one of those tags can display the applet, while the other tag is disabled.

The <applet> tag, though deprecated, usually uses the Oracle JVM (Java Virtual Machine) to display a Java applet. When you disable Java in Internet Explorer's security settings, you are only disabling the <applet> tag from running a Java applet - the <object> tag is unaffected and still capable of running an applet. When the <applet> tag is disabled, navigator.javaEnabled( ) will be false.

The <object> tag in Internet Explorer can implement an ActiveX control that specifically runs Oracle Java. When the <object> tag has a classid='clsid:8AD9C840-044E-11D1-B3E9-00805F499D93', you are running the most recent Oracle Java version. When you disable ActiveX in the security settings then the <object> tag with classid is disabled - but the <applet> tag will be unaffected.



Oracle Java, ActiveX, and Internet Explorer 7+

The tricky part for plugin detection in IE 7+ is that we want to avoid triggering any security alerts when instantiating ActiveX control(s).

There is one Oracle Java ActiveX control that is pre-approved by Microsoft for all Java versions, and hence will not trigger any alerts when instantiated. This control has a classid of {8AD9C840-044E-11D1-B3E9-00805F499D93}. This classid is for dynamic versioning of Java. You may instantiate the most recent version of this control by using <object classid='clsid:8AD9C840-044E-11D1-B3E9-00805F499D93'></object> in your html document. PluginDetect sometimes uses this pre-approved ActiveX control to find the Oracle Java version.

There are some other Java related ActiveX controls. For JRE 1.6.0_01 and lower versions, they are not pre-approved, and thus could cause a security alert popup in IE 7+. However, JRE 1.6.0_02 and higher seem to have their ActiveX controls pre-approved and should not cause any security message popups in IE 7+.

Some examples of these other ActiveX controls are ActiveXObject('JavaPlugin'), ActiveXObject('JavaWebStart.isInstalled'), ActiveXObject('JavaWebStart.isInstalled.1.6.0.0'), and ActiveXObject('JavaPlugin.150_07'), etc...

PluginDetect will make use of some of these controls wherever appropriate to determine the Oracle Java version.



Java Detection Speed in Internet Explorer

The disadvantage of using a Java applet in a web page to detect Java is that you have to wait for the Java Runtime Environment to fully load, and then you have to wait for the applet to run, before you can query the applet to get the Java version. The startup times for Java have gotten especially slow with Java 1.6 in Internet Explorer.

However, since the release of JRE 1.6.0_02 it is possible for PluginDetect to get the Java version without loading the entire JRE. This means that if you have JRE 1.6.0_02 or higher installed on your system, then PluginDetect will detect the version very quickly, without the need for loading and starting the entire Java Runtime Environment. This should be very fast.

PluginDetect attempts to detect Java using the fastest detection methods first. If that fails, PluginDetect will use slower methods.



PluginDetect also uses the Deployment Toolkit (DTK) plugin

Oracle has released a Deployment Toolkit (DTK) browser plugin bundled with JRE JRE 1.6.0_10 (or higher). One of the reasons the Deployment Toolkit plugin is useful is that it allows us to detect Java without the need to first fully load and run the JRE. In other words, the DTK plugin allows for very fast Java plugin detection.

The DTK browser plugin so far only exists for Windows. There does not appear to be a DTK plugin for Macintosh or Linux yet.

I want to make it clear that the DTK browser plugin is not the same as the DTK script. The DTK script is a javascript by Oracle named "deployJava.js". It was created to assist in Java detection/deployment. It makes use of the DTK plugin whenever it is available. But it is possible to use the DTK script even if the DTK browser plugin is not present.

PluginDetect will make use of the DTK plugin whenever possible. If the DTK plugin is not installed, then PluginDetect will use any one of several other methods to detect Java.

The disadvantage of relying only on the DTK plugin to do Java plugin detection is obvious: the DTK plugin is relatively new, it only appears to exist for Windows (so far), it does not come bundled with any JRE version < 1.6.0_10, and it does not appear to know when Java is disabled in the browser. Thus we cannot count on the DTK plugin being present on everyones system (at least not for a little while). Hence, PluginDetect uses several methods in addition to the DTK plugin to do Java detection.



Detecting Multiple JREs

Detecting multiple Java installations on a computer is not always possible. Sometimes the browser will only permit you to see and use the highest installed Java version, while ignoring all the lower versions. Nevertheless PluginDetect will attempt to find all possible Java JREs that are installed.

Before you attempt to detect multiple JREs, you will need to actually use the getVersion('Java', ...) or the isMinVersion('Java', ...) method. [Note that the getVersion( ) method will only return the highest installed Java version, since that is the version that most browsers will use by default]. Once you have done this, you will be able to check for multiple versions. For example:

var all = PluginDetect.getInfo('Java', 'getJavaInfo.jar').All_versions; // sorted array, from highest to lowest
if (all.length>0) alert("The Java versions are" + all.join(' & '))
else alert('Java not detected');


The PluginDetect.getInfo('Java').All_versions[ ] array will contain a sorted list of all Java versions that could be detected thru your browser.

The All_versions[ ] array has the best chance of detecting multiple JREs if you have the Deployment Toolkit (DTK) plugin installed in your browser. The reason is that the Deployment Toolkit plugin can see multiple JREs even if the browser itself cannot. If the DTK is not present, then PluginDetect will get as much information from the browser as possible in order to fill the All_versions[] array.

It appears to me that detecting multiple JREs from within a single browser is mostly for Windows users.

You should also be aware that there is a big difference between detecting the Java JRE's and being able to run the detected JREs in your browser. Using the traditional Java browser plugin, many browsers will only run the highest installed JRE version while ignoring the lower ones. However, the next generation Java plugin allows you to choose the Java version that runs. The next-gen plugin is available for Java 1.6.0_10 or higher.


Top of Page