I received the following message off-list regarding JVM detection and the Sun Java Plugin.
My response contains technical information that is worth documenting publically. Miguel ---- > I have confirmed what I feared, that a brand new "clean" > Windows XP Pro SP2 system, with all critical updates up to > date, sometimes has NO java. Should not be a surprise ... clean Windows installs from Microsoft never have Java ... not for the past few years. HP, IBM, and Dell all pre-install Java, but that is like an application that they install ... it is separate from Windows. My guess is that there are few people who do not have it preinstalled by their hardware vendor. The people who would *not* have it installed are: - anyone who builds a machine from scratch and buys a shrink-wrap retail version of Windows - some/many people who buy from a local 'white box' computer store that assembles machines from scratch. Same as previous item, but many of these stores will install Acrobat and Java in advance. - anyone who wants to upgrade to Windows XP and who reformats their hard drive before the install in order to do a clean install of XP - anyone who does a 'system restore' (on a Dell or HP) and who chooses not to restore the 'applications' > (The > one I tested was installed as SP1 and updated to SP2.) When > a Jmol web page is visited in MSIE, a little square with an X > inside appears in the upper left corner of the applet > rectangle, and no > help is offered. It just sits there not showing the molecule. I am somewhat surprised that this is happening. I did work on this ... Never mind ... that only applies to Jmol.js In Jmol.js I put in code to test for this case. If IE is running and no Java is found then an alternate display is put up in the area where the applet would have appeared, directing the users to www.java.com You may want to look at the Jmol.js code and do something similar. > Our new sitemeter shows that the majority of (our small sample of 100+) > our visitors use Windows XP, and MSIE. No surprise that the majority of web users are IE on XP. But, given that most hardware vendors preinstall Java, the majority of these people are successfully running with the Java plugin. There is a way to actually count how many people do not have the Java plugin installed by using the web log files. 1. Find IP addresses that access a Jmol page. 2. Subtract out those IP addresses that download JmolApplet0.jar within (say) 15-30 seconds. The difference between these two is the IP addresses that downloaded the page, but did not download the applet ... they did not download the applet because plugin/JVM wasn't there to request the applet. > Presently, if the user clicks "Can't see the molecule?" and reads > carefully, s/he may try java.com and solve the problem. But wouldn't it be > nice if we could somehow automatically tell the user they need java? I did a lot of work on this as part of Jmol.js ... to make life easier for people by dealing with this complexity in a centralized place. The browser testing needs to happen within the context of the web page scripting. It tests for IE and then uses VBscript to determine whether or not the JVM is available. ** 2 minutes later ** Not true ... I just took another look. I started down that path, but then decided that it wasn't worth it. I want to push people off of the MSFT JVM. MSFT has not wanted people running it for at least 5 years. I feel like I have one hand tied behind my back because of MSFT JVM support. Therefore, I abandoned the VBscript approach and decided to force use of the Sun Java Plugin. Jmol.js forces use of the Sun Java Plugin through the ActiveX mechanism that is supported by Microsoft. > Contained in jmol.js are the following lines that I don't understand: > > windowsClassId: "clsid:8AD9C840-044E-11D1-B3E9-00805F499D93", > windowsCabUrl: > "http://java.sun.com/update/1.5.0/jinstall-1_5_0_05-windows-i586.cab"; Ohh ... good ... looks like you already discovered that :-) > I am wondering if these are related to getting > or updating java on Windows, Yes. It forces use of Java Plugin 1.4 or greater. If the Java Plugin is not found, then IE goes to that URL and prompts the user for an automatic installation. > and if so, how they could be implemented (short of recoding > everything to use jmol.js). (Watch your Capitalization ... it is Jmol.js ... and Windows & Mac users tend to have problems with Case Sensitivity when they move to Unix web servers.) As always, I encourage people to use Jmol.js. The function _jmolApplet says "if the browser is IE6 then output an IE <object> tag using MSFT conventions that is XHTML-compliant. > I could probably figure out how to do this with enough > analysis of jmol.js and testing, but I would GREATLY appreciate a > jump-start from you with as much detail as you are able to provide, e.g. a > block of proposed code. The format of a MSFT object tag is: <object name='your-name-and-id' id='your-name-and-id' classid='clsid:8AD9C840-044E-11D1-B3E9-00805F499D93' codebase='http://java.sun.com/update/1.5.0/jinstall-1_5_0_07-windows-i586.cab' <param name='code' value='JmolApplet' /> <param name='archive' value='JmolApplet0.jar' /> <param name='mayscript' value='true' /> <param name='codebase' value='path-to-dir-with-JmolApplet*.jar' /> // now come your Jmol parameters <param name='script' value='your-script-goes-here' /> // now, close it out </object> > I would also love to know what is known about the behavior of various > Windows systems, in various states (no java, or old java) when they run > this code -- or who to ask. Probably nobody to ask other than me. The details about the ActiveX mechanism is documented as part of Microsoft's SDK (software development kit) documentation. Specifics as to how to apply this to the Sun Java Plugin is part of the Sun Plug-in deployment guide in the SDK. The documentation is freely available, but it is not consolidated in one space and it makes a lot of assumptions about the problem space. This code forces use of the Sun Java plugin using the ActiveX mechanisms built into IE ... the references to .cab (cabinet) files. ActiveX controls are identified by numeric globally unique class IDs ... in this case "clsid:8AD9C840-044E-11D1-B3E9-00805F499D93". This class ID is associated with any version of the Java Plugin that is 1.4 or greater. (There are other class IDs that one can use if one wants to force usage of a specific version of Java.) The effect is this: If you any version of Java Plugin 1.4 or greater installed then things run just fine. Java 1.4 was released in 2001. Otherwise, put up a dialog box which asks the user whether or not they want to automatically download the latest Java 1.5 version from java.sun.com. This dialog box is Microsoft's standard ActiveX control mechanism. Restated ... make sure that the user is running Sun Java 1.4 or greater. If they don't, then they are prompted for an automatic install. The old Microsoft JVM is not used, even if it is present. I plan to drop support for the MSFT JVM at the end of 2006. The purpose of this mechanism was to start forcing 'Jmol.js' users to use the Sun Java Plug-in. I put this mechanism in place about 6 months ago. I have received one complaint from someone who did not like this behavior ... he wanted to keep using the MSFT JVM. > I don't mind doing some testing but starting > from nothing would take many days (esp. if I need to test Win98SE, > Win2000, WinME, WinXP SP1, WinXP SP2, As part of Jmol.js development I tested this on IE running on Win98SE, WinME, Win2K, and WinXP. It uses the ActiveX control mechanism which is documented/supported/encouraged by Microsoft. It works fine. Your choice as to whether or not you feel the need to retest. (Note that MSFT does not support this mechanism on IE Mac ... so it is not used there) I have tested various versions of IE and have never experienced any problems. > and various browsers on each one, etc.). Note that this *only* applies to IE ... so there really is no such thing as 'various browsers'. Note that for other browsers Jmol.js uses other mechanisms to deal with the 'no-java-plugin' problem ... but they are completely different mechanisms. > I have kept my WinXP SP2 virtual machine java-less for testing. Is there a > way to uninstall java cleanly? I would not trust the uninstall of the Sun Java Plugin to be completely clean. With that said, I am sure that it is better than the uninstall of the MSFT JVM. Try it ... it might work. > Of course, I can keep a java-less copy of > the VM at 5 gigs a pop. That is certainly the safest solution. Miguel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
