JDK-6863499 : Webstart JAR updates are completely broken in 6u14
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u14,6u18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2009-07-23
  • Updated: 2011-02-16
  • Resolved: 2009-12-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u18 b04Fixed 7Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
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.
29-09-2009