J2SE Version (please include all output from java -version flag):
 java version "1.6.0_10-ea"
 Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b12)
 Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x ? Yes / No (pick one)
  No

Operating System Configuration Information (be specific):
  Windows XP PRO SP2
  IE 7.0

Hardware Configuration Information (be specific):
  Sony VAIO laptop 2.8 Gz
  1.25 GB RAM


Bug Description:
Tested consumer JRE version of webstart and there are still big problems with
webstart. The downloads are still done incorrectly.

You will notice the critical race condition here that breaks on of the fundamental requirements of webstart...launching an application.

As it is currently, unpredictable java Errors can occur at runtime (like NoSuchMethodErrors) which should never happen. When got these Errors, it is because
webstart is running applications with different incompatible libraries. The
libaries on the server are always compatible, but the downloading of them is
not consistent and therefore old and new libraries are mixed....sometimes with
terrible results.

Restarting the application will cause the webstart cache to re-sync itself
(thank goodness for this), and the problem *invariably* goes away. To restate
this: The first time the application is started after a a library update often
does not work. The second time *always* works.

What seems to happen is this:
* Transactions are created to check the timestamps on the cached files.
* If this is not fast enough, the application will start anyway...leaving the
downloads to occur after the application has started.

This would fully explain bug 6632928 in which the certificate dialog comes up 30
times...and it is ok to cancel almost all of them. It comes up for each time it
is trying to test/downloaded a jar file. The application should be waiting for this
process to complete. However, since the application starts anyway, it can try to
run off of the older libraries that exist in the cache.

----Important design note ---------
When using certificate authentication, starting a thread to simulatiously check each
cache entry is undesireable since, if the process requires user intervention, they
will get prompted many times. (User intervention could be necessary because of
multiple certificates, or because the certificate is on a device that requires
authentication.)

Steps to Reproduce (be specific):

In your download servlet; in the JNLPDownloadServlet, change the sendRespond method
of DownloadResponse.java to sleep for 5 seconds before it starts to transfer to data.
This will simulate a high latency network. Also, make sure your test case has several
jar files. (I am not using versioned jar files and all the jar-diff stuff.)

Now, download and run the app. If this is the first time, everything will work fine,
although because of the 5 second sleep, things will take a long time to download.

Now exit the app and then touch all your jar files (by touch, I mean the unix 'touch'
to update the timestamps)

Launch the application again. It will come up immediately, which should not be the
case since it should be downloading the new jar files

Now, however, even with the application started, webstart will continue to download
the jar files. Checking the timestamps of the webstart cache entries validates the
assertion that jar files are being updated after the application has started.

**Repeat: Even after my application has started, cache entries are being updated!**

Remember that the application has started. In this test we just touched the files,
but in production, these jar files might be quite different than the ones there are
replacing. If methods are ever changed or removed, this will cause runtime Java Errors
that should never happen.

The download also seems to cause the application to suspend for a while. I don't know
if the downloads freeze the class loader for a while or something. My application
will just freeze for a few minutes (persumably during the downloading) and then
continue where it left off. Duing this time the user has no idea what is happening.