Depth-First: Tag java

ChemWriter 1.3.1

Rich Apodaca — Mon, 30 Jun 2008 14:54:00 -0400

ChemWriter 1.3.1 can now be downloaded. This version resolves an EditorApplet issue in which molfiles containing two or more atoms with exactly the same 2D coordinates were not displayed properly.

Details are available on the Metamolecular Company Blog.

ChemWriter is the 2D chemical structure editor designed for Web applications. Lightweight and intuitive, ChemWriter makes an excellent choice for both creating and displaying 2D chemical structures on the Web.

3D Molecular Visualization on the Web: OpenAstexViewer

Rich Apodaca — Thu, 19 Jun 2008 09:04:00 -0400

OpenAstexViewer is an LGPL-licensed 3D molecular visualization tool written in Java. With the obfuscated jarfile weighing in at 1 MB, OpenAstexViewer could make a good choice for use in Web applications.

There are now at least two open source, feature-rich 3D molecular visualization tools written in Java (the other being Jmol). Are there any others?

Credit: thanks to Noel O'Boyle for spotting this.

Screencast: Drawing Structures Quickly With ChemWriter

Rich Apodaca — Wed, 18 Jun 2008 13:55:00 -0400

This short video shows how to use ChemWriter to draw structures quickly with keyboard shortcuts.

Better Structure Drawing With ChemWriter 1.3.0

Rich Apodaca — Mon, 16 Jun 2008 16:18:00 -0400

ChemWriter 1.3.0 has been released and is ready for download. This version makes it possible to change the mouse cursor hover radius for more accurate drawing. It also adds a setting to disable heteroatom keyboard shortcut events occurring away from a molecule node, reducing the possibility of an off-atom label being inadvertently drawn.

For details, see the Metamolecular Company Blog.

Adobe Flash for Cheminformatics: Fast, Scalable, and Attractive 2D Depiction of Chemical Structures with Vector Graphics

Rich Apodaca — Tue, 10 Jun 2008 11:05:00 -0400

The previous article in this series discussed the use of vector graphics markup languages for cheminformatics, in particular for the display of 2D chemical structures. Although vector graphics are well-suited for creating responsive and appealing cheminformatics Web applications, the lack of universal native browser support makes both Scalable Vector Graphics (SVG) and its cousin Vector Markup Language (VML) unattractive at this time. This article highlights Adobe Flash as a 2D chemical structure renderer for Web applications, and features a fully-functional proof of concept based on the ChemWriter rendering engine.

About Adobe Flash

Although Adobe Flash is practically an industry unto itself today, at it's core, Flash is a lightweight vector graphics renderer. Introduced in 1996, the Flash Player can be found on millions of Internet-enable devices today. According to a study by Adobe, the Flash Player was running on nearly 99% of Internet-enabled desktops as of March 2008. The player has also found its way onto a host of handheld devices and phones.

Many technologies have been layered on top of the Flash Player. One of the first was the ActionScript scripting language. More recently, Adobe has introduced Flex, a full-fledged application development framework.

Unlike SVG and other vector graphics systems, Flash is ready today, proven, and about as close to universal as is possible on the Web. If you want to do vector graphics on the Web with the most convenient user and developer experience, Flash is your tool.

But what can Flash do for cheminformatics?

A Demonstration

The table below is composed of twelve cells, each of which display a chemical structure through the Flash Player.

zoom	zoom	zoom
zoom	zoom	zoom
zoom	zoom	zoom
zoom	zoom	zoom

Several points are worth mention:

Each of the structures can be zoomed by clicking on its 'zoom' link.
Each cell contains a lightweight embedded "SWF" file, or "ShockWave File," and the zoomed view displays exactly the same file. No matter how the SWF file is resized, it will always be proportionally-scaled to its smallest dimension and centered.
The size of each SWF file ranges from a low of 563 bytes to a high of 8.5 KB, with an average of around 1.5KB. The larger the molecule, the more space is required. A comparable PNG with a resolution of 150x150 pixels would require on average for each structure about 6-8 KB.
Each image was generated from a molfile using a development version of the ChemWriter rendering engine via the open source Transform SWF Java toolkit.
SWF Files, unlike applets, are highly optimized for multiple instance display on all major platforms and browsers. In every case, startup will be nearly instantaneous and scrolling will be smooth. The performance of Flash should be at least as good as, if not better than, raster images.

The Right Tool for the Job (is Probably not a Raster Image)

One of the first challenges developers of cheminformatics Web applications are faced with is how to render 2D chemical structures. For an overview of the technologies now in use, see the previous article in this series. Each option has its own set of trade-offs.

The most widely-used 2D structure rendering option, raster images, is both inflexible and inefficient. Unlike a vector image, a raster image by definition has only one resolution, which is fixed at creation time. If image dimensions need to change, then all structures must be re-imaged. Given the size of many of today's chemistry databases, such a system-wide re-imaging of structures can involve a non-trivial amount of processor power and bandwidth.

To compensate, many sites store relatively large images, say 300x300 pixel, and then use the HTML <img> tag to shrink it as needed. But this creates problems of its own: both storage and bandwidth requirements are far larger than they need to be, resulting in the need for more powerful server hardware and poorer application scalability. And then there are the application's users, who must wait through a 30KB or higher download for each 2D image.

A significant number of structures in any compound collection will be so large that even a 300x300 pixel image will be insufficient to render the necessary detail. For example, a recent Depth-First article discussed a vector graphics solution this problem within the context of Chempedia, the free chemical encyclopedia. Vector graphics simply eliminate this issue.

Many cheminformatics applications would benefit from being able to show 50 or more structures at a time, with each structure having a zoom view for closer inspection. To a non-chemist, this might seem unnecessary. But for today's chemists dealing with large chemical catalogs and high-throughput screens, it's not only possible, but a routine part of the practice of chemistry. The raster image approach makes it extremely difficult to meet this important need on the Web. Vector graphics, possibly delivered through the Flash Player, offer a much simpler and more efficient way to do it.

2D chemical structures are vectorial in nature; using raster images to depict them is in most cases the more costly and lower quality option.

Summary

Vector graphics are a near-perfect match for the job of depicting 2D chemical structures on the Web. Although there are many vector graphics platforms to choose from, the Flash Player is by far the most universal option. This article has demonstrated a working example of multiple 2D chemical structures rendered as lightweight vector images via the Adobe Flash Player, the first and only such demonstration of which I'm aware.

The key technologies behind this demonstration are the ChemWriter rendering engine and the open source Flash developer toolkits available from Flagstone Software. If you're interested in learning more about how vector graphics and Flash can improve both the user and developer experience in your cheminformatics Web applications, I'd be happy to hear from you.

Chempedia.net: Mashing Up PubChem and Wikipedia

Rich Apodaca — Fri, 04 Apr 2008 10:06:00 -0400

PubChem and Wikipedia represent two of the largest open repositories of chemical information in the world. And they complement each other very nicely. PubChem contains mainly low-level chemical structure information whereas Wikipedia contains free-text descriptions of chemical compounds in the form of compound monographs.

Both services offer permission and access to copy and reuse their contents. But neither service is, by itself, nearly as useful as it could be.

Why not mash them up?

To explore that question my company, Metamolecular, LLC has launched Chempedia.

To my knowledge, Chempedia represents the first publicly-facing database of compounds to incorporate Wikipedia's collection of organic compound monographs. And it's one of the few cheminformatics services to make use of free-text descriptions generated by individual chemists.

Chempedia has been somewhat selective about the compounds it includes. To date, it has spidered over 2,500 monographs, combining them with over 300,000 of the most interesting compounds from PubChem. Not every Chempedia.net molecule has a monograph, but now there's a tool that can actually make that absence apparent.

Chempedia is both an experiment and a service. It's immediately useful for anyone in the business of making or doing things with organic molecules. It's created several unexpected moments of "Oh, that's actually a useful molecule!" It also will serve as a platform to test some of the ideas discussed in Depth-First over the last year or so on the advantages of the Web for collaboration in chemistry.

Stay tuned for more details about how Chempedia was created and some of its applications in chemistry.

Five Open Tools for 2D Structure Layout (aka Structure Diagram Generation)

Rich Apodaca — Wed, 26 Mar 2008 09:11:00 -0400

Given a molecular representation without 2D coordinates, how would you display a human-readable view?

This problem can arise in many situations, one of the most common of which is the parsing of line notations such as IUPAC nomenclature, SMILES, or InChI.

And then there are the cases when you have 2D coordinates, but they're not very aesthetically pleasing. Maybe the coordinates were created by people either in a hurry or working with low quality editors, or maybe they were generated as distorted 2D projections of 3D coordinates. Whatever the reason, simply having 2D coordinates may not be the same as having good 2D coordinates.

Last year, a Depth-First article discussed the Structure Diagram Generation (SDG) problem and how it can be solved with Open Source software. Given that nearly a year has passed, it seemed appropriate to revisit the topic.

The good news is that there are at least four independent Open Source implementations of SDG algorithms, and one potential open database approach. They are, in no particular order:

MCDL Written in Java, the emphasis of this software appears to be facilitating the use of Modular Chemical Descriptor Language. Unfortunately, no new releases of this intriguing software package have been made in the last year.
Chemistry Development Kit (CDK) This useful package handles about 70-80% of a typical assortment of chemical structures well. The large amount of activity on the CDK project in general makes this a particularly good SDG system to contribute to, especially in the areas of refactoring and handling special cases. See also Christoph Steinbeck's overview of CDK's layout system.
BKChem A 2D structure editor written in Python. Give it an InChI and it will display the structure, courtesy of SDG. The system worked remarkably well with the molecules I tested. BKChem has also been reported to work in batch mode.
RDKit Written in Python and C++, this package is the newest of the bunch. Although I haven't had much luck compiling RDKit, it still looks quite promising. Any chance of switching to make as a build system?
PubChem PubChem? Maybe. With a database of small molecules now numbering well over ten million, there's a good chance that the molecule for which you need to assign coordinates is already in PubChem. And if it's in PubChem, 2D coordinates have already been assigned. Use an InChI as a hash key, and voila - instant SDG without much software. Given the novelty of large, publicly-available databases of small molecules such as PubChem, this approach may have a great deal of untapped potential.

SDG is one of those issues that can stay off the radar for some only to become an instant, nagging problem with no clear way out. The tools cited here offer an excellent place to begin working toward a comprehensive solution.

Demystifying Java Applets Part 3: Failing Gracefully When Your Users Don't Have Java

Rich Apodaca — Wed, 12 Mar 2008 23:26:00 -0400

Contrary to popular misconception, Java applets are a mature technology ideally suited for building highly interactive Web content. Although this hasn't always been the case, a lot has changed since Sun's introduction of Java over a decade ago. Previous articles in this series have discussed why the object tag alone can and should be used to deploy applets and how using the Javay deployment method can make life easier if you do. This article will address one of the most important questions of all when using applets: what happens if your user doesn't have Java?

Assume Your Users Won't Have Java

Java is ubiquitous, but it's not universal. Some users simply won't have a Java Virtual Machine (JVM) installed at all on their systems. Some will have one, but it will be disabled. Still others may have been browsing the Web for years, never realizing that Microsoft installed a hopelessly obsolete JVM on their machines without their knowledge, rendering useless a large amount of Web content.

Regardless of why they might not have the JVM your applet requires, assume that a good number of your users won't and plan accordingly.

But how?

The Javay Method and Deployment Failsafes

The Javay method for applet deployment can be broken down into three main parts:

Using the HTML 4 <object> tag - period. Neither <applet>, which is deprecated, nor <embed>, which isn't even part of HTML, are needed any longer.
Using Microsoft's conditional comments to create an opening object tag that will work with its browsers, but keeping it DRY by re-using the rest of the tag.
Suppressing the ridiculous "Click to activate" message in IE 6/7 with jActivating.

In contrast to other approaches, with the Javay method, we can:

Know our applet will instantiate on all major browsers, and many niche browsers as well.
Work only with standards-compliant HTML from start to finish.
Stop using document.write to create tags, a method which unless properly trapped will silently fail without any indication of what's wrong when JavaScript is disabled or if the script fails for some other reason.

But perhaps the biggest advantages of the Javay method are the ones most often overlooked:

It offers a cross-browser method to display failsafe content should Java be disabled or not installed.
It provides a highly effective, cross-browser method for users to install Java directly from the page displaying the applet.

How the Failsafe Works

When modern browsers such as Firefox and Internet Explorer encounter an <object> tag requesting a plugin they don't understand, they do two very useful things:

They render any valid HTML appearing after the <object> tag's child <param> elements.
They prompt the user to install the correct plugin to view the content - without redirecting them to another page.

These two behaviors give us everything we need to gracefully fail if the Java plugin is unavailable. When the Java plugin is installed and enabled, users see the applet as planned. When the Java plugin is either not installed or disabled, users see both a placeholder of our choosing and a prompt, created by the browser itself, offering to install the missing plugin.

The <object> tag lets us take this even further. We can specify, down to the revision level, the exact version of Java needed to run an applet. If that requirement changes, all we need to do is change the <object> tag and users will be prompted to upgrade their JVM the next time they see our applet - if necessary.

Live Demo

Here's my company's 2D chemical structure editor, ChemWriter, deployed with the Javay method:

And here's what the failsafe code looks like when it's rendered:

One More Thing

We can take failsafes to yet another level, if we'd like. Let's say Joe comes to our site without the an installed Java plugin. Internet Explorer 6 informs him via a popup that Java is needed. Impatient to see the site's content, he closes the dialog. Without being redirected, Joe can see all of the site's content, except for the parts requiring Java, for which he sees a custom "Plugin Not Found" placeholder. Discovering that the site's content consists of highly-relevant information, he decides he wants to install the Java plugin after all. Clicking on placeholder image takes him to a Java installation page.

Unlike other Java installation pages Joe may have seen, this one is specific to his browser, Internet Explorer 6.

This approach work very well in practice. For example, my company's website, metamolecular.com uses it. Try visiting the default Java installation page, and if your browser is included below, you'll be redirected to the browser-specific Java installation page:

More information can be found in this article on deploying ChemWriter.

Last Thoughts

Java applets gained a deserved reputation in the late '90s for being difficult to deploy, a view that's now worth reconsidering. Using some simple techniques, Web applications can fail gracefully if Java is unavailable and then take steps to quickly get users back on track.

Getting software reliably and securely installed on any client system is difficult, especially on the open Web. But the Java plugin and the Javay deployment method make it about as straightforward as it can possibly be.

It's time reconsider applets.

Image Credit: brrtha

Demystifying Java Applets Part 2: DRY Deployment with the Javay Method

Rich Apodaca — Mon, 10 Mar 2008 11:13:00 -0400

Java applets are easy to deploy in a standards-compliant way across multiple browsers - you just need to know how. The previous article in this series gave some general pointers to better applet deployment, including the use of the <object> tag. This article will show how to make this deployment method even more concise with the Javay Method.

Keeping it DRY

The code from the previous article used two completely different <object> tags: one for Internet Explorer and one for all other browsers:

<!--[if !IE]> -->
<object classid="java:com/metamolecular/chemwriter/applet/EditorApplet.class" 
              type="application/x-java-applet"
              archive="/path/to/applets/chemwriter.jar" 
              height="350" width="550" >
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <!-- For Konqueror -->
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>

    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<!--<![endif]-->
<!--[if IE]>
<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" 
                codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0"
                height="350" width="550" > 
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>
    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<![endif]-->

Conditional comments are used to ensure that IE sees one definition and standards-compliant browsers see another. But notice the large amount of repetition, specifically the parameters list, the failsafe code, and the closing <object> tag.

Surely there must be a better way.

A Widespread Problem

Microsoft's idiosyncratic use of the <object> tag doesn't just cause difficulties for Java applets: it rears its head with all plugin content. This problem is so widespread in the Flash world that its solution even has a name: Flash Satay.

In the language of Drew McLellan, inventor of Flash Satay, the applet code listing above is the "twice-cooked method" - we repeat the same code twice.

The twice-cooked method violates one of the most important principles in software development: Don't Repeat Yourself (DRY). It's an invitation cross-browser bugs. If we forget to include the same parameter twice, or if we mistakenly use one parameter for IE and another for standards-compliant browsers, for example, we've just created a potentially nasty headache for ourselves.

Drying Up the `<object>` Tag

We can DRY up our applet <object> tag by factoring out what's common: the parameters listing; the failsafe code; and the closing <object> tag:

<!--[if IE]><object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0"
width="480" height="350"><script>/*<![endif]--><script type="text/javascript">/**/</script>
<!--[if !IE]><!-->
<object type="application/x-java-applet;version=1.4.2" width="480" height="350">
<!--<![endif]-->
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class">
  <param name="archive" value="/applets/chemwriter.jar">
  <param name="persistState" value="false">
  <param name="licenseKey" value="4BC4-3C59-3E7D-182B-92B7-2E68">
  <a href="http://metamolecular.com/java/">
    <img src="http://depth-first.com/demo/20080310/chemwriter_plugin.png" style="padding: 125.0px 190.0px 125.0px 190.0px; border: 1px dashed red;"/>
  </a>
</object>

This approach was inspired by the BlaTek Satay method, which uses the cute empty JavaScript as a way to prevent IE from showing unwanted characters. To my knowledge, it's never before been applied to applets.

In the long tradition of naming these hacks after the original Satay method, I call this one "Javay."

The Javay method's only repetition is in the width and height attributes. Even this redundancy could be eliminated, if we chose, by setting each to "100%" and enclosing the result in a <div> tag that did specify size.

The above code works in all major browsers, including Safari, Firefox, Internet Explorer 6 and 7, Opera, and Camino. If you find a browser on which the code doesn't work, I'd like to hear about it.

Here's what the code produces, using my company's 2D structure editor ChemWriter as an example:

Conclusions

To summarize, Java applets can be deployed in a cross-browser, standards-compliant way using the Javay Method. This method solves some of the trickier problems when deploying applets, specifically:

Uses the HTML 4 <object> tag, eliminating the deprecated <applet> tag.
Works on both IE and standards-compliant browsers in a DRY way.
Suppresses the annoying "Click to activate" message in IE 6 and 7 with jActivating.
Avoids the use of document.write and the problems that can arise if JavaScript is disabled.
When Java is either missing or not installed, provides a cross-browser failsafe (more on this next time).
Leaves us with nothing but pure, standards-compliant HTML to write, debug, and maintain.

We've pretty much got everything the old <applet> tag used to have - and more.

But what if your users don't have Java? Tune in next time to see how to solve this problem once and for all.

Image Credit: Things are Better with a Parrot

Demystifying Java Applets, Part 1: Cross-Browser, Standards-Compliant, Pure HTML Deployment Using the Object Tag

Rich Apodaca — Wed, 20 Feb 2008 09:41:00 -0500

A 2006 survey on java.net posed a simple question to developers: What's wrong with applets? By a significant margin, the number one complaint was that they are "too hard to deploy." This article, the first in a series, takes a look at the issue of Java applet deployment and in particular how using the <object> tag can radically simplify and enhance both the developer and end user experience.

Applets? You Must Be Joking!

Applets got a well-deserved bad reputation in the early days of Java. They were slow, difficult to deploy across browsers, and over-hyped. The situation has signficantly changed for the better, but the bad reputation lingers.

There are many situations in which applets are inappropriate. The most important of these is when simple interactivity can be achieved through HTML or JavaScript (Ajax).

But in many situations, HTML and JavaScript make a poor platform choice. As a specific example, consider Web-based chemical structure editors. The high level of graphical manipulation, sophistication of data processing, and responsiveness required by these components, coupled by their ubiquity, means that it will be a long time indeed before Ajax (or Flash for that matter) is up to the challenge - and they may never be, given their design constraints.

For a large number of specialized Web components, applets are the only platform.

Regarding the "uncool factor", it's worth pointing out that not more than four years ago JavaScript was one of the most loathed, ridiculed, and ignored technologies around. Now it finally works - meaning it's reliable enough to be used on all modern browsers. The result is Ajax and a host of interactive Web technologies that played a major role in redefining what the Web was all about.

Whether a similar renaissance happens for applets is anybody's guess, but most of the prerequisites have already been met.

Deployment with the `<applet>` Tag

If you decide to develop Web applications with applets, a major consideration will eventually become how to deploy them. Unfortunately, a bewildering array of often contradictory advice is available on the subject - most of it outdated.

Many sources recommend using the <applet> tag. It's the oldest method, and will generally work on most browsers. For example, to deploy my company's structure editor applet ChemWriter, the following code could be used:

<applet code="com/metamolecular/chemwriter/applet/EditorApplet.class"
        archive="/path/to/applets/chemwriter.jar"
        width="600" height="300">
  <param name="persistState" value="false" />
</applet>

Unfortunately, the <applet> tag has some very important strikes against it. The first is that its use is now deprecated in HTML. In other words, whatever support browsers now have for it is living on borrowed time.

The second problem with the <applet> tag is an insidious bug in Internet Explorer (as if there were any other kind). Most hardware suppliers pre-install Java onto their Microsoft-based machines, which is a good thing. The bad thing is that at least one major manufacturer disables the Java console in IE 7 at the same time. Under IE 7, disabling the Java console renders all <applet> tags invisible. Counterintuitive as it may seem, this is what happens. The insidious part is that perplexed users know they have Java installed because they can see the plug-in, are being told by IE that it's active, can find some applets that *do* work and - well, you get the idea.

The third problem with the <applet> tag is that, by itself, it has no mechanism to indicate which version of Java is required. This can be a very important consideration for applets that take advantage of the major advances in functionality and performance of the Java platform in recent years.

A Better Way: Deployment with the `<object>` Tag

All major browsers support the <object> tag, and this is the preferred method for deploying applets. Provided that Internet Explorer's peculiarities are accounted for, a single piece of valid HTML can render applets on all major browsers including:

IE 6/7
Firefox 1.5/2
Safari

As a specific example using ChemWriter, the <applet> tag above can be re-written with the <object> tag:

<!--[if !IE]> -->
<object classid="java:com/metamolecular/chemwriter/applet/EditorApplet.class" 
              type="application/x-java-applet"
              archive="/path/to/applets/chemwriter.jar" 
              height="350" width="550" >
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <!-- For Konqueror -->
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>

    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<!--<![endif]-->
<!--[if IE]>
<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" 
                codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0"
                height="350" width="550" > 
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>
    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<![endif]-->

Before explaining the code, here's what the verbosity buys:

It works with both IE 6/7 and standards-compliant browsers such as Firefox.
It avoids the use of JavaScript JVM detection methods.
It prompts the user to download the correct JVM, without immediately directing them away from the current page.
Firefox and IE users can opt to install the Java plugin without ever leaving their current page.
It works in IE 7 with the Java console disabled.

You've Got Some 'Splainin' to Do

The code above is based on documentation found on this site, which also details the meaning of the codebase and classid attributes.

The main idea is that Internet Explorer handles the <object> tag in its own idiosyncratic, lovable way. Most of this difference is in the <object> element itself and the classid attribute in particular. By taking advantage of Internet Explorer's support for conditional comments, we can handle both IE and the rest with one chunk of HTML.

A Live Demonstration

For a live demonstration of the above technique, see the ChemWriter Home Page. If you have Java 1.4.2 or higher installed and activated in your browser, you'll see the most recent version of the ChemWriter editor applet. If not, you'll see the ChemWriter logo and a link to install Java. Firefox and IE will also display an "Install Plugin" bar at the top of the browser for in-place installation of the JVM.

Click to Activate: Working Around Eolas

A recent Depth-First article discussed the problem that IE 6 and 7 have involving a "click to activate" (or "Eolas") message that appears with applets and all other browser plugins. To eliminate this issue, the ChemWriter Home Page uses the excellent jActivating library. This JavaScript library, which is included in the HTML <head> tag, obviates the need to write the <object> tag using JavaScript. All that's left is pure, standards-compliant HTML to debug, deploy, and maintain.

Conclusions

Applet deployment, like Java itself, has come a long way in the last ten years. This article has shown one method to deploy applets into highly heterogeneous computing environments with relatively little effort.

But deployment is only one aspect of interactive Web development using applets. Future articles will discuss some of the others.

Image Credit: oskay

Depth-First: Tag java

ChemWriter 1.3.1

3D Molecular Visualization on the Web: OpenAstexViewer

Screencast: Drawing Structures Quickly With ChemWriter

Better Structure Drawing With ChemWriter 1.3.0

Adobe Flash for Cheminformatics: Fast, Scalable, and Attractive 2D Depiction of Chemical Structures with Vector Graphics

About Adobe Flash

A Demonstration

The Right Tool for the Job (is Probably not a Raster Image)

Summary

Chempedia.net: Mashing Up PubChem and Wikipedia

Five Open Tools for 2D Structure Layout (aka Structure Diagram Generation)

Demystifying Java Applets Part 3: Failing Gracefully When Your Users Don't Have Java

Assume Your Users Won't Have Java

The Javay Method and Deployment Failsafes

How the Failsafe Works

Live Demo

One More Thing

Last Thoughts

Demystifying Java Applets Part 2: DRY Deployment with the Javay Method

Keeping it DRY

A Widespread Problem

Drying Up the <object> Tag

Conclusions

Demystifying Java Applets, Part 1: Cross-Browser, Standards-Compliant, Pure HTML Deployment Using the Object Tag

Applets? You Must Be Joking!

Deployment with the <applet> Tag

A Better Way: Deployment with the <object> Tag

You've Got Some 'Splainin' to Do

A Live Demonstration

Click to Activate: Working Around Eolas

Conclusions

Drying Up the `<object>` Tag

Deployment with the `<applet>` Tag

A Better Way: Deployment with the `<object>` Tag