Frank Pittelli's comments, in their entirety

The important point is that Java must provide a "consistent" cache mechanism across all platforms, instead of relying on browser vendors to handle caching IN THEIR OWN WAYS. "The JAR format, which batches an app's class files and compresses the resulting file, will help in this regard. However, if the integration of the JAR file and the class loader is not done consistently across platforms and with practical issues in mind, it may not provide the great benefits that everyone expects.

For example, consider Netscape's current "archive" solution, where class files can be placed in an UN-COMPRESSED ZIP file and downloaded all at one time. Although this approach seems beneficial at first look, it doesn't provide much benefit in some common real-world situations. In order to use the archive file, the developer is forced to include all classes that MAY be needed by the user during the execution of an applet. Given that most applets have more features than the user commonly uses during a given session, this means that a larger number of classes will be loaded initially than are actually needed. And since compression is not supported, the resulting download time may actually increase, even if only one web connection is needed. In actual tests over a 28.8 modem Internet connection with a commercial charting Java package, it took 192 seconds to download the 30+ class files (totalling 150K) needed to render a standard bar chart. When the package was archived using Netscape's approach, the resulting 400K archive file took 174 seconds to download. That is, only a 10% savings was achieved because compression wasn't allowed and the chart vendor was required to batch all classes, not just the ones actually needed.

Even with 4-to-1 compression, the archive file would still take almost a minute to download initially. And, here again, Netscape's current archive support has the browser download an archive the first time it is referenced during a session, even though their very own class caching mechanism caches individual class files across browser sessions.

Although it can be argued that this is a problem with the Netscape's approach, the marketplace simply doesn't distinquish between a Java problem and a Netscape problem, it is all perceived as a Java problem. The JARS approach, if properly integrated with the JVM's standard class loader, should eliminate many of these problems, but nothing is certain without paying attention to the details.

Over the last year, the downloading and distribution of Java class files has continued to be a major problem for developers of mission-critical applications.

So for Java to broaden its potential market into the mainstream while maintaining its commitment to the Internet as a delivery vehicle, it must take big strides to improve network download performance across all platforms, both inside and outside of commercial browsers. More importantly, it must allow developers, users and other technologies to control cache operations to satisfy their specific needs.

I advocate the creation of a Version-Controlled Cache within the JVM specification, that allows users, developers, and administrators to tailor class caching for their own needs, ACROSS ALL VENDOR IMPLEMENTATIONS. Unlike the current caching schemes deployed by each of the browser vendors, the Java cache would be standard across all platforms and, because of the open specification, would allow utilities and other approaches to be developed to help maintain and distribute large number of classes throughout an Internet or Intranet user population.

For example, if the JVM supported a consistent caching mechanism, then that cache could be used by users across all of the Java applets and applications that they run, even if they use different browsers and/or appletviewers from one day to the next. That is, the JVM for each of those appletviewers would simply be told to use the same cache, greatly reducing redundant storage when users make use of multiple viewers (an increasing problem, now that almost every software vendor has announced support for viewing applets.)

Similarly, a universal cache specification would allow vendors in the "push" world to build products that targeted the Java cache on any platform as the recipient of periodic class updates. Such updates could be performed during off hours, supplying subscribers with up-to-date class files as they are developed. In this case, the user would only suffer a download delay in the rare case when they reference a newly updated class before the periodic refresh is performed.

By adding a simple version number to each class, the cache approach can be further expanded to allow developers to properly control the distribution of products and applications to large user populations. Version tags could be used by developers to make sure that all of the classes being used within an application are suitable to operate with each other. Currently, caching schemes rely solely on the size or modification timestamp, and developers rely on class-loader exceptions to detect problems. It would be much better to have off-line utilities that could analyze the contents of the cache during off-hours and determine when a consistent set of classes are properly loaded.

That capability could also form the basis of the "pay as you go" software marketing approaches that have received a lot of attention recently. The ClassLoader, with all of it's built in security mechanisms, could be relied upon, by software vendors, to invalidate cache copies when they have expired. Then, when the class is loaded across the network, the user could be charged accordingly. On the other hand, users may specify that they don't want the latest versions and simply "pin" the current versions in the cache. In that way, the user can control their own downloading activities, if they want to.

Finally, a separate and consistent Java class cache would allow users to easily distinquish between the amount of disk space to be used for the applets that run their business and the HTML documents and images gathered as the result of Web surfing. Somehow, it just doesn't seem right to have mission-critical Java applets competing for cache space with the latest "gee-wiz" advertising GIF images from your favorite Web site. Sure, we might be able to download things quickly, but why should users keep waiting for the same applet that was downloaded yesterday and will be downloaded tomorrow.

None of these features prevent Java from delivering classes on-demand, as it has always done, but they do allow users, developers and administrators to control class "distribution" using the same basic mechanisms.

By solving the basic distribution problem that has plagued software vendors and developers for over 20 years, many of the network downloading problems currently being discussed will be easily managed. For every class file that changes, the goal should be to have at most one download, performed by any user that needs that class and if that download is performed during off-hours, the user need never see the network delay regardless of how optimized it is.

Performance is a "system" discipline and Java designers should be providing solutions that span the entire system, not just some aspect. Yes, we need compression, archiving, data pushes, etc., but we also need to let users, developers and administrators control when, where and how often classes are loaded in the first place.

Back to JavaSoft Forum 1.2