United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6676453 Quality of implementation issues with update=background
JDK-6676453 : Quality of implementation issues with update=background

Details
Type:
Bug
Submit Date:
2008-03-18
Status:
Closed
Updated Date:
2011-05-13
Project Name:
JDK
Resolved Date:
2008-07-16
Component:
deploy
OS:
generic
Sub-Component:
webstart
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b23)

Related Reports
Backport:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
EVALUATION

target b22
                                     
2008-03-26



Hardware and Software, Engineered to Work Together