views:

115

answers:

4

We have an ages old Java applet that we want to move forward to a newer version of Java (5 or 6), however until today we've always supported people using Java VMs as far back as version 1.1 (specifically for those still using the Microsoft VM)

As part of the upgrade, we'd like to be able to serve a web page to people using out-of-date VMs telling them which versions we now support and where they can download them from. Ideally we want to do this without having to serve a Java 1.1 applet first just to determine the JVM version.

Answers to either of the following (with code samples if possible) would be appreciated:

Question 1: is it possible to determine the JVM in a script on the server using information from the HTTP headers?

Question 2: is it possible to determine the information on the client using just JavaScript?

+1  A: 

Q1: no

Q2: yes, but I don't know how portable that is:

<html><head><title>Test</title>
</head><body>
<script type="text/javascript">
document.writeln('<table border="1">');
for (var i = 0; i < navigator.plugins.length; i++) {
  document.writeln("<tr>");
  document.writeln("<td>" + navigator.plugins[i].name + "<\/td>");
  document.writeln("<td>" + navigator.plugins[i].description + "<\/td>");
  document.writeln("<td>" + navigator.plugins[i].filename + "<\/td>");
  document.writeln("<\/tr>");
}
document.writeln("<\/table>");
</script>
</body></html>

That outputs a table of all plugins, versions should be contained. I think you have to loop over all the plugins, check if 'java' is contained in the name and then parse the version from description...

Johannes Weiß
Up-voted for the short, but sweet, answer to Q1 - that's what I thought.Unfortunately, Q2 doesn't appear to port as far as IE6 - mine's getting navigator.plugins.length as 0 :-(
raimesh
A german website says it is supported in JavaScript 1.1, Netscape 3.0, Opera 5.12, Firefox 1.0, Konqueror 3.1, Safari 1 and higher and (exactly) IE for Mac 5.0 :-(.Perhaps any of all these JS libs has something for that...
Johannes Weiß
+1  A: 

There is a deployment toolkit for doing this sort of thing.

Serving an applet shouldn't be too bad. It can either be a 1x1 pixel bug, or use your normal applet with a small 1.1 class that forwards the applet lifecycle methods if it can load your 1.5 code.

Nobody should still be using 1.1. It hasn't had security bugs fixed in it for years.

Tom Hawtin - tackline
We actually already serve an applet to determine the VM as we have two versions, one of which works around bugs in MS JVM (but doesn't work on Sun) and one of which is the other way round. The powers that be think this approach is too clunky going forward, so I'm tasked with looking for another way.
raimesh
Oh, and just because nobody *should* be using 1.1, this does not mean none of our customers *are* using 1.1, unfortunately :-(
raimesh
A: 

This script seems to do the trick on all major browsers:

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

mercator
Seems quite complex considering it might run an applet anyway for its "NOTF" approach; we might as well just go straight to that option. Plus I'm not sure I want to run code written by someone who uses the idiom "Java142Installed = Java142Status == 1 ? true : false"
raimesh
Well, I have to admit I didn't go beyond testing it actually worked.
mercator
+1  A: 

I think the deployment toolkit might do what you want.

Use the runApplet() function in deployJava to ensure that a minimum Java Runtime Environment is available on a client machine before launching the applet.

Jason Day
Looks like the deployment toolkit is the "proper" way forward, so I've accepted this answer as it included a link to the appropriate page (sorry, tackline - I know you suggested the toolkit first, but them's the breaks).Meanwhile, we'll be using our tried-and-tested launch an applet approach!
raimesh