JDK-6676383 : DownloadEngine doesn't support background downloading of application resources
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-17
  • Updated: 2011-12-22
  • Resolved: 2008-03-18
Related Reports
Relates :  
Description
The DownloadEngine used for both the Java Plug-In and Java Web Start, and the code which uses it, perform update checks for downloaded resources serially. Before a given resource is fetched from the cache, a conditional HTTP GET is made against the web server to see if an update is available.

These sequential update checks impact the startup time of frequently launched applications and applets.

Current applications such as Firefox, and competing frameworks to Java from other companies, allow application updates to be downloaded in the background and installed on demand. Full support for such a mechanism would require API and specification changes, which are not allowed in an update release. Therefore we aim for a more modest, incremental, solution.

The system property

  -Djnlp.backgroundDownload={true|false}

defaulting to false (the current behavior), will enable the background downloading of the application's resources.

The DownloadEngine will need to be made aware of which resources are eligible for background downloading. To avoid unexpectedly returning older cache entries to application code, we only want to enable background downloading of the application's resources (any JNLP files and the resources they point to, as well as jar files in the archive tag for old-style applets).

For old-style applets, the URLs to the jar files in the archive tag will be passed down to the DownloadEngine. Perhaps a similar mechanism to the way jar versions are passed down for old-style applets should be used; on the other hand, perhaps not. See Applet2Manager.initJarVersionMap, Applet2Manager.storeJarVersionMapInAppContext, and common deployment code referring to Config.getAppContextKeyPrefix() for how jar versions are handled. Fundamentally a Set of URLs per AppContext will need to be maintained. This seems to be simpler than how jar versioning is handled.

For Java Web Start applets and new-style JNLP applets, the JNLPs constituting the application or applet, as well as the resources they point to, should be made eligible for background download.

A daemon background download thread will need to be created by the DownloadEngine to allow the update checks to be performed in the background. For the time being, it seems best to have a singleton background thread and to keep it in the main AppContext or similar so that it does not get terminated when an applet is terminated. An alternative would be to have a per-AppContext worker thread, although this would require more bookkeeping.

Comments
EVALUATION It turns out that the new "update" element in the JNLP specification from Java SE 6 with a value of "background" sufficiently covers the use cases associated with this bug. There are some quality of implementation issues around the use of this element. Closing this bug as "Will Not Fix" and opened 6676453 to track these other issues.
18-03-2008