United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6863499 Webstart JAR updates are completely broken in 6u14
JDK-6863499 : Webstart JAR updates are completely broken in 6u14

Details
Type:
Bug
Submit Date:
2009-07-23
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2009-12-08
Component:
deploy
OS:
generic,windows_xp
Sub-Component:
webstart
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u14,6u18
Fixed Versions:
6u18 (b04)

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Also reproduced on Ubuntu Linux 9.04 Jaunty

A DESCRIPTION OF THE PROBLEM :
Webstart application installation works but JARs updated on the server are not downloaded (ignored completely).

My Webstart application's JNLP uses the following update settings:
<update check="always" policy="always"/>

This means that all resources should always be checked before the application starts and if a JAR is updated on the server (it has a newer timestamp), the JAR should be downloaded and placed in the cache.

Currently, in JRE 6u14, this seems to be completely broken. Webstart doesn't notice the updated JAR on the server and it doesn't download it.

As a check, I installed JRE 6u11 into an other Windows machine and tested the behaviour from the same Webstart web server.

JRE 6u11 works as expected. If I update the JAR on the web server and restart the application, Webstart immediately notices the new JAR and downloads it. This proves that there is no timestamp problem on the web server.

I checked the timestamps on the web server manually and they are correct. The webstart client and the server practically doesn't have any time difference (both are attached to internet time servers).




STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Any webstart application should be possible to use for reproduction:

- Make sure the JNLP has proper update settings (always)
- Install the webstart app, close it
- Update one of the JARs on the server, check that the timestamp is newer
- Start the previously installed webstart app

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Webstart should download the updated JAR
ACTUAL -
No download happens, Webstart starts the application with the OLD JAR

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
No workaround, practically makes Webstart unusable.

I have no idea how this bug made it to u14, there should be an automatic test case for this.

Please, fix this bug because all of the already installed Webstart applications are now frozen, it is impossible to update them on the client (if the user installs u14 but this can happen easily with JRE updates).

We have a lot of clients using our Webstart applications and some of them installed JRE 6u14 (a growing number).

Release Regression From : 6u11
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

                                    

Comments
EVALUATION

The main app jnlp update check does not get the result of extention checks. This affects both plugin2 and java webstart.
                                     
2009-09-29



Hardware and Software, Engineered to Work Together