Depth-First: Tag applet

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.

Solve Web Application Scaling Problems With Signed Applets

Rich Apodaca — Fri, 25 Apr 2008 13:12:00 -0400

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.

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

Hacking JSpecView: Enhancing the User Interface

Rich Apodaca — Fri, 01 Feb 2008 11:25:00 -0500

The last installment of this series showed how to set up an HTML testing harness for JSpecView. With the preliminaries taken care of, this installment will show how to enhance the user interface.

The Goal

The live applet shown above illustrates the changes that were made. As you move your mouse cursor into the spectrum area, you'll see a vertical red line appear and track the movements of the mouse. As you presss the mouse key to begin a selection, a grey rectangle will show you exactly where the selection area will be.

If you can't view the applet, be sure you system has JDK 1.5 or higher installed, and that you've enabled applets for your browser.

Clearly, these modifications need more work. For example, you can extend the selection box outside the boundary of the spectrum area. And green might be a better color for the cursor. Then again, maybe the cursor should use an alpha channel. But I digress.

One More Thing

Being a longtime Eclipse user, I prefer this tool for my Java development. So far, only the use of Ant has been described. Fortunately, Eclipse offers an elegant way to import an existing Ant project. File->New gives a dialog like the one shown below:

Selecting "Java Project from Existing Ant Buildfile" gives this dialog:

Filling in the fields as shown should give a fully-functional Eclipse project.

Still One More Thing

If you check the HTML source for this page, you'll notice that the applet tag is used to display the applet. Yet on Internet Explorer, there is no "click to activate" message. The reason is that Depth-First is using the excellent JavaScript library JActivating, which re-writes the applet tag so that it isn't detected by the Eolas workaround. This lets us stick with plain HTML, rather than using document.write to specify the applet.

Changing the Source Code

Too many changes were made to detail individually. In general, they related to:

Removing non-applet classes such as those involved with the desktop application.
Removing code flagged by Eclipse as unused.
Editing the jspecview.common.JSVPanel source to add the UI modifications. The drawGraph, drawCursor, and drawZoomBox methods contained most of the changes.

The complete Eclipse project should be available from SourceForge shortly.

Conclusions

Given the right tools, modifying JSpecView is not that difficult. We've gone from raw souce code to a complete Eclipse project, and even added some functionality in the process.

Where would you like to take JSpecView?

Hacking JSpecView: Creating an HTML Test Harness

Rich Apodaca — Mon, 28 Jan 2008 10:37:00 -0500

The previous article in this series discussed the construction of an Ant build environment for JSpecView. This article will show how to use Ant to build an HTML harness to test the resulting Applet and jarfile.

Availability of Source Code

Robert Lancashire, the lead JSpecView developer, has kindly agreed to host the complete source code for this series of tutorials on the JSpecView SourceForge project page.

Overview

Our goal for this session is to create an Ant task that will assemble a directory of HTML pages for testing the JSpecView applet. To do this, we'll add a new demo task and some supporting files.

Editing the build.xml File

The main change we'll make is to add the demo task itself:

<target name="demo" depends="jar">
  <mkdir dir="${demo}" />
  <copy todir="${demo}">
    <fileset dir="${resources-html}" />
  </copy>
  <copy file="${build-lib}/${unix-name}-${version}.jar" tofile="${demo}/lib/${unix-name}.jar" />
</target>

This task creates a demo directory and copies into it the contents of a new resources/html directory, along with the jarfile built with the jar task.

Other changes to the build.xml file are necessary. In the interest of brevity, they have been omitted. Those interested should download the source package to be available shortly.

Creating the resources Directory

Think of the resources directory as a place to hold non-Java files that will get used by our Ant tasks. Our first addition to this directory will be a directory called html. Here, we'll create a new directory called demo1. It will contain an HTML document with an embedded JSpecView applet (index.html), along with a JCAMP-DX file (netanilineH.jdx) and the excellent JActivating JavaScript tool.

Using the `demo` Task

We can run our new demo task just like the others:

$ ant demo Buildfile: build.xml init: [mkdir] Created dir: /home/rich/devel/proj/jspecview/build [mkdir] Created dir: /home/rich/devel/proj/jspecview/build/classes [mkdir] Created dir: /home/rich/devel/proj/jspecview/build/lib compile: [javac] Compiling 48 source files to /home/rich/devel/proj/jspecview/build/classes jar: [jar] Building jar: /home/rich/devel/proj/jspecview/build/lib/jspecview-20080128.jar demo: [mkdir] Created dir: /home/rich/devel/proj/jspecview/demo [copy] Copying 3 files to /home/rich/devel/proj/jspecview/demo [copy] Copying 1 file to /home/rich/devel/proj/jspecview/demo/lib BUILD SUCCESSFUL Total time: 3 seconds

If all went well, you should see a new demo directory with the following structure:

Viewing the Result

You can view the result online here. The applet loads and displays the JCAMP-DX file netanilineH.jdx. Notice that the spectrum is interactive; zoom and display properties can be set by right-clicking in the applet Window.

Conclusions

This tutorial has show how to build a simple HTML test harness for JSpecView. With this important step complete, we can begin to customize JSpecView itself. Future tutorials will show how.

Hacking JSpecView: Getting Organized with Ant

Rich Apodaca — Wed, 23 Jan 2008 10:28:00 -0500

JSpecView is a general-purpose X-Y data viewer suitable for Web applications. The previous article in this series introduced JSpecView and discussed the importance of this kind of software in building rich, chemically-aware Web applications. This article will illustrate one way to set up the JSpecView build environment to easily enable extensions and modifications to be outlined in articles that will follow.

Prerequisites

This tutorial will use Apache Ant. For those unfamiliar with it, Ant is a platform-independent build tool like make. It automates the drudgery of compiling software and building its accessories such as documentation, jar files, and so on. Although far from perfect, Ant is the most widely-used Java build tool.

Configure Your Build Directory

Download and unpack the most recent version of the JSpecView source distribution ("2008Jan13" as of this writing) into a directory of your choice. When finished, you should end up with a directory structure like this:

Now, re-arrange the files and directories:

Create a new directory called src to hold source files and lib to hold external libraries.
Move jspecview, mdidesktop, and test into the new src directory.
Delete META-INF
Add an empty file called build.xml

When finished, your new directory structure should look like this:

Adding External Libraries

Compiling JSpecView in its current form requires two external libraries - let's add them now.

The first library is the LiveConnect JavaScript library named plugin.jar. It can be found in your Java Developer Kit. It's typically located under the jre/lib directory. Copy this file into your JSpecView lib directory.

The second library we'll need is Velocity. Copy the Velocity-1.5 jarfile into your JSpecView lib directory.

Create build.xml

All that remains is to create an Ant build.xml file. There are many ways to do this; the file presented below is but one of them:

<?xml version="1.0"?>

<project name="JSpecView" default="compile" basedir=".">
  <description>
    A JCamp-DX Viewer
  </description>
  <property name="full-name" value="JSpecView" />
  <property name="short-name" value="JSpecView" />
  <property name="unix-name" value="jspecview" />
  <property name="version" value="20080113" />
  <property name="img" location="icons" />
  <property name="src" location="src" />
  <property name="lib" location="lib" />
  <property name="build" location="build" />
  <property name="build-classes" location="build/classes" />
  <property name="build-lib" location="build/lib" />
  <property name="doc" location="doc" />
  <property name="dist" location="dist" />
  <property name="bin-dist" location="${dist}/bin" />
  <property name="src-dist" location="${dist}/src" />

  <target name="compile" depends="init" description="compile the source">
    <javac srcdir="${src}" destdir="${build-classes}" debug="on" source="1.5" target="1.5">
      <classpath>
        <fileset dir="${lib}">
          <include name="**/*.jar" />
        </fileset>
      </classpath>
    </javac>
  </target>

  <target name="jar" depends="compile">
    <jar jarfile="${build-lib}/${unix-name}-${version}.jar" basedir="${build-classes}" >
    </jar>
  </target>

  <target name="init">
    <mkdir dir="${build}" />
    <mkdir dir="${build-classes}" />
    <mkdir dir="${build-lib}" />
  </target>

  <target name="doc" depends="compile" description="create the full api documentation">
    <javadoc sourcepath="${src}" packagenames="*" destdir="${doc}" windowtitle="${short-name} API">
      <doctitle>${full-name} v${version}</doctitle>
        <header>${full-name} v${version}</header>
      <classpath>
        <fileset dir="${lib}">
          <include name="**/*.jar" />
        </fileset>
      </classpath>
    </javadoc>
  </target>

  <target name="clean" description="remove dist, doc, and build directories">
    <delete dir="${build}" />
    <delete dir="${dist}" />
    <delete dir="${doc}" />
  </target>
</project>

The purpose of this file is to create five general-purpose scripts: compile, jar, init, doc, and clean.

Compiling the Jarfile and Documentation

The build.xml file can be tested by using it to compile the JSpecView source:

$ ant
Buildfile: build.xml

init:
    [mkdir] Created dir: /home/rich/devel/proj/jspecview/build
    [mkdir] Created dir: /home/rich/devel/proj/jspecview/build/classes
    [mkdir] Created dir: /home/rich/devel/proj/jspecview/build/lib

compile:
    [javac] Compiling 48 source files to /home/rich/devel/proj/jspecview/build/classes

BUILD SUCCESSFUL
Total time: 3 seconds

If you don't get this result, make sure your libraries are installed in the lib directory and that you've moved all Java sourcecode directories into the src directory.

We can build a JSpecView jarfile just as easily:

$ ant jar
Buildfile: build.xml

init:

compile:

jar:
      [jar] Building jar: /home/rich/devel/proj/jspecview/build/lib/jspecview-20080113.jar

BUILD SUCCESSFUL
Total time: 1 second

As you can see from the output, the jarfile has been placed into the build/lib directory.

We can also create JavaDoc documentation:

$ ant doc
Buildfile: build.xml

init:

compile:

doc:
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Creating destination directory: "/home/rich/devel/proj/jspecview/doc/"
  [javadoc] Loading source files for package jspecview.applet...
  [javadoc] Loading source files for package jspecview.application...
  [javadoc] Loading source files for package jspecview.common...
  [javadoc] Loading source files for package jspecview.exception...
  [javadoc] Loading source files for package jspecview.util...
  [javadoc] Loading source files for package jspecview.xml...
  [javadoc] Loading source files for package mdidesktop...
  [javadoc] Loading source files for package test...
  [javadoc] Constructing Javadoc information...
  [javadoc] /home/rich/devel/proj/jspecview/src/jspecview/util/DisplaySchemesProcessor.java:31: package org.apache.xerces.parsers does not exist
  [javadoc] import org.apache.xerces.parsers.DOMParser;
  [javadoc]                                 ^
  [javadoc] Standard Doclet version 1.6.0_01
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating /home/rich/devel/proj/jspecview/doc/stylesheet.css...
  [javadoc] 1 warning

BUILD SUCCESSFUL
Total time: 10 seconds

The result is placed into a new doc directory. As you can see from the output above, there was a problem finding the Xerces DOMParser, a library we may need to include in the lib directory for future iterations.

To clean up the directories our script created, we simply use:

$ ant clean
Buildfile: build.xml

clean:
   [delete] Deleting directory /home/rich/devel/proj/jspecview/build
   [delete] Deleting directory /home/rich/devel/proj/jspecview/doc

BUILD SUCCESSFUL
Total time: 0 seconds

Conclusions

With a build environment configured and working, we can move on to building a test harness and making modifications. But that's a story for another time.

Depth-First: Tag applet

ChemWriter 1.3.1

3D Molecular Visualization on the Web: OpenAstexViewer

Solve Web Application Scaling Problems With Signed Applets

Chempedia.net: Mashing Up PubChem and Wikipedia

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

Hacking JSpecView: Enhancing the User Interface

The Goal

One More Thing

Still One More Thing

Changing the Source Code

Conclusions

Hacking JSpecView: Creating an HTML Test Harness

Availability of Source Code

Overview

Editing the build.xml File

Creating the resources Directory

Using the demo Task

Viewing the Result

Conclusions

Hacking JSpecView: Getting Organized with Ant

Prerequisites

Configure Your Build Directory

Adding External Libraries

Create build.xml

Compiling the Jarfile and Documentation

Conclusions

Drying Up the `<object>` Tag

Deployment with the `<applet>` Tag

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

Using the `demo` Task