Bug ID: JDK-6518576 Graphic icons can NOT be displayed while Java Web Start launch an application with JDK 1.6

Versions (Unresolved/Resolved/Fixed)

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
6u2Fixed	7 b13Fixed

Sun Device Detection Tool(Compiled by jdk1.4.2) is an Java Web Start applicantion developed by HCTS team. We tested
the it with JRE1.4.2 and JRE1.5, and it works well. 

When we tested it with JRE1.6, the graphic icons on the GUI disappeared
often time (not every time). In other words, all image icon on the GUI
including the button which contains a image icon disappeared. This
problem raised on all of S10, SNV55, Fedora Core 5, and Windows XP
platforms.

Averagely starting it 10 ~ 15 times, the problem will occur once. For a
few systems, it might raise more often.

When we disabled the option of "Keep temporary files on my computer" in
Java Control Panel -> Temporary Internet Files Settings, this problem
didn't occur again even running more than 50 times. It seems a *Work
Around* of this problem. 

All source code and icons pictures (a few JPG and GIF files) are
complied into a single jar file. In the source code, there are a few
icons added into the GUI with the following code:
----------------------
 ImageIcon icon1 = new
        ImageIcon(this.class.getResource("icons/pic1.jpg"));
 ImageIcon icon2 = new
        ImageIcon(this.class.getResource("icons/pic2.jpg"));
 ... ...
 ImageIcon starticon = new
        ImageIcon(this.class.getResource("icons/StartButton.jpg"));
 this.StartButton = new JButton(starticon);
 ... ...
----------------------

We also tried using ClassLoader instance to replace
this.class.getResource as follows:
----------------------
ClassLoader cl = this.getClass().getClassLoader();
ImageIcon icon1 = new ImageIcon(cl.getResource("icons/pic1.jpg"));
... ...
----------------------
However, the problem raised as well.

SUGGESTED FIX 1. When we need to update the cache index file for the new expiration date, instead of always writing out the full index file, we should just update the expiration date field. This will significantly reduces the amount of time needed to update the index file, and hence reduce the collision chances. 2. If we are running with Java 1.4 or above, use the NIO FileChannel API to lock the file before reading/writing. http://web-east.east/deployment/www/webrevs/ngthomas/6518576/6u2/webrev/

02-02-2007

EVALUATION This is a bug in the Java Web Start code in JDK 6. Problem is two > different threads is trying to read/write the cache idx file, causing > the StreamCorruptedExpcetion sometimes. > > In JDK 6 Java Web Start, when we do a update check on the jnlp > application resource, if the server return a new expiration date header, > we will update the corresponding cache index file with the new > expiration date value. > > We do the update check in a separate thread. By default, if the update > check does not complete in 1.5 seconds, we will continue and just run > from cache, and let the update check continue in another thread. > > When the bug happens, the update check did not complete in 1.5s, so it > keep running in the update check thread. While the main thread continue > to run, it will need to read the JAR manifests in the cache index file. > So it happens that during the reading of the manifests, the update check > thread complete and found a new expiration date, and write that to the > cache index. Therefore the stream got corrutped when the main thread is > reading the manifests from the index. > > In the meantime, if you need to use JDK 6, you can try adding this to > the jnlp file: > > <update check="always"/> > (update element is a new sub-element of the jnlp element in JDK 6) > > This will force the update check to complete before the application can > be started, which can workaround this problem. But the application > might take longer to start, depending on the server availability. > > Or you can use a webserver that does not return the expiration date > value upon a if-modified-since GET request.

31-01-2007