[Index] [Introduction] [Installation] [Cookbook] [Package] [Component] [Chart] [Axis] [Utility] [Applet] [Servlet] [Appndx B] [API]

FRAMES   NO FRAMES   NO FRAMES INDEX


Appendix A - Deployment

Overview

Java class files have a standard organization and naming convention. All class files are found beneath one of the directories or zip/jar archives listed in the CLASSPATH environment variable. KavaChart classes are found beneath the "javachart" directory tree. The chart package is located in javachart/chart, the applet package is located at javachart/applet and so on.

Your applications and applets will reference classes in the chart directory with the naming convention javachart.chart.classname.class, or will import the entire package with a statement like:

These files are located in javachart/chart/*.class, and the javachart directory must be located in your CLASSPATH environment variable.

An alternative is to use a jar archive that contains the KavaChart classes you require. To use this, you would add the name of the archive to your CLASSPATH variable instead of the directory that contains it.

When you install an application that uses KavaChart, you must also install some or all of the KavaChart class files. For your convenience, we have supplied a jar archives that can be used for this purpose. You may not make copies of the KavaChart API documentation to include with your software distribution. This would violate your license to use KavaChart code.


Out, Damned Spot!

You've undoubtedly noticed that KavaChart's standard applets display a small blue rectangle at the lower right hand corner of each chart. This rectangle signals users of freeware KavaChart applets that KavaChart is a commercial product, through the message dialog that opens with every mouse click.

As a KavaChart licensee, you can remove the spot, and disable the information dialog in a number of ways:

Even though it's easy to remove KavaChart's default copyright notification, you are still subject to the terms of your license agreement.


Necessary Files

Because of KavaChart's modular construction and extensive list of supported charts, it's unlikely that any particular chart, or even any application or applet would require all KavaChart classes. Generally, you'll need your application or applet, and then a KavaChart class tree that contains some or all of the chart package, and possibly some of KavaChart's utility files or applet classes.

If you plan to use the KavaChart applets, you'll also need to be aware of the applet requirements. Because KavaChart's applets are organized into a package, you must include the javachart/applet directory, with ChartAppShell.class, MessageFrame.class, and whatever applets you plan to use.

If your application loads its classes from a local disk, it's a good idea to just use the standard KavaChart archive file or the standard class tree; either will work well. If you plan to use the applets from a browser, however, you may want to eliminate unused classes, and create a custom archive.

The Java VM in popular browsers makes a new TCP/IP connection for each required class. This means that an applet that contains many classes, such as a KavaChart graph, requires many round-trips to the server just to start up. To make matters worse, the time required to negotiate a new connection is usually longer than the time required to download each class, so the overall startup time for a multi-class applet can seem unreasonable.

To avoid this problem, most browsers now support some kind of archive file that can be downloaded in a single network connection. The contents of the file are then loaded dynamically from memory. This is a tremendous time saver because it eliminates uneeded network negotiation, but if you're working with low bandwidth connections, it also means that you need to eliminate unnecessary classes from your archives. For example, if you want to build a dynamic bar chart, you certainly don't need, and probably don't want to download classes for Speedo charts.
 


Archives

Java 1.1 and Java 2 confront the archiving issue head on, implementing the elegant Java Archive, or jar file. Jar files include compression, and support other features, such as identifying Java Bean compliant classes, nested archives, and so on. A complete discussion of the jar utility is beyond the scope of this document. Please consult the on-line documentation at JavaSoft or refer to any of the quality publications available on Java release 1.1.

We highly recommend using a professional IDE, such as IBM's VisualAge or Symantec's Cafe product to generate a dependency-based jar file for your applet or application. This will allow you to create applets that are smaller than 50k, and will ensure the minimum possible footprint for all applications.

Since we've pre-created jar files for each of the "off-the-shelf" applets, these also represent a good starting point for building delivery archives. You'll want to be aware, though, that the various applet jars contain many duplicate classes. By combining the archives to achieve the right mix for your applet combination, you can get the maximum impact with the minimum footprint.

For example, the lineApp.jar jar file is about 50k. The jar file for barApp, barApp.jar is about 60k. If you extract both archives into the same directory and combine them, you'll find that the result is not 110k, but something closer to 70k. This could be significant if your pages use both bar and line charts. Considering the way applets are used on your web pages can make a tremendous perceived performance difference for your users, especially when the jar file is cached at the browser so your users notice almost no startup time.


A Few Other Tricks

Another technique that can save significant kilobytes on an applet deployment is something called "obfuscation". By running your code (and KavaChart) through an obfuscator, you can probably reduce the size of your delivery jar by as much as 20%. Several Java obfuscators are freely available on the Internet. The potential downside of this is that debugging applications from field reports can be difficult unless your exception messages are very clear.

You can also split your jar file into several collections, based on dependency. For example, you might want to create a base.jar and a line.jar and a bar.jar. Base.jar would contain the shared classes, bar.jar would contain the classes necessary for your BarChart, and line.jar would contain classes necessary for your LineChart. The benefit of doing this is that viewers who only use LineCharts won't have to download any classes for BarCharts.


[Index] [Introduction] [Installation] [Cookbook] [Package] [Component] [Chart] [Axis] [Utility] [Applet] [Servlet] [Appndx B] [API]