Discussion and Conclusions

The basic application as originally conceived, i.e. a readily accessible tool for remote consultation and exploratory grid browsing, is successful. In our project for developing automated data acquisition tools, JavaScope has been used by our collaborators in California (Research Institute at Scripps Clinic) to control the TEM in Illinois and provide advice as to the worth of acquiring data from a particular specimen. It has also had an additional benefit in providing students at the microscope with a means by which they can consult with an advisor who might be located at a remote location (i.e. across campus).

This initial investigation of the use of Java as a tool for remote control and image viewing has however illustrated a number of areas where Java does not provide the required solutions. Java has evolved rapidly over the past several years, generally improving with each revision, but the suppliers of web browsers have not done as well in keeping their JVM and AWT implementations current. Consequently different versions of each web browser support a different version of Java; for example:

As a further complication, various vendors have developed a technology called the Just-In-Time (JIT) Compiler. This allows the JVM to compile Java bytecode into native machine language in blocks and keep the compiled chunks around in case they are needed again. This vastly improves performance over the standard JVM which interprets the Java bytecode one chunk at a time and then has to re-interpret a short while later. Java 1.2, not yet widely implemented, promises further improvements in cross platform consistency and performance enhancements. There are also numerous extensions available (class libraries often compiled native to the JVM host computer) which can be added to the JVM environment. These range from 3D graphics to database integration but are not provided "out-of-the-box" with the JVMs provided with current web browsers.

JavaScope design goals necessitated writing this applet for the lowest common denominator (JDK and AWT 1.0.2) which had a number of practical and negative impacts. It has severely restricted what can be done with the interface and made it difficult to develop an interface that appeared identical across Windows, Macintosh and Unix platforms. Also the amount of memory Java can access is variable depending on the version of web browser used and it is often not possible to increase the amount of memory available. As a result the current implementation of JavaScope can not handle 1024x1024 images. Furthermore, as Java is an interpreted language it is very slow at handling large amounts of data (although some implementations work quite well as they include JIT compilers). Given these restrictions, our conclusion is that Java is not an unqualified success as a cross-platform web-based application development tool. This negative opinion would be modified if we could assume the availability of Netscape Navigator 4.0.6 or Internet Explorer 4.x or later, in which case we could assume Java AWT 1.1 was available. In addition, if the user is running Windows 95, 98 or NT we could assume a good JIT compiler is in action which would allow the Java applet to do more. However, placing these restrictions on the user of the application would defeat the primary initial goal of the project which was to supply a universally available and simple interface to the TEM.

Since JavaScope is a qualified success as a collaborative and consultation tool we plan to add some simple extensions to it in the form of an improved user interface, faster applet loading, and possibly the ability to save and print images. These future versions will require more recent versions of Java, currently Internet Explorer 4.x or Netscape Navigator 4.06 or later. These improvements will be at the expense of serving the lowest common denominator in web browsers and computer systems. It is clear that developing a Java application that works well cross-platform and with many different generations of browsers is difficult at best. This makes it impossible to develop any application and expect it to run "out-of-the-box" in all cases. To get the most out of Java it is necessary to specify which release is required and even possibly what implementation patches may be required for each platform explicitly supported.

In addition to Java there are other alternative web-based application delivery mechanisms. The emScope project (on which the server end of this application is based) has adopted the use of the scripting language Tcl/Tk (Ousterhout, 1994). Internet Explorer and Netscape plug-ins exist on most major platforms for running Tcl/Tk scripts. Unlike Java, Tcl/Tk is a relatively simple scripting language with remarkable power and extensibility. While complex Tcl/Tk applications are difficult to develop organizationally, small to moderate sized applications are relatively easy to develop. For example, while JavaScope took months to develop, a similar Tcl/Tk stand-alone application was developed in two weeks. This would appear to indicate that developing applications of this size in Java may not be worth the software development time if Java is not otherwise the primary development platform of the group.

Would we use Java to develop another application? Probably not. But if we did we would do so with lower expectations. To succeed with Java the software developer will have to use the latest release of Java available and target a particular implementation to get the best performance and visual layout. Also it is clear that Java is not a simple, easy-to-use software development system. It can be as complicated as developing with C++ and certainly requires planning and considerable design before coding. This complexity comes with rewards for the seasoned developer, but is often at odds with software development in the scientific research community.

Page 5 of 7