In the original Windows application there is one critical portion of the UI that I always found rather clumsy and awkward to use. Years ago - as time permitted and as a precondition to starting the project - I’d put together a small prototype Java applet to present this one aspect and test out my notions for a better presentation. I was satisfied with the resulting UI gadget. Where the original application was obscure - with the small Java applet this same facet of the user interface became simple, intuitive, and more efficient to use.
Now - the support for Java applets in web browsers is somewhat half-hearted. Web developers have largely moved away from use of Java applets. Microsoft is - at best - a bit grumpy about supporting Java. So I knew this part was a bit of a risk.
Years ago the Sun/Java folks did “The Right Thing” and came up with the Java Plugin. With the right incantation in your HTML page you could insure the proper version of Java was installed in the user’s web browser. Since by now the Java Plugin has been around for years - I pretty much assumed any of the kinks should have been worked out long ago.
What’s more there is even a standard built-in JSP tag to properly invoke the Java Plugin. Given the simple to use jsp:plugin tag to generate the proper incantation - how could I go wrong?
… rather badly wrong, as it turns out …
The first sign of trouble came when the guy doing testing reported that the applet did not run on machine that did not have a JRE already installed. What’s more it seemed that the Java Plugin was attempting to download the wrong version of Java! Ouch. The original jsp:plugin invocation follows - which works properly when the JRE is already installed.
<jsp:plugin name = "TemplateEditorGadget" type = "applet" jreversion = "1.4" code = "com.asg.reportweb.modeler.applets.swing.TemplateEditorGadget" archive = "applets/TemplateEditorGadget.jar" width = "100%" height = "300" > <jsp:params> <jsp:param name="mayscript" value="Y" /> </jsp:params> <jsp:fallback> <div class="notice">Java plugins not supported by your browser.</div> </jsp:fallback> </jsp:plugin>
On checking the generated HTML, it appears that whomever wrote the jsp:plugin code followed the Sun recommendation for use of the Java Plug-in in IE and Navigator. Now - if you’ve been playing attention - this part should strike you as a little odd. Note that the JSP page is dynamically generating HTML, and can detect the sort of web browser on the remote end of the connection. There is seldom if ever a need to generate HTML for a web browser other than the one receiving the page.
Along the way spotted a discouraging sign in the documented list of Autodownload Files offered by Sun. What you have here is effectively a (web) API that Sun has not made an effort to keep consistent. Based on past changes, you cannot predict the URLs valid for future JRE versions - not good!
Since the generated HTML from jsp:plugin was not producing the desired effect, and what should work was less than entirely clear, this seems like a good time to try out Sun’s HTML Converter. Cooked up a basic APPLET invocation and ran it through HTML Convertor - which generated a result that didn’t work for some reason. Severely confused at this point, I put together a series of test cases to empirically determine what works and what does not.
Note that at this point it is a great advantage to have a machine with VMware installed. To test you need a machine that does not have Java installed - and preferably has never had Java installed. With VMware cloning a new VM takes seconds, and gets you an absolutely clean copy of a reference installation of whatever operating system version you want to test.
… still trying to sort this out …