JDK-7151950 : REGRESSION:Webstart in 7u4 b13 not downloading new content
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 7u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2012-03-07
  • Updated: 2013-09-12
  • Resolved: 2012-04-12
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.
6u43Fixed 7u4Fixed 8 b31Fixed
J2SE Version (please include all output from java -version flag):
Java Web Start
Using JRE version 1.7.0_04-ea-b13 Java HotSpot(TM) Client VM

Does this problem occur on J2SE 1.5 or 6ux?  Yes / No (pick one)


Operating System Configuration Information (be specific):

Windows 7 Ultimate 64 bit
Intel Core 2 T5600

Hardware Configuration Information (be specific):

Launching through Firefox.  No 64 bit JVMs installed.
Connecting through Tomcat 6, with clientAuth="true"

Bug Description:

Webstart doesn't download updated jar files.  In fact, it doesn't even seem to check.
Looked at the Tomcat access log, and it is not showing any connections for most of 
the jar file.  (Probably just the eager ones work.)

Have to choose the certificate from the dialog box 2 or 3 separate times. 
(It would be nice if double-clicking an item would select it and close the dialog.) 
With a clean cache directory, only need to do this once.

touched (Solaris 'touch' command) all the files in the lib/dsi directory several 
times during this test, plus uploaded changed jar files to the webserver.  
The clientC.jar (eager) gets downloaded.  The javaws logs state that the other 
jar files in the lib/dsi directory are being checked, but these calls don't 
make it to the server.

Cleaning the cache directory seems to be the only way to get new content.

Steps to Reproduce (be specific):
More information from submitter:

Looks like it happens whether or not clientAuth is on or not.  
That is good, as it will make it easier to test.

Steps to reproduce:

1.Uninstalled all Java 7 versions from the machine

2.Installed Java 7 Update 3 (from www.oracle.com/...)

3.Clicked on file looking at Tomcat access log, and could 
  see all the files being checked. (WORKING)

4.Uninstalled Java 7 Update 3

5.Installed Java 7 update 4 ! build 13
6.Clicked JNLP link in Firefox while looking at the 
  Tomcat access log, and could see that NOT all the 
  files being checked. (NOT WORKING)

Before did the above sequence, had tried a 7U4-build 9 
that is the only installer version of on machine.  
It suffered from the same problem as build 13.

Looks like this was introduced early in the update 4 release line.

EVALUATION This bug was introduced by fix to the soft references issue (CR6967414). We wanted avoid immediate update to lazy resource in case of multiple applet sharing JVM or reloading. The possible fix could be to check if webstart environment and check=always do not exclude lazy resources.