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.

from customers feedback: ( ###@###.###)
> 2. If my app is already running when Java Web Start tries to download a
> newer version, the newer version gets "lost". Specifically, this happens
> when there is a new version of the app available. The first time I click on
> the JNLP link, it tells me that Java Web Start will download the new version
> the next time. If I click on this link again before closing the first one,
> it downloads the new app, but won't start it. If I then close the app and
> click on it again, Java Web Start thinks it has the latest version, but
> actually runs the older version. Much of this could be avoided if you
> implemented the change I suggested earlier to give the user the option to
> download the new version immediately rather than waiting for the next time.
>
If we try to write to a file that is open, the write will fail.
We should verify that the applications files are writable before atempting to
download a new version.
Name: nt126004 Date: 11/06/2001
java version "1.3.1-rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc1-b21)
Java HotSpot(TM) Client VM (build 1.3.1-rc1-b21, mixed mode)
I have realized that when an application update is available and you have the
same application runnig, updating fails.
JavaWebStart trys to overwrite the jar files but the OS doesn't allow this
operation because the file is in usage.
However the next time you click on the jnlp link JavaWebStart doesn't detect
the new version. I think JWS has yet written the new version control on the
client although it hasn't been update correctly.
To reproduce:
1. Start an application via a jnlp link.
2. Update the jar file.
3. Start the application again via the link (original instance still running).
4. You get the exception:
JNLPException[category: Download Error : Exception: java.io.IOException: rename
failed in cache : LaunchDesc: null ]
at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
at com.sun.javaws.Launcher.downloadResources(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
5. Quit the application and start it again from the link. No download is performed, but
you get the old version!
(Review ID: 135107)
======================================================================

EVALUATION
I have been investigating bug #4393792: Downloading new version of running
app fails, and I have come to the conculsion that it is just not true.
1.) All of the paths thru DiskCache.java, except for deleteEntry throw up
an IOException (which is later wrapped as a JNLPException) if the operation
is not a success. In particular, insertEntry() which does the actual
rename of the temp file to the correct cache file name, explicitly throws
such an exception if the rename fails.
2.) I ran a simple test on NT (renaming t1.jar and t2.jar to T.jar and
running both) which clearly shows jar files are not left open simply because
they are "running" (java opens, reads, and closes them as expected). This
may not be the case for native library dlls in jar files, but certainly
is for classes.
3.) If any SecurityException, JNLPException, or IOException is thrown whil
downloading or installing, LaunchErrorDialog.show() will be called. this
does a System.exit(-1) so we could never get to the code that Resets
force update, and, as the description of this bug says:
"If I then close the app and click on it again, Java Web Start thinks it
has the latest version, but actually runs the older version."
andy.herrick@East 2001-03-04
Since noone has yet been able to provide example of how to reproduce, I am
downgrading this to P4 - if example is provided will upgrade and escallate.
andy.herrick@East 2001-03-09
New cache reorg in 1.2 should allow you to dowwnload running app.
andy.herrick@East 2001-07-13

2001-03-09

WORK AROUND
Use the version-based download
rene.schmidt@eng 2000-11-30