Skip to main content

Tracking Java Versions using Google Analytics

57 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24
Points: 0

Guys,

I just posted a blog entry explaining how to track the Java version of your website visitors: http://cowwoc.blogspot.com/2008/11/tracking-java-versions-using-google.html

I would love to see Google integrate this as a standard feature of Google Analytics but in the meantime we can do it ourselves. If you own a popular website please share your statistics with everyone else. I'd love to find out what Java usage is like in the wild.

Thank you,
Gili Tzabari

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mbien
Offline
Joined: 2007-04-29
Points: 0

functionality to detect _SUN 6u10 on linux would be a nice move from sun nonetheless. (just to make a handfull of devs happy ;-) )

trembovetski
Offline
Joined: 2003-12-31
Points: 0

> I also don't understand Sun's reluctance to invest in detecting non-Sun JREs. I would understand if you did some research and found out that 95% of users use Sun JDK so there is no point detecting the remaining 5% but I don't think this kind of research has been done in the first place.

I think in some cases common sense is enough to justify not investing time in obviously unnecessary research.

We're talking about client here, right? Ostensibly there are only three kinds of client VMs out there - Microsoft, Apple and Sun's.

IcedTea and stuff is nice, but it can't be on more than than 1% of systems out there (see data on Linux's penetration on desktop)..

Dmitri

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> IcedTea and stuff is nice, but it can't be on more
> than than 1% of systems out there (see data on
> Linux's penetration on desktop)..

Fair enough, but then Sun should be putting out the signal: "Currently we only support these platforms but if you're a JVM vendor and you'd like to see DT support it then we welcome your contributions". Sun should be welcoming these kinds of contributions in the context of OpenJDK.

Gili

rogyeu
Offline
Joined: 2006-07-30
Points: 0

You won't be able to detect which update without DT Plug-In. Therefore, it is not possible to return 1.6.0* for other update releases w/out DT Plug-In. If there's a DT Plug-In, you will be able to tell the update release info. I think case #1 is really minimal. I really don't see any major benefit in this change. If you prefer, you can submit an RFE to http://bugreport.sun.com, I will open a bug report for it.

>What about other browsers such as Safari? Do you only support IE and Mozilla?
>What operating systems does this work on? What is the earliest JRE version you
>can detect?
>When I say I'm looking for an extensive list I am expecting you to reply with
>something like this...
Please see here for support platforms: http://java.sun.com/javase/6/webnotes/install/system-configurations.html (you can find it on http://java.sun.com/javase/downloads/index.jsp ).

The earliest version can be detected is 1.3.0

>I'm not sure I understand. What registry settings? What non-Sun vendor
>does this today? I assume none... Does this mean that the DT only detects Sun JREs?
>Does Sun plan on actively encouraging other vendors to port the DT plugin to their
>platforms?
Please understand DT has 2 parts: JavaScript and PlugIn. The JavaScript part returns the Java version by checking the WebStart ActiveX object in IE, and mime type in Mozilla family browsers. It works on our supported platform even before 6u10. It should return correct version info if other JREs are returning the correct info.

DT PlugIn is currently only available on Windows. Therefore, no need to detect IcedTea or Mac VM at this time. As mentioned, returning the update release info for non-Sun JREs is not part of the goal for this plug-in. MSVM returns 1.0 due to the way it was delivered.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> You won't be able to detect which update without DT
> Plug-In. Therefore, it is not possible to return
> 1.6.0* for other update releases w/out DT Plug-In. If
> there's a DT Plug-In, you will be able to tell the
> update release info. I think case #1 is really
> minimal. I really don't see any major benefit in this
> change. If you prefer, you can submit an RFE to
> http://bugreport.sun.com, I will open a bug report
> for it.

Sorry, I don't understand what you mean. I'm saying that if the DT plug-in is not available and all you're able to detect is the 1.6.0 family you should return the string 1.6.0* instead of 1.6.0 as you currently do. Certainly you can do this...?

> >What about other browsers such as Safari? Do you
> only support IE and Mozilla?
> >What operating systems does this work on? What is
> the earliest JRE version you
> >can detect?
> >When I say I'm looking for an extensive list I am
> expecting you to reply with
> >something like this...
> Please see here for support platforms:
> http://java.sun.com/javase/6/webnotes/install/system-c
> onfigurations.html (you can find it on
> http://java.sun.com/javase/downloads/index.jsp ).

This isn't obvious from the documentation. You should explicitly document that deployJava.js is only guaranteed to detect the supported platforms listed here: http://java.sun.com/javase/6/webnotes/install/system-configurations.html

I have already opened a RFE to this end a few weeks ago. I also don't understand Sun's reluctance to invest in detecting non-Sun JREs. I would understand if you did some research and found out that 95% of users use Sun JDK so there is no point detecting the remaining 5% but I don't think this kind of research has been done in the first place. There are plenty of open-source Java-detection scripts out there. You could copy their code into your script with minimal effort.

> The earliest version can be detected is 1.3.0

Thank you. Please document this explicitly as well. Ideally all of these details should show up in the comments at top of deployJava.js or at least have the top link to a secondary site that lists this information.

> DT PlugIn is currently only available on Windows.
> Therefore, no need to detect IcedTea or Mac VM at
> this time.

I don't understand this logic. Why do you need the DT plugin to detect IcedTea or Mac VM? There are plenty of existing scripts which can detect them without the plugin. We don't need update-level information. You should at least detect their version family.

> As mentioned, returning the update release
> info for non-Sun JREs is not part of the goal for
> this plug-in.

I totally agree it's not worth the resources at this time, but I am expecting you to at least return the family version.

> MSVM returns 1.0 due to the way it was delivered.

Please document this as well.

Thanks,
Gili

trembovetski
Offline
Joined: 2003-12-31
Points: 0

> Sorry, I don't understand what you mean. I'm saying that if the DT plug-in is not available and all you're able to detect is the 1.6.0 family you should return the string 1.6.0* instead of 1.6.0 as you currently do. Certainly you can do this...?

Could you explain the benefit of getting 1.6.0* instead of 1.6.0 in this case? What exactly will it allow you to do?

To me it looks like there's absolutely nothing useful in that information.

Dmitri

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> > Sorry, I don't understand what you mean. I'm saying
> that if the DT plug-in is not available and all
> you're able to detect is the 1.6.0 family you should
> return the string 1.6.0* instead of 1.6.0 as you
> currently do. Certainly you can do this...?
>
> Could you explain the benefit of getting 1.6.0*
> instead of 1.6.0 in this case? What exactly will it
> allow you to do?
>
> To me it looks like there's absolutely nothing useful
> in that information.

1) It would allow users to differentiate between 1.6.0 the family and 1.6.0 the specific version without jumping through hoops.

2) It would improve consistency with the rest of the API that treats an input of 1.6.0* as the family of 1.6.0 versus 1.6.0 as the specific version.

Gili

rogyeu
Offline
Joined: 2006-07-30
Points: 0

Java Deployment Toolkit Plug-In is different from the Java Plug-In. The DT plugin is part of the Java Deployment Toolkit. It installs with the Java platform (JRE). No extra download is required.

Starting in 6u10, DT plugin introduces new features to allow developers to detect end-users' Java environment (i.e. deployJava.getJREs(), deployJava.versionCheck() ), and deploy the necessary Java platform to end-user systems if not there already (ie. deployJava.installLatestJRE(), deployJava.installJRE(requestVersion)) .

In addition to detect and deploy Java platforms, DT also includes functions (writeApplet, runApplet ) to generate suitable tags for users' browsers and system to run Applets or JNLP apps.

However, as mentioned by Andy, these features are new in 6u10. deployJava.js will not be able to detect the update release version if user does not have 6u10 installed or previously installed because user does not have the DT plugin on their system.

For more info:
http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advic...
http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advic...

Message was edited by: rogyeu

demonduck
Offline
Joined: 2008-03-14
Points: 0

> Java Deployment Toolkit Plug-In is different from the
> Java Plug-In. The DT plugin is part of the Java
> Deployment Toolkit. It installs with the Java
> platform (JRE). No extra download is required.
>

Ok...

Question -- can I use:

deployJava.setInstallerType('kernel');
// include any required packages as shown below
deployJava.setAdditionalPackages('javax.swing, javax.xml');

Without using javascript to run my applet? Can I use a plain old applet
tag with deployJava.setInstallerType("XXX") to download a JRE?

And what types does setInstallerType take. There is still no documentation
for deployJava.js even after all our requests.

rogyeu
Offline
Joined: 2006-07-30
Points: 0

I've responded to your question here:
http://forums.java.net/jive/thread.jspa?threadID=53588

to keep this thread stick to the topic.

jstansel
Offline
Joined: 2007-04-26
Points: 0

I think he probably means the npdeploytk.dll that was installed with 6u10 (only on ms/windows of course)

http://browserspy.dk/plugins.php?detail=1 shows it for Firefox 3 but the page seems to fail on MSIE 6

jstansel
Offline
Joined: 2007-04-26
Points: 0

> 1.) without the deploy toolkit plugins installed, the
> javascript can only report the latest family version
> installed, so "1.6.0" really means 1.6.0_00 thru
> 1.6.0_07. Even 1.6.0_10 and later can report just
> "1.6.0" if plugins are not installed (such as on
> non-windows).

I believe that the javascript could do better, as Firefox 3 on Ubuntu 8.10 allows http://browserspy.dk/plugins.php?detail=1 to see that "application/x-java-applet;jpi-version=1.6.0_10" is available from "Filename: libnpjp2.so"

-james.

P.S. the default ubuntu packaging doesn't enable the plugin2 so I took some manual steps to get firefox configured to use it

mbien
Offline
Joined: 2007-04-29
Points: 0

8.) is this a bug?
;)

demonduck
Offline
Joined: 2008-03-14
Points: 0

What is a "deploy toolkit plugin"?

Is it something that the user has to download and install in order for deployJava.js to work?

mbien
Offline
Joined: 2007-04-29
Points: 0

i guess it is plugin2 (aka next gen plugin shipped with u10) which can be called directly from within deployJava.js thats why he refers to it as "deploy toolkit plugin".

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> i guess it is plugin2 (aka next gen plugin shipped
> with u10) which can be called directly from within
> deployJava.js thats why he refers to it as "deploy
> toolkit plugin".

I don't think the next-gen plugin is not the same as the deployment toolkit plugin. My understanding is that the deployment toolkit plugin is a separate FireFox/IE/Safari plugin installed by Java6 update 10 that allows deployJava.js to detect the specific JREs installed.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I see my post ended up on the Editor's daily blog :)

I think it's important to note that we don't have enough data to be certain of the above results.

I would like to see:

1) More data from other websites that have nothing to do with Java (to avoid a bias). You should probably avoid mentioning your website name for the same reason.

2) Large sample sizes (1000 visitors seems okay to me).

3) A formal list of detected configurations from the Deployment Toolkit team. For all we know a large portion of "Java: none" could have Java installed but isn't being detected properly.

Gili

andyherrick
Offline
Joined: 2005-04-17
Points: 0

A few clarifications:
1.) without the deploy toolkit plugins installed, the javascript can only report the latest family version installed, so "1.6.0" really means 1.6.0_00 thru 1.6.0_07. Even 1.6.0_10 and later can report just "1.6.0" if plugins are not installed (such as on non-windows).
2.) known bug - safari on mac - there is no useable code in the pure javascript to detect java version(s) on Mac, and code was modified to allow runApplet() and launch() on mac to work, as a result, mac reports all versions there, and this results in the "1.8.0" claim. This bug should be addressed shortly.
3.) When dt plugins are installed, getJREs() will contain a complete list of installed jres. Thats where you can see 1.6.0_06 and 1.6.0_02 etc. These machines also have 1.6.0_10, or did have, and had them uninstalled.

/Andy

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Hi Andy,

4) What will getJREs() return for Java 1.6 (no updates) if the plugin *is* installed?
5) What will getJREs() return if only non-Sun JDKs are installed (with and without the plugin)?
6) What is the extensive list of platforms (JRE vendors, operating systems, browsers, and versions) that deployJava.js is known to detect? Can we assume that all other platforms (such as Microsoft JVM) will not be returned by getJREs?
7) Is it possible for Sun to collect data from openoffice.org and report the results here?

Thank you,
Gili

Message was edited by: cowwoc

rogyeu
Offline
Joined: 2006-07-30
Points: 0

Let me try...

> 4) What will getJREs() return for Java 1.6 (no
> updates) if the plugin *is* installed?
1.6.0

> 5) What will getJREs() return if only non-Sun JDKs
> are installed (with and without the plugin)?
getJREs() returns an array. If no public JRE is installed, it should array length should be 0.

> 6) What is the extensive list of platforms (JRE
> vendors, operating systems, browsers, and versions)
> that deployJava.js is known to detect? Can we assume
> that all other platforms (such as Microsoft JVM) will
> not be returned by getJREs?
MSVM returns 1.0.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> > 4) What will getJREs() return for Java 1.6 (no
> > updates) if the plugin *is* installed?
> 1.6.0

That is problematic. This means that there is no way to differentiate between 1.6.0 the family and 1.6.0_00 the specific version. Is it possible to modify the Deployment Toolkit to return 1.6.0_00 instead? The same would obviously go for older version numbers as well.

> > 5) What will getJREs() return if only non-Sun JDKs
> > are installed (with and without the plugin)?
> getJREs() returns an array. If no public JRE is
> installed, it should array length should be 0.

Are you saying that the deployment toolkit only detects Sun JDKs? What about IBM, Apple, Excelsior JET, open-source Linux JREs, etc?

> > 6) What is the extensive list of platforms (JRE
> > vendors, operating systems, browsers, and
> versions)
> > that deployJava.js is known to detect? Can we
> assume
> > that all other platforms (such as Microsoft JVM)
> will
> > not be returned by getJREs?
> MSVM returns 1.0.

Thank you :) We still need an extensive list of all the platforms that the deployment toolkit is known to detect.

Gili

rogyeu
Offline
Joined: 2006-07-30
Points: 0

The version string "1.6.0_00" doesn't exist in the current product. "java -version" returns "1.6.0" for Java 6. IMHO, introducing an additional version string will cause confusion and even bigger confusion if this only applies to DT or deployJava.js.

Allow me to back up a bit:
With DT plug-in, for Java 6 and 6u1, you will get 1.6.0 and 1.6.0_01 respectively.
Without DT plug-in, from 6 to 6u7, you will get 1.6.0 in any cases. However, this is expected.

With that said, the actual confusion rises only in the 2 following cases:
- DT Plug-In installed + Java 6.
- No DT Plug-In installed + any Java 6 platform (6 to 6u7).
but I doubt case #1 is significant when is compared to case #2. However, you may still be able to distinguish the difference with this:
if (jre[i] == '1.6.0') {
if (deployJava.isPluginInstalled()) {
//case #1
} else {
//case #2
}
}
where jres = deployJava.getJREs().

>Thank you :) We still need an extensive list of all the platforms that the
>deployment toolkit is known to detect.
The JavaScript part of DT determines JRE based on the based on browser. On IE, it returns what version of the java web start activeX objects are present, on Mozilla family, it depends on what mime type values are registered.

For the DT Plugin, our goal is to return a list of Sun's JREs that are installed. However, if a third party java installs setting certain registry keys, it will be detected too.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> The version string "1.6.0_00" doesn't exist in the
> current product. "java -version" returns "1.6.0" for
> Java 6. IMHO, introducing an additional version
> string will cause confusion and even bigger confusion
> if this only applies to DT or deployJava.js.

Okay, how about reusing an existing syntax to avoid any confusion? DT could return 1.6.0 to denote the specific version and 1.6.0* to denote the family. The script already uses the star syntax to denote a family.

> to case #2. However, you may still be able to
> distinguish the difference with this:
> if (jre[i] == '1.6.0') {
> if (deployJava.isPluginInstalled()) {
> //case #1
> } else {
> //case #2
> }

Fair enough, but this requires more work than it should. Please consider the star syntax mentioned above.

> >Thank you :) We still need an extensive list of all
> the platforms that the
> >deployment toolkit is known to detect.
> The JavaScript part of DT determines JRE based on the
> based on browser. On IE, it returns what version of
> the java web start activeX objects are present, on
> Mozilla family, it depends on what mime type values
> are registered.

What about other browsers such as Safari? Do you only support IE and Mozilla? What operating systems does this work on? What is the earliest JRE version you can detect?

When I say I'm looking for an extensive list I am expecting you to reply with something like this...

- We support Mozilla, IE on the platforms listed below
- We support JRE 1.4.2 update 5 and newer
- We support Windows, [list of Linux distributions], and MacOS X
- We support the following JRE vendors: Sun, Apple, IBM

> For the DT Plugin, our goal is to return a list of
> Sun's JREs that are installed. However, if a third
> party java installs setting certain registry keys, it
> will be detected too.

I'm not sure I understand. What registry settings? What non-Sun vendor does this today? I assume none... Does this mean that the DT only detects Sun JREs? Does Sun plan on actively encouraging other vendors to port the DT plugin to their platforms?

Thanks,
Gili

trembovetski
Offline
Joined: 2003-12-31
Points: 0

> 'm not sure I understand. What registry settings? What non-Sun vendor does this today? I assume none... Does this mean that the DT only detects Sun JREs? Does Sun plan on actively encouraging other vendors to port the DT plugin to their platforms?

Gili, honestly, do you really expect a significant percentage of non-sun vendor client jres out there in the wild?

Dmitri

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> Gili, honestly, do you really expect a significant
> percentage of non-sun vendor client jres out there in
> the wild?

That's a good point, though I would feel better if we had *some* sort of measurement to prove this. I simply don't know.

It also depends strongly on your target market. If your target market happens to be Linux or Mac OS X then you might very well be interested in non-Sun JDKs and they might make up the majority of your customers.

There seem to be plenty of unofficial JRE detection scripts out there. Perhaps we could find the best one and fold it in with minimal work. I just want to be able to say with confidence that the figures being collected (~70% JRE deployment) aren't leaving out a sizable user base.

There seems to be a pretty high discrepency between the figures being reported by Google Analytics -> Browser Capabilities -> Java Support (~90%) and the 70% we're seeing. We need to figure out where that's coming from.

PS: I've discovered that the script has a bug whereby it only reports the latest JRE version, as opposed to all installed JREs. When I say "latest" I mean the last element returned by getJREs(). This brings up a question: is getJREs() guaranteed to be sorted according to increasing version numbers? If not, is there an easy way to sort it?

Thanks,
Gili

mbien
Offline
Joined: 2007-04-29
Points: 0

> Google Analytics -> Browser Capabilities -> Java Support (~90%)

this only reports if "java" has not been disabled by the user in the browser settings (checkbox next to disable javascript) but does not indicate if there is an jre installed or not.

In other words it may report "java supported" without an jre installed.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> > Google Analytics -> Browser Capabilities -> Java
> Support (~90%)
>
> this only reports if "java" has not been disabled by
> the user in the browser settings (checkbox next to
> disable javascript) but does not indicate if there is
> an jre installed or not.
>
> In other words it may report "java supported" without
> an jre installed.

This may be the case, but how do you know? Certainly when I read http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer... it talks about the user's "platform" supporting Java, not the browser. Furthermore I'm not sure that non-Mozilla browsers even have such a dedicated "allow Java" checkbox so what are they checking then?

It would be nice to get a more technical answer from Google (posting on their help forums is worse than useless). Perhaps looking at their actual Javascript will yield answers?

Gili

mbien
Offline
Joined: 2007-04-29
Points: 0

> It would be nice to get a more technical answer from
> Google (posting on their help forums is worse than
> useless).
>Perhaps looking at their actual Javascript
> will yield answers?
its obfuscated, it isn't really fun to reverse engineer it.
http://www.google-analytics.com/ga.js

I have attached a formated version of the file above, open it with NetBeans or similar for syntax highlighting.

In essence it uses .javaEnabled(http://www.w3schools.com/HTMLDOM/met_nav_javaenabled.asp) to check if the browser permits java or not.

[edit] here a better formatted version from someone else: http://xamde.blogspot.com/2008/07/towards-gajs-un-obfuscated.html

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> Java: none
>
> Is that accurate or is that an artifact of the way
> the data was collected?

It should be accurate. The script only sets this value if getJREs() returns an empty list.

> And is the Java: 1.6.0 just detecting the specific
> release or the generation?

I am guessing this refers to a family and that the real Java6 would show up as 1.6.0_00 though to be honest I haven't ever seen _00 being reported. The behavior doesn't seem to be documented. If someone has a copy of the original JDK 1.6 release we could test it to be sure.

mbien
Offline
Joined: 2007-04-29
Points: 0

AFAIK it is only possible to report update releases when the next gen plugin is installed && enabled.
that means x.x.x_update means update 10 is one of the available JREs and plugin2 is enabled otherwise you would only get the family version.
for details read the first function of:
http://java.com/js/deployJava.js

[edit]I think I found a bug, see other thread

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Here is my interpretation of the results:

A total of 1002 visits (excluding "not set")

Java: 1.6.0 (52%)
Java: none (29.94%)
Java: 1.5.0 (7.94%)
Java: 1.6.0_10 (3.79%)
Java: 1.4.2 (3.29%)
Java: 1.5.0_06 (0.8%)
Java: 1.6.0_07 (0.7%)
Java: 1.6.0_02 (0.3%)
Java: 1.4.2_03 (0.2%)
Java: 1.6.0_03 (0.2%)
Java: 1.8.0 (0.2%)
Java: 1.4.1_02 (0.1%)
Java: 1.4.2_05 (0.1%)
Java: 1.4.2_06 (0.1%)
Java: 1.4.2_18 (0.1%)
Java: 1.5.0_05 (0.1%)
Java: 1.5.0_09 (0.1%)
Java: 1.5.0_15 (0.1%)
Java: 1.6.0_05 (0.1%)
Java: 1.6.0_06 (0.1%)

In summary:

1.6.0_00 to 1.6.0_09: 530 (52.89%)
none: 300 (29.94%)
1.5.0: 93 (9.28%)
1.6.0_10: 38 (3.79%)
1.4.2: 39 (3.89%)
1.8.0: 2 (0.2%)

1.4.2+: 700 (69.86%)
1.5+: 661 (65.97%)
1.6+: 568 (56.67%)

So it seems fair to say that ~70% of web users have Java installed, but for those of us interested in Applets or Desktop Applications I guess we are only interested in the top 56% or even 4%...

Is that good enough? I guess it depends on whether you see the glass half-full of or half-empty. I am actually quite surprised that 56% of web users have Java 1.6 installed. That's actually much better than I expected!

I believe that Applets require Java6 update 10 (in other words, they won't be ready for prime time until update 10 sees better adoption) but Desktop Java should run very well on basic Java6 so 56% is pretty damn good.

Gili

mthornton
Offline
Joined: 2003-06-10
Points: 0

I think 1.6.0 is the preinstalled version on Dell and presumably other systems. It is a pity so few of them have been updated.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> I think 1.6.0 is the preinstalled version on Dell and
> presumably other systems. It is a pity so few of them
> have been updated.

It's not clear that they haven't been updated. Remember, 1.6.0 could designate a family name as opposed to a specific update version. We'll find out shortly when someone from the deployment team comments on this (I've been told someone from their team with join the discussion soon).

mbien
Offline
Joined: 2007-04-29
Points: 0

i am tracking https://netbeans-opengl-pack.dev.java.net/ and here are my results:

[code]
5 days 379 visits
Java: 1.6.0 48.81%
Java: none 15.04%
Java: 1.6.0_10 11.35% (->plugin2 installed and enabled)
Java: 1.5.0 7.92%
Java: 1.8.0 4.22% (???)
(not set) 3.96% (script was not able to send results back)
...
[/code]

details to "Java: none":
50% windows 50% linux
Mainstream browsers like firefox, opera, chrome

that means around 85% of all visitors had a JRE installed.
I would have expected better results on a java.net page. But the timespan was also to short for representative results.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> Java: 1.8.0 4.22% (???)

I also saw this value. It can from a MacIntosh Safari user. If you create a Custom Report as my blog recommends you can drill-down to get this sort of information.

> (not set) 3.96% (script was not able to send results back)

This figure represents any hits before you started using deployJava.js ... Try limiting the date interval in Google Analytics to when you actually installed the script and you will notice it will drop to zero.

> I would have expected better results on a java.net
> page. But the timespan was also to short for
> representative results.

Agreed, java.net is probably not a good site to measure Java penetration :) It's more useful for measuring Java versions being used by Java developers.

mbien
Offline
Joined: 2007-04-29
Points: 0

> > Java: 1.8.0 4.22% (???)
> I also saw this value. It can from a MacIntosh Safari
> user. If you create a Custom Report as my blog
> recommends you can drill-down to get this sort of
> information.
yes exactly here too. A bug in the script or is this a real version?

>
> > (not set) 3.96% (script was not able to send
> results back)
>
> This figure represents any hits before you started
> using deployJava.js ... Try limiting the date
> interval in Google Analytics to when you actually
> installed the script and you will notice it will drop
> to zero.
I know, my analytics tracker is on the bottom of the page this happens in my case if the user e.g presses the download link or navigates away before the whole page is loaded.

> Agreed, java.net is probably not a good site to
> measure Java penetration :) It's more useful for
> measuring Java versions being used by Java developers.
this is actually the reason why i tracked this page, I expected >90% penetration. I am also a little bit surprised that u10 isn't widely used yet (the most tracked versions are 1.6.0 this means AFAIK no plugin2 since it reports only the family version).

agoubard
Offline
Joined: 2003-10-04
Points: 0

Hi,

I've also recently been tracking Java versions using another method.

The method used was by looking at the User Agents collected by Webalizer on one of my website.
Because at the moment the website only contains Jar files accessed by Applet it was easy to get.
Here are more details:

  • The Applet used is http://dictionary.japplis.com
  • 65 % of the visitors are Dutch or Belgium accessing it via http://woordenboek.japplis.com
  • The deployment toolkit is used to start the Applets with minimal version being 1.3
  • People not having Java installed or with Java disabled are not part of the statistics
  • These are statistics collected over the last 4 days of November 2008
  • The statistics tool gives me only the top 15, representing 77.25 % of hits.

And now the statistics:

# Hits User Agent

1 1687 25.12% Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_07
2 707 10.53% Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_07
3 525 7.82% Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_10
4 384 5.72% Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_05
5 339 5.05% Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_03
6 261 3.89% Mozilla/4.0 (Mac OS X 10.5.5) Java/1.5.0_16
7 239 3.56% Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_06
8 203 3.02% Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_10
9 178 2.65% Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0-oem
10 157 2.34% Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_02
11 130 1.94% Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_05
12 110 1.64% Mozilla/4.0 (Mac OS X 10.4.11) Java/1.5.0_16
13 105 1.56% Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_06
14 84 1.25% Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_03
15 78 1.16% Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_01

Conclusion:

  • Most of Mac OS X users still use Java 5
  • Most of Windows users use Java 6
  • 10.8 % of installed Java are Java 6 update 10
swpalmer
Offline
Joined: 2003-06-10
Points: 0

On Mac OS X the version is probably skewed towards Java 5 because Java 6 on OS X is 64-bit only and Safari is a 32-bit app and currently only runs Java 5 for applets. (That will change when the new applet plugin is released on OS X.)

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I just posted an improved script for detecting Java versions. Please take a look and report your new data: http://cowwoc.blogspot.com/2008/12/tracking-java-versions-using-google.html

Thank you,
Gili

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I screwed up. [b]Anyone who's already installed the script, please update the path to the new value mentioned in the blog[/b]. Google Code won't let me edit the original file. Also, please note that the new version I just posted will allow you to differentiate between 1.6.0* the family versus 1.6.0 the version.

For what it's worth, here are my site's statistics, collected before I could differentiate between families and specific versions. The website caters to non-technical users but the same size is very small (100 unique users).

Java Detected?
----------------------

71.43% yes
28.57% no

Java Version
------------------

50.65% 1.6.0
24.68% 1.6.0_10
10.39% 1.5.0
2.60% 1.6.0_04
2.60% 1.6.0_05
2.60% 1.6.0_06
2.60% 1.6.0_07
1.30% 1.5.0_06
1.30% 1.5.0_11
1.30% 1.6.0_03

If you guys plan on releasing statistics please include results from December 4th onward so we can differentiate between the family versions.

Thanks,
Gili

Message was edited by: cowwoc

I mistakenly posted per-visit statistics instead of per-user statistics. When posting your data please make sure "Label contribution to total" reads "Unique Events" not "Total Events" which is the default.

tdanecito
Offline
Joined: 2005-10-10
Points: 0

I amy be wrong but for me I can see in my Apache web logs the java version. It may be because I uses JAXWS and it is recorded by the protocol even though the requests get forward to Tomcat.

Regards,
Tony

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> I amy be wrong but for me I can see in my Apache web
> logs the java version. It may be because I uses JAXWS
> and it is recorded by the protocol even though the
> requests get forward to Tomcat.

That's not going to work for everybody because:

1) Not everyone uses JAXWS
2) Most of the time when you see the Java version in your Tomcat logs it is because by default Java sets "user-agent" to a String containing the version number. Nothing prevents users from changing the contents of this string.

forcers
Offline
Joined: 2008-01-18
Points: 0

Here are results for 1,033 visits of a site that hits a wide spectrum of users (a freeware utility I wrote to do a print screen).

[code]
User Defined Value Visits Pages/Visit Avg. Time on Site % New Visits Bounce Rate
1. Java: 1.6.0 516 2.45 00:00:58 95.16% 1.55%
2. Java: none 300 2.41 00:00:58 93.33% 1.67%
3. Java: 1.5.0 82 2.27 00:00:34 89.02% 2.44%
4. Java: 1.6.0_10 38 2.66 00:01:08 92.11% 0.00%
5. Java: 1.4.2 33 2.33 00:00:56 93.94% 0.00%
6. (not set) 31 1.48 00:00:20 100.00% 67.74%
7. Java: 1.5.0_06 8 3.62 00:02:14 100.00% 0.00%
8. Java: 1.6.0_07 7 2.57 00:00:36 100.00% 0.00%
9. Java: 1.6.0_02 3 2.67 00:00:48 100.00% 0.00%
10. Java: 1.4.2_03 2 3.00 00:00:32 100.00% 0.00%
11. Java: 1.6.0_03 2 1.50 00:00:10 100.00% 0.00%
12. Java: 1.8.0 2 3.00 00:00:20 100.00% 0.00%
13. Java: 1.4.1_02 1 3.00 00:00:55 100.00% 0.00%
14. Java: 1.4.2_05 1 1.00 00:00:01 100.00% 0.00%
15. Java: 1.4.2_06 1 1.00 00:00:01 100.00% 0.00%
16. Java: 1.4.2_18 1 19.00 00:06:11 100.00% 0.00%
17. Java: 1.5.0_05 1 3.00 00:01:34 100.00% 0.00%
18. Java: 1.5.0_09 1 4.00 00:00:09 100.00% 0.00%
19. Java: 1.5.0_15 1 1.00 00:00:01 100.00% 0.00%
20. Java: 1.6.0_05 1 3.00 00:00:58 100.00% 0.00%
21. Java: 1.6.0_06 1 2.00 00:00:07 100.00% 0.00%
[/code]

demonduck
Offline
Joined: 2008-03-14
Points: 0

Java: none --

Is that accurate or is that an artifact of the way the data was collected?

And is the Java: 1.6.0 just detecting the specific release or the generation?

forcers
Offline
Joined: 2008-01-18
Points: 0

Good questions for cowwoc.

I used the script as-is.

By the way, the freeware on my site is non-java (windows based).

jsight
Offline
Joined: 2005-06-30
Points: 0

This needs to go with the _GIANT_ caveat that it uses deployJava.js which tends to be extremely unreliable outside of some very specific deployment scenarios.

This one would work much better (though still would report artificially low #s due to various browser limitations):
http://www.pinlady.net/PluginDetect/JavaDetect.htm

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> This needs to go with the _GIANT_ caveat that it uses
> deployJava.js which tends to be extremely unreliable
> outside of some very specific deployment scenarios.

What are you basing this on?

Gili

jsight
Offline
Joined: 2005-06-30
Points: 0

Experience, and posts in here. Have you ever seen a list of supported browser/java version combinations for deployJava.js?

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> Experience, and posts in here. Have you ever seen a
> list of supported browser/java version combinations
> for deployJava.js?

I believe deployJava.js will detect Java versions at least all the way back to Java 1.4.2, and I suspect even earlier. The only thing that is not clear is whether it will work for non-Sun JDKs back to those versions but we can ask Sun for clarification on this point (in fact, I just filed a BugParade issue asking for explicit documentation). Here are my references:

http://developers.sun.com/events/techdays/presentations/2007/TD_BOS_Cons...
\-> Page 19: "Script will use the plugins if available[...]Pure javascript can only detect at the family granularity"

http://docs.huihoo.com/javaone/2006/java_se/JAVA%20SE/TS-1319.pdf
\-> Page 7: "Family detection—5.0 family or 1.4.2 family"

http://forums.java.net/jive/thread.jspa?threadID=33852&tstart=-1

demonduck
Offline
Joined: 2008-03-14
Points: 0

For the last hour, I've been trying to understand the current best way to deploy
applets using CLSID; OBJECT tags; deployJava.js.

Wow -- what a mess.

One page says not to use OBJECT tags -- another page says to use OBJECT tags.

One page says deployJava.js make everything easy to deploy applets but if you read
the code it's mostly for JNLP and webstart.

The CLSID is all over the place. There's a dynamic one that uses the most recent
version of a particular family -- if it's installed -- I think. Then there's a CLSID that
only works for MSJVM. Then there's mysterious CLSID's that mean something
but what that is I don't know.

And this is great:

/*
* deployJava.js
*
* This file is part of the Deployment Toolkit. It provides functions for web
* pages to detect the presence of a JRE, install the latest JRE, and easily run
* applets or Web Start programs. Usage guide may be found at http:///.
*
* The "live" copy of this file may be found at
* http://java.com/js/deployJava.js.
* You are encouraged to link directly to the live copy of the file.
*
* @version @(#)deployJava.js 1.13 08/10/28
*/

TBD -- well isn't that precious ----

Come on people -- get it together. We're dying out here....