As the number of bridge-based components grows it will become increasingly impractical to download the entire set of jars are startup. As of 021228, there are roughly 3 Mb of jars that must be loaded on initial installation.

The JNLP API provides the basic tools for deferred loading of jars in the DownloadService interface and related classes. Minimally, a mechanism could be added to bridge that would support mapping of data classes to jar files. When an ObjectID is encountered, the existing mechanism for finding a ComponentView (prior to pulling the object across the net) could be augmented to check for the presence of the necessary jar files.

Issues include:
  1. ComponentViews are currently used to provide icons for objects, meaning that the CVs must be loaded simply to show icons. Solutions include:
    • Moving icon lookup out of the CV interface. In practice, all existing CVs use the default static icon-lookup implementation.
    • Reverting to an "unloaded" icon for CVs whose jar files are not yet loaded. This is likely be to at least as complex as simply moving icon lookup out of the CV interface.
  2. Version management. To facilitate agressive caching behind firewalls, we currently name jars to indicate the date on which the jar was created. Prefixes are preserved, so a solution to this could be:
    • Send (data class, jar prefix) pairs to the client
    • Send list of full jar names (as jnlp property?)
    • Match prefix to full jar names, check with DownloadService.isPartCached

An initial version of lazy jar loading support was added 021229, implemented primarily in bridge.apps.jnlp.JarLoader. It appears that WebStart begins downloading lazy jars in the background after startup, so actual forced loading is difficult to test. Icon lookup has not yet been changed.

/public/projects/bridge/design/Lazy jar loading Login | Web Editor | Full Editor
Last modified 9/11/03 1:34 PM by isenhour (history)
Site contents