Discussions with ###@###.### and ###@###.### indicate that the "update" element in the JNLP specification from Java SE 6 covers the use case described in 6676383, where it is desirable to allow update checks for the application's resources to be done in the background to improve startup time.

There are some quality of implementation issues with this code:

 - Currently the background update check will simply cause the cache entry for the resource to be invalidated on a background thread. We want the download to occur in a background thread as well, so that the next time the app is started, the new version of the resource will be ready to go.

 - To avoid having some of the app's resources be updated and not others, we want a notion of atomicity along with the background updates. The update checks for the various resources should be enqueued from the application's main thread. After all of the resource updates have been enqueued, a request to "complete" the update should be enqueued. This should cause all of the cache entries associated with this application to be cut over from the old version to the new version.

There may be another issue:

 - The "update" element is specified per-JNLP file. If for example the root JNLP specifies it, and it pulls in an extension JNLP which does not, then the root JNLP's specification should take effect. In other words, during descent into the JNLP tree, the parent's value should take effect if the child JNLP didn't specify it explicitly. This might already be the case but verification is needed. The use case here is an extension JNLP that wants to enable background updates even if the top-level JNLP didn't request them.