http://www.pinlady.net/PluginDetect/JavaDetect.htm

Java Plugin Detector

Download PluginDetect and the jarfile here...

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

1) download the getJavaInfo.jar along with a few Java detection examples. The jarfile is used by PluginDetect in order to accomplish Java detection.

2) download the PluginDetect script itself. The PluginDetect script generator will allow you to customize the PluginDetect script to include whatever features you desire.

That being said, I would still recommend that you read thru most of this page before creating your own Java detection code.


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 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.

As to the issue of timing, we can say that Java detection is performed either "on the fly" (OTF) or "not on the fly" (NOTF) in your script. Any single line of Javascript code that is able to both initiate and complete Java detection is said to be OTF. No Javascript code is executed by the browser in between the initiation and the completion of the Java detection. All non-applet methods are performed OTF. And usually, the applet methods are OTF as well. [BTW, all non-Java plugins detected by PluginDetect are OTF.]

For NOTF detection, the browser is able to execute Javascript code in between the initiation and the completion of Java detection. In other words, after you initiate detection the browser will keep executing Javascript commands while you are waiting for the Java results. NOTF Java detection only occurs for the applet methods, and only some of the time.


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 the format of "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. The +0.5 number only occurs for NOTF detection of the Java plugin. The plugin appears to be installed (& enabled). Other Java info may or may not be available at this point in time. You will have to wait until detection has completed to get all the detection info. When the plugin detection has been completed, the isMinVersion() method will return 1, 0, or -1.
   Returns 0 if plugin installed (& enabled). The plugin version is unknown, and thus we are unable to determine if version >= minVersion.
   Returns -0.2 if Java installed but not enabled. Some browsers occasionally reveal enough info to make this determination.
   Returns -0.5 if plugin detection has been initiated but is not yet completed. The -0.5 number only occurs for NOTF detection of the Java plugin. It is not known yet whether the plugin is installed or what the plugin version is. When the plugin detection has been completed, the isMinVersion() method will return 1, 0, or -1.
   Returns -1 if plugin version < minVersion, or if plugin is not installed / not enabled.
   Returns -3 if you supplied a bad input argument to the isMinVersion() method.

PluginDetect.onDetectionDone('Java', f, jarfile, verifyTagsArray): [Returns number]
   Even though you can use this method for any plugin, you only really need to use it for NOTF Java detection.
   The 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){ ... }.
   This method is useful as sometimes Java detection results are available at unpredictable times - meaning that Java detection is not always possible "on the fly". Hence, the onDetectionDone() method will wait as long as necessary until the Java detection has completed before executing handler f. You are free to use getVersion() and isMinVersion() inside handler f to see the detection results.
   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 so handler f has not been executed yet.
   Returns -1 if error (plugin name input argument not specified correctly).

PluginDetect.beforeInstantiate('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 beforeInstantiate() 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 the PluginDetect object
       PD.beforeInstantiate('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, and after the plugin detection results are 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 getVersion(), isMinVersion(), onDetectionDone(), and beforeInstantiate() 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.beforeInstantiate(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.beforeInstantiate(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]
   Returns an object with several useful properties. The properties are listed below. To simplify matters, we assign this object to a variable:
    var INFO = PluginDetect.getInfo('Java', jarfile, verifyTags);

INFO.isPlugin2: [number] This tells us if the next generation Java plugin is installed in your browser. A brief description is given by Sun.
   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 and/or not enabled in your browser.

INFO.PLUGIN: [object or null] When PluginDetect needs to insert a Java applet into the web page to perform Java detection, this parameter will point to that Java applet. Otherwise this parameter is null.

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.DeploymentToolkitPlugin: [object or null]
   Returns the Java Deployment Toolkit plugin object, assuming the Toolkit is installed and enabled.
   Returns null otherwise.
Sun Java 1.6.0.10+ for Windows comes with the Deployment Toolkit plugin.

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 DeployTK_versions array).

INFO.vendor: [string]
   The Java vendor. Possible value are 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 <object> tag can be used to run/display a Java applet in your browser. This parameter only refers to <object> tags that do not use ActiveX to run Java.
   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 also appears to be functional for this <object> tag. The path/filename given for jarfile appears to be correct.
   Returns 0 if Java is installed and enabled and this <object> tag can run a Java applet. The Javascript to Java bridge does not appear to be functional, or the path/filename given for jarfile is incorrect.
   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. The <applet> tag does not use ActiveX to run Java.
   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 also appears to be functional for this <applet> tag. The path/filename given for jarfile appears to be correct.
   Returns 0 if Java is installed and enabled and this <applet> tag can run a Java applet. The Javascript to Java bridge does not appear to be functional, or the path/filename given for jarfile is incorrect.
   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 ActiveX can be used to run/display a Java applet in your browser. This particular <object> tag uses Sun 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 also appears to be functional for this <object> tag. The path/filename given for jarfile appears to be correct.
   Returns 0 if Java is installed and enabled and this <object> tag can run a Java applet. The Javascript to Java bridge does not appear to be functional, or the path/filename given for jarfile is incorrect.
   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 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.

   There are 2 versions of the jarfile available. Version 1 of the jarfile is named "getJavaInfo.jar" and is 359 bytes. Version 2 of the jarfile is named "getJavaInfo2.jar" and is 485 bytes. Both versions of the jarfile are compatible with PluginDetect, and you may use either version in your Java detection scripts. (Do NOT try to use both versions in the same web page.)
   The version 1 jarfile (getJavaInfo.jar) allows PluginDetect to query the JRE directly to determine the Java version and Java vendor. The version 2 jarfile (getJavaInfo2.jar) does everything that version 1 does, AND also the following:

        a) it allows PluginDetect to query the JRE for any additional Java properties that the JRE is willing to reveal. The query is in the format of System.getProperty(S) where S could be 'java.version', 'java.vendor', 'java.vm.name', 'java.vm.specification.name', etc... This feature is currently not being utilized by PluginDetect, but it will be in a future PluginDetect version.

        b) it allows PluginDetect to try to erase the "Applet A Started" message in the browser statusbar, which occurs in some browsers when the jarfile applet is running. The erase will only work if the browser allows this. The erase occurs from Java via the applet, not purely from Javascript. This is mostly intended for some older browsers, which tend to leave the "Applet A Started" message in the statusbar even after the page has fully loaded.  

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 <object> tag detection method (ie. one of the applet detection methods). It determines when the <object> tag (without ActiveX) with jarfile is 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 the <applet> tag (without ActiveX) with jarfile is 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 the <object> tag (with ActiveX) with jarfile is used for Java detection. The result of this detection is given by INFO.objectTagActiveX.

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 simple PluginDetect examples to detect Java

If you want to detect if Java is installed or not in your browser, you could use the following code:

var Java0Status = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar');
var Java0Installed = Java0Status >=0 ? true : false;

The variable Java0Installed will be true or false, depending on whether Java is present or not. You will note that because we check for Java0Status >= 0, we are detecting all the JVM's (Java Virtual Machine) where the Java version can and cannot be detected. In other words, if PluginDetect can determine that Java is present but cannot determine the Java version, then Java0Installed is true. Also, if PluginDetect can determine that Java is present and can determine the Java version, then Java0Installed is true.

On the other hand, suppose you wanted to check that JRE (Java Runtime Environment) 1.5 or higher was installed. The way you could do that is here:

var Java15Status = PluginDetect.isMinVersion('Java', '1.5', 'getJavaInfo.jar');
var Java15Installed = Java15Status == 1 ? true : false;

The variable Java15Installed will be true or false. If Java is present (and enabled) and the Java version is detected to be 1.5 or higher, then Java15Installed is true. If Java is present (and enabled) and the Java version is detected to be less than 1.5, then Java15Installed is false. If Java is not enabled, then Java15Installed is false. If Java is present but the Java version could not be detected, then Java15Installed is false.

If you want to find the Java version, then we can use this:

var JavaVersion = PluginDetect.getVersion('Java', 'getJavaInfo.jar');

For most people, these simple examples will probably be sufficient. On the other hand, there are some subtle issues involved with Java detection. I would recommend that you read the rest of this page before writing any Java detection code for your own website.



Introducing ON THE FLY & NOT ON THE FLY detection

Java detection with PluginDetect can occur in one of 2 ways: On The Fly (OTF) or Not On The Fly (NOTF). It all depends on the browser, the OS, and the type of Java you are using.


OTF detection means that you can get the Java detection results at any point in your javascript...whenever you want, wherever you want. For example, suppose you were using the Firefox browser under Windows XP with Sun Java 1.6. Also suppose you had a javascript in your web page that consisted of only 3 lines:

var JavaVersion = PluginDetect.getVersion('Java', 'getJavaInfo.jar');
var Java0Status = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar');
alert('Java version is ' + JavaVersion + '\n' + 'Java status is ' + Java0Status);

Java detection is initiated and completed in the first 2 lines of code. The results are JavaVersion equal to '1.6.0.0' and Java0Status equal to 1. This detection is said to be OTF (on the fly), because the final results were made available exactly where and when you specify.

In other words, the 1st line of code initiates the Java version detection, and completes the detection to get the installed Java version (JavaVersion = '1.6.0.0'). The 2nd line of code initiates Java status detection, and completes the detection to get the Java status (Java0Status = 1).


NOTF detection, on the other hand, means that you can only get the final java detection results at certain times and in certain places in your script. NOTF occurs rarely with PluginDetect, but it can happen. For example, suppose you were using the Konqueror browser under Ubuntu Linux with Java 1.6. Also suppose we had the same 3 line script:

var JavaVersion = PluginDetect.getVersion('Java', 'getJavaInfo.jar');
var Java0Status = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar');
alert('Java version is ' + JavaVersion + '\n' + 'Java status is ' + Java0Status);

Konqueror often requires NOTF to do java detection. In this case, the 1st line of code initiates Java version detection, but does not complete the detection. And so JavaVersion = null instead of '1.6.0.0'. The 2nd line of code initiates Java status detection, but does not complete the detection. And so Java0Status = -0.5 (or possibly +0.5) instead of 1.

Whenever you get a -0.5 or +0.5 value for the isMinVersion() method, it means that Java detection has started but has not yet completed, and the final results will be available at a later time.


Okay. Now let us consider a slightly more complicated script to better illustrate OTF and NOTF:

var JavaVersionA, JavaVersionB;
var Java0StatusA, Java0StatusB;

JavaVersionA = PluginDetect.getVersion('Java', 'getJavaInfo.jar');
Java0StatusA = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar');

function Q(){
   JavaVersionB = PluginDetect.getVersion('Java', 'getJavaInfo.jar');
   Java0StatusB = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar');

   alert('statusA: ' + Java0StatusA + '\n' + 'versionA: ' + JavaVersionA + '\n' +
      'statusB: ' + Java0StatusB + '\n' + 'versionB: ' + JavaVersionB);
};

PluginDetect.onWindowLoaded( Q ); // Execute Q after the window has loaded

For Firefox under Windows XP with Sun Java 1.6, the above script will use OTF. We would have Java0StatusA = 1 and JavaVersionA = '1.6.0.0' [ie. Java detection was initiated and completed]**. And after the window has loaded, function Q executes to give us Java0StatusB = 1 and JavaVersionB = '1.6.0.0'.

For Konqueror under Ubuntu Linux with Java 1.6, the above script would most likely use NOTF. We would have Java0StatusA = -0.5 (or possibly +0.5) and JavaVersionA = null. Again, this means that Java detection was initiated, but the final results are not yet available (ie. not until the JRE can start or until the window.onload event has occured). After the browser window has fully loaded, Java detection will have been completed so that Java0StatusB = 1 and JavaVersionB = '1,6,0,0'.

For 99% of all browsers and Java vendors and platforms, PluginDetect will use OTF. I'm guessing that less than 1% of web users would need NOTF. NOTF is needed to detect Microsoft Java in Internet Explorer. It is also needed for Konqueror under Linux. There are some rare cases where the Opera browser may require NOTF, though usually Opera*** will use OTF. There may be a few other special cases that require NOTF that I am not aware of.

[** To be more precise, the first time you use PluginDetect.isMinVersion(plugin) in a script, the results are simply stored in memory. So when you try to use PluginDetect.isMinVersion(plugin) a second, third, or Nth time, you are only retrieving that result from memory, as opposed to doing the actual detection over and over again. The same can be said for PluginDetect.getVersion(plugin).]

[*** Both Opera and Konqueror do not use any Java plugin. They use the java binary directly. Hence detection is a bit of a problem for those browsers. For Opera, it is usually possible to simply query the Java binary directly to get the java version, which can be done OTF.]



How to do both OTF and NOTF java detection

In the previous section, we saw how the PluginDetect.onWindowLoaded() method could be used to handle both OTF and NOTF detection. We initiated detection in the our script before the window loaded (JavaVersionA and Java0StatusA), and then waited until after the window fully loaded to get our final result (JavaVersionB and Java0StatusB).

While onWindowLoaded() certainly works, it is a bit awkward. It always forces you to wait for the entire web page to load to get your results, even if Java detection could be completed long before that. For example, say you have a large image embedded in your web page, and this page takes 2 minutes to download from the server. Then you would not have your final java results for a full 2 minutes. That would be annoying.

To solve this problem, I came up with the PluginDetect.onDetectionDone() method. Consider the following script:

var Java0Status, Java0Installed, JavaVersion;

function displayResults($){    // event handler receives PluginDetect as an input argument
   Java0Status = $.isMinVersion('Java', '0', 'getJavaInfo.jar');
   JavaVersion = $.getVersion('Java', 'getJavaInfo.jar');
   Java0Installed = Java0Status >= 0 ? true : false;
   alert('Java Version : ' + JavaVersion);
   alert('Java Status : ' + Java0Status);
   alert('Java Installed : ' + Java0Installed);
};

// Initiate Java detection, execute the event handler displayResults() as soon as Java detection completed
PluginDetect.onDetectionDone('Java', displayResults, 'getJavaInfo.jar');

var dummyVar = 25;   // These 2 lines of code serve no real purpose
var dummyVar1 = 26;

When the script reaches the PluginDetect.onDetectionDone() method, java detection is initiated. There are 2 possible outcomes at this point:

A) Java detection is OTF (On The Fly). The detection is completed, and then the displayResults() method is executed. And then the script continues executing the next lines of code [ie. var dummyVar = 25; var dummyVar1=26; etc...].

B) Java detection is NOTF (Not On The Fly). This means that the java detection will not be completed right away in your script. Instead, your javascript will continue executing code (ie. var dummyVar=25; var dummyVar1=26; etc...) and then at some later point the java detection will be completed. Only then, once the java detection has completed, will the displayResults() method be executed.
   While you are waiting for displayResults() to run, however, the value of PluginDetect.isMinVersion('Java') would be -0.5 or +0.5, and the value of PluginDetect.getVersion('Java') would be null. And once displayResults() actually does run, the value of PluginDetect.isMinVersion('Java') would be 1, 0, or -1.
   Again, the displayResults() method will be executed no later than window.onload. But if your web page loads slowly (for whatever reason...like having a large embedded image) the displayResults() method will likely execute long before window.onload.

Note that if you disable NOTF, then only outcome A) shown above will occur. Disabling NOTF is discussed in the next section.

You are permitted to use PluginDetect.onDetectionDone() multiple times in the same script. For example:

PluginDetect.onDetectionDone('Java', method1, jarFile);
PluginDetect.onDetectionDone('Java', method2, jarFile);
PluginDetect.onDetectionDone('Java', method3, jarFile);
PluginDetect.onDetectionDone('Java', method4, jarFile);

The methods will be executed in the order in which they were specified. First method1(), then method2(), then method3(), and finally method4().



How to disable NOTF detection

If you want, you are free to disable NOTF detection. There are a couple ways:

1) NOTF is disabled when the jarfile argument is absent. By this I mean that the jarFile argument needs to be absent from any and all PluginDetect methods in your script. Most people, however, will prefer to keep the jarfile argument since it makes overall java detection more reliable.

2) NOTF can be disabled when generating the PluginDetect script. When the Java checkbox is selected, simply deselect the "Enable NOTF" checkbox.

I would recommend using option 2) to turn off NOTF. That way you are free to use the jarfile.

When NOTF is disabled, then PluginDetect.isMinVersion() will never be -0.5 or +0.5. For Microsoft Java in Internet Explorer, PluginDetect.isMinVersion() would be -1. For Konqueror under Linux, PluginDetect.isMinVersion() would be -1.


Java detection with onWindowLoaded()

We now know that the onDetectionDone('Java', displayResults, jarfile) method executes the event handler displayResults() right away for OTF, or at some later time for NOTF.

But what if we wanted displayResults() to always run after the window has loaded? Let us look at a simple script example on how to do this:

var Java142Status, Java142Installed, JavaVersion;

PluginDetect.onDetectionDone('Java', 0, 'getJavaInfo.jar'); // Dummy statement that forces java detection to begin

function displayResults($){    // event handler receives PluginDetect as an input argument
   Java142Status = $.isMinVersion('Java', '1.4.2.0', 'getJavaInfo.jar');
   JavaVersion = $.getVersion('Java', 'getJavaInfo.jar');
   Java142Installed = Java142Status == 1 ? true : false;
   alert('Java Version : ' + JavaVersion);
   alert('Java 1.4.2.0 Status : ' + Java142Status);
   alert('Java 1.4.2.0 or higher Installed & Enabled: ' + Java142Installed);
};

PluginDetect.onWindowLoaded(displayResults);

The onDetectionDone() method causes Java detection to initiate. If detection is OTF (on the fly), then the Java detection is completed and the results are stored in memory. If detection is NOTF (not on the fly), then the Java detection will be completed no later than window.onload. At which point the results are stored in memory.

You will note the '0' input argument to onDetectionDone() is a dummy input. We do not want the onDetectionDone() method to actually do anything here, other than initiate the Java detection.

The very last line introduces the PluginDetect.onWindowLoaded() method. It will execute the displayResults() function after the browser window has loaded and after Java detection has completed.

The displayResults() method itself simply retrieves the detection results from memory. In other words, displayResults() only runs after the Java detection has completed.


Note that you are free to use the onWindowLoaded() method multiple times in the same script:

PluginDetect.onWindowLoaded(method1);
PluginDetect.onWindowLoaded(method2);
PluginDetect.onWindowLoaded(method3);
PluginDetect.onWindowLoaded(method4);

After the window has fully loaded, the methods will be executed in order. First method1() is executed, then method2(), method3(), and finally method4().



onWindowLoaded() & window.addEventListener('load')

It should be said at the outset that you may use onWindowLoaded() independent of any Java detection. Just remember to select the onWindowLoaded() option when using the PluginDetect script generator.

By now you are probably wondering why one could not use window.onload, window.addEventListener('load'), or window.attachEvent('onload') instead of onWindowLoaded(). Indeed in most general situations you could, with one important exception: the window.onload, window.addEventListener('load'), and window.attachEvent('onload') methods are not recommended when doing NOTF Java detection via PluginDetect. With NOTF Java detection, you should use onWindowLoaded() and/or onDetectionDone().

For example, the following is a script that you should not ever use if NOTF detection is enabled:

var Java142Status, Java142Installed, JavaVersion;

PluginDetect.onDetectionDone('Java', 0, 'getJavaInfo.jar'); // Dummy statement that forces java detection to begin

function displayResults(){
   Java142Status = PluginDetect.isMinVersion('Java', '1.4.2.0', 'getJavaInfo.jar');
   JavaVersion = PluginDetect.getVersion('Java', 'getJavaInfo.jar');
   Java142Installed = Java142Status == 1 ? true : false;
   alert('Java Version : ' + JavaVersion);
   alert('Java 1.4.2.0 Status : ' + Java142Status);
   alert('Java 1.4.2.0 or higher Installed & Enabled: ' + Java142Installed);
};

window.addEventListener('load', displayResults, false); // Run displayResults() after window loads

The above script certainly seems reasonable to use, doesn't it? However, for the NOTF case there is a timing issue. It has to do with the way in which PluginDetect operates. I don't really want to go into any detailed reasons here. I see no need to complicate things even further. Just know that the last line in the script above should use the onWindowLoaded() method (or even the onDetectionDone() method).

Note: the onWindowLoaded() method will not interfere with any function you may have assigned to window.onload. This was done to maintain the unobtrusiveness of PluginDetect.



The jarfile input argument

The use of the jarfile input argument is strongly recommended. PluginDetect can usually detect Java without it. However, there are a few cases (ie. older versions of Safari on Macintosh, and Microsoft Java and other non-Sun JREs on Internet Explorer, Konqueror under Linux, etc...) that appear to require the jarfile in order to detect Java. I would recommend using the jarfile 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;

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

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

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;
var tmp = PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar'); // begin java detection

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

Example #6

var Java142Status, JavaVersion;
var tmp = PluginDetect.getVersion('Java', 'getJavaInfo.jar'); // begin java detection

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.onWindowLoaded(displayResults); // run displayResults() when window has loaded

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


And finally, you need to make sure that the specified path of the jarfile 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 the specified path is correct. Assuming you have Java installed and enabled on your system, you can test this by temporarily setting verifyTagsArray to [3,3,3]. The [3,3,3] value will force PluginDetect to only use the jarfile applet for Java detection. We then examine the value of PluginDetect.getInfo().objectTag and PluginDetect.getInfo().appletTag. If any of them return a 1, then everything is correct.

For instance, suppose that you wanted to verify that using 'ABC/getJavaInfo.jar' in your Java detection was correct. You could use this code to do precisely that:

function verifyJarfile(){
   var INFO = PluginDetect.getInfo('Java');
   
   if (INFO.appletTag == 1 || INFO.objectTag == 1 || INFO.objectTagActiveX == 1)
         alert('path and filename of jarfile appear to be correct')
   else alert('Error, check jarfile path. Also make sure Java is enabled');
};

PluginDetect.onDetectionDone('Java', verifyJarfile, 'ABC/getJavaInfo.jar', [3, 3, 3]);

Once you have verified that the jarfile name and path are correct, you can go back to using whatever value for verifyTagsArray you want. To learn more about the verifyTagsArray, see the next section.



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 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 of [2,2,2]. 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. The value of INFO.appletTag will be null in this case.

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

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

   verifyAppletTag = 3: means that the <applet> tag method is always used to do Java detection.
   INFO.appletTag will always have a numerical value in this case.

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 Java, then we are done. If it does not give any result on the fly, then the <applet> tag method is used. If it succeeds in detecting Java, then we are done. If it does not give any result on the fly, then the <object> tag ActiveX method will be used (for Internet Explorer only). If it succeeds in detecting Java, 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 these applets.

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.

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 will default to a value of [2, 2, 2]. 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 <object> tag into the web page:

For Internet Explorer, the HTML is (without ActiveX)

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

For all other browsers, the HTML is

<object archive="[path]getJavaInfo.jar" classid="java:A.class" type="application/x-java-applet" width="1" height="1">
<param name="archive" value="[path]getJavaInfo.jar" />
<param name="mayscript" value="true" />
<param name="scriptable" 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:

<applet archive="[path]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="archive" value="[path]getJavaInfo.jar" />
<param name="code" value="A.class" />
<param name="mayscript" value="true" />
<param name="scriptable" 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, 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 of [2, 2, 2]. The command PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar', [2, 2, 2]) has the exact same meaning as PluginDetect.isMinVersion('Java', '0', 'getJavaInfo.jar').



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

Suppose that we are using the following plugin detection code:

PluginDetect.onDetectionDone('Java', 0, 'getJavaInfo.jar', [2, 2, 2]);   // begin java detection

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);
};

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

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)

INFO.appletTag: -1 (Java not able to run using <applet> tag)
INFO.objectTag: -1  (Java not able to run using <object> tag)
navigator.javaEnabled(): irrelevant (its value has no importance here)
verifyTagsArray: can be [1,1,1] or [2,2,2] or [3,3,3] or some combination thereof to get this result

non-applet detection methods: unable to detect Java
applet detection methods: unable to detect 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)

INFO.appletTag: -1 (Java not able to run using <applet> tag)
INFO.objectTag: -1  (Java not able to run using <object> tag)
navigator.javaEnabled(): false
verifyTagsArray: can be [1,1,1] or [2,2,2] or [3,3,3] or some combination thereof to get this result

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

From my own testing, I have found a few examples where PluginDetect will give you a STATUS == -0.2 for the non-IE browsers. Assuming that Java is installed, they are:

1) In Firefox 2, you disable Java in the browser's options.

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

3) In Safari/Windows, you disable Java in the browser's preferences.

[Note: Disabling Java in your non-IE browser is fairly trivial. You just go into your browser Preferences / Options, and deselect the "Java enabled" box. This should usually disable Java for both the <applet> tag and the <object> tag. The navigator.javaEnabled() method will then return false.]

There are, however, a few examples where disabling Java in the browser settings will not really have the expected result. In testing Konqueror 3.5.8 under Ubuntu Linux, I learned that 'disabling' Java in the browser settings does not disable the <object> tag. But the navigator.javaEnabled() parameter is false and INFO.appletTag is -1, as expected. In other words, Java is still installed and enabled because the <object> tag can run/display Java applets in a web page.


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.

If you want PluginDetect to be able to find (whenever possible) that Java is "installed but not enabled", then use non-zero values in the verifyTagsArray. You could use verifyTagsArray = [1,1,1] or [2,2,2] or [3,3,3] if you wanted to, or some combination thereof. (The default value of [2, 2, 2] for verifyTagsArray will get the job done.)



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:

PluginDetect.onDetectionDone('Java', 0, 'getJavaInfo.jar', [2, 2, 2]);   // begin java detection

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);
};

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

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.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 Sun Java ActiveX)
STATUS: 1  (Java can run. Java is installed & enabled)
verifyTagsArray: can be [1,1,1] or [2,2,2] or [3,3,3] or some combination thereof 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.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 Sun Java ActiveX)
STATUS: 1  (Java can run. Java is installed & enabled)
verifyTagsArray: can be [1,1,1] or [2,2,2] or [3,3,3] or some combination thereof 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.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 Sun Java ActiveX)
STATUS: -1  (Java cannot run. It is either not installed, or installed but not enabled)
verifyTagsArray: can be [1,1,1] or [2,2,2] or [3,3,3] or some combination thereof 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:

PluginDetect.onDetectionDone('Java', 0, 'getJavaInfo.jar', [3, 3, 3]);   // begin java detection

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);
};

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

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.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 Sun 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, Sun 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.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 Sun 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.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 Sun 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.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 Sun 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 an 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.

I myself recommend using [2, 2, 2], which is the default value for verifyTagsArray. I believe that most people who browse the web using Internet Explorer won't bother using the Manage Add-ons Menu anyway.



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 Sun Java version for Internet Explorer 5 and higher. The outdated Microsoft Java Virtual Machine will only be detected with NOTF.

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, uses the Sun JVM (Java Virtual Machine) or the Microsoft JVM 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 Sun Java. When the <object> tag has a classid='clsid:8AD9C840-044E-11D1-B3E9-00805F499D93', you are running the most recent Sun 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.



Sun 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 Sun 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 Sun 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 yellow bar security popup 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 Sun 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

Sun 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 Sun 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 solves this particular problem. The next-gen plugin is available for Java 1.6.0_10 or higher.



Does PluginDetect Not Detect Your Java?

Are you on Linux, and PluginDetect does not detect Java in your browser? Are you using some kind of open source Java, and PluginDetect does not detect that?

Whatever the case may be, there is a way you can help. If you are using a browser other than Internet Explorer, and PluginDetect does not detect Java for your particular browser/OS, then visit this web page here. Select all the text on that page, copy and paste the text into a text file. And then email that file to Eric Gerds

<b>[TURN ON JAVASCRIPT TO SEE EMAIL ADDRESS]</b> Your help is greatly appreciated.


/*    By Eric Gerds


 getJavaInfo.jar v2
 ---------------------
 Rename getInfo() to getProp()


 getJavaInfo.jar v2 beta1
 -------------------------
 We added 2 more methods to the applet.
    getInfo(String S) - returns value of System.getProperty(S)
    statusbar() - sets the value of the browser status bar from Java.
       This only works sometimes depending on the browser, but it could allow you to
       overwrite the "Applet Started" message in the status bar when an applet starts up.
 This applet is backwards compatible with any Javascripts that use getJavaInfo.jar v1.


 getJavaInfo.jar v1
 ---------------------
 The very first version of our jar. Has 2 public methods:
     getVersion() - returns Java version
     getVendor() - returns Java vendor


*/

import java.applet.*;

 public class A extends Applet
 {

    public String getProp(String S)
    {
       String o="";
       try{
           if (S instanceof String) o=System.getProperty(S);
       }
       catch(Exception e){};
       return o;
    }

    public String getVersion()
    {
       return getProp("java.version");
    }

    public String getVendor()
    {
       return getProp("java.vendor");
    }

   
/*  Set the browser window status bar from within this applet.

    We would like to prevent the window status bar from showing the "Applet A started"
    message when detecting Java. This message only occurs in some browsers, not all.
    We can solve this problem using the showStatus("") method from within the Java applet.

    - Is the showStatus method compatible with Java 1.3?

    - Even when you cannot set window.status from Javascript, it is still possible
     in some browsers for the applet to affect the status bar. Hence it is probably best
     to set the status bar from within the applet using showStatus().

    - Note, some browsers show the word "Done" in the status bar after the page has fully
    loaded (ie. window.onload has fired). We want to avoid overwriting the 'Done'.

*/
    public void statusbar(String S)
    {
       try{
           if (S instanceof String) showStatus(S);
       }
       catch(Exception e){};
    }
 }