Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6676383

DownloadEngine doesn't support background downloading of application resources

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Won't Fix
    • Affects Version/s: 6u10
    • Fix Version/s: 6u10
    • Component/s: deploy
    • Labels:
      None
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              hdongorcl Hao Dong (Inactive)
              Reporter:
              kbr Kenneth Russell (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: