FULL PRODUCT VERSION :
Java Plug-in 1.6.0_10

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
If an unsigned applet loads a JAR file using a URL connection, it succeeds the first time and places the file in the cache.  Subsequent loads fail with AccessControlException trying to read the file from the cache.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the applet below and place the class file on a web server

2. Place the HTML file in the same directory on the web server:

3. Put a file into the folder with the name test.jar

4. Visit the applet on that server from IE or Firefox, view the Java Console

5. Close the browser

6. Open the browser, and visit the applet again, view the Java Console



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Step 4 will print a message to the console showing that it was able to read the .JAR
Step 6 SHOULD print the same message
ACTUAL -
Step 6 throws the exception



ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\User\Application Data\Sun\Java\Deployment\cache\6.0\41\709d85a9-4c3f90f4.idx read)
	at java.security.AccessControlContext.checkPermission(Unknown Source)
	at java.security.AccessController.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkRead(Unknown Source)
	at java.io.RandomAccessFile.<init>(Unknown Source)
	at com.sun.deploy.util.SyncFileAccess.openLockFileObject(Unknown Source)
	at com.sun.deploy.util.SyncFileAccess.openLockRandomAccessFile(Unknown Source)
	at com.sun.deploy.cache.CacheEntry.openLockIndexFile(Unknown Source)
	at com.sun.deploy.cache.CacheEntry.readManifest(Unknown Source)
	at com.sun.deploy.cache.Cache.getCacheEntry(Unknown Source)
	at com.sun.deploy.cache.Cache.getCacheEntry(Unknown Source)
	at com.sun.deploy.cache.Cache.getCacheEntry(Unknown Source)
	at com.sun.deploy.net.DownloadEngine.isUpdateAvailable(Unknown Source)
	at com.sun.deploy.cache.DeployCacheHandler.get(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at TestCacheApplet.start(TestCacheApplet.java:29)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
--TestCacheApplet.java--

import java.applet.*;
import java.net.*;
import java.io.*;

public class TestCacheApplet extends Applet
{
    public void start()
    {
        System.out.println("Reading...");
        try {
            URL u = new URL(getCodeBase(), "test.jar");
            //
            // Workaround #1: Do not use .jar extension...
            //
            // URL u = new URL(getCodeBase(), "test.jxr");
            //
            // Not  customer  because many web servers will not serve up
            // files with unknown extensions, and many users cannot
            // influence the configuration of corporate web servers.
            //
            URLConnection uconn = u.openConnection();
            //
            // Workaround #2: Disable caching
            //
            // uconn.setUseCaches(false);
            //
            // Not  customer  because caching is very useful!
            //
            InputStream istr = uconn.getInputStream();
            ByteArrayOutputStream ostr = new ByteArrayOutputStream();
            istr = new BufferedInputStream(istr, 16 * 1024);
            byte [] b = new byte[1024];
            int read;
            for(;;)
            {
                read = istr.read(b,0,1024);
                if (read == -1)
                    break;
                ostr.write(b, 0, read);
            }
            istr.close();
            System.out.println("Read "+ostr.toByteArray().length+" bytes");
        } catch (Exception ex) {
            System.out.println("Failed...");
            ex.printStackTrace();
        }
    }
}


--index.html--
<html><head></head><body><applet code='TestCacheApplet' width=1 height=1></applet></body></html>


---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
1. Use a different extension.  This bug seems peculiar to .JAR files

2. Disable caching in the code, as shown above

3. Disable caching in the Java Control Panel
Posted Date : 2008-12-16 02:10:30.0

N/A

Original problem should not be reproducible after fix for 6791250 as we 
do not use readManifest directly from the Cache.

However, there are some public methods in the CacheEntry, such as getManifest(), etc.
that may try to read files on disk again in non-priveledged mode. We should wrap all public calls that may lead to disk access with priveledged action.
Also, some of package private methods of CacheEntry better to be private to avoid
introduction of direct requests in the future.
Posted Date : 2009-02-17 14:30:53.0

Yes, I worked with the 3D Kaon software and we have been working on this bug for many months. The work-around is a temp. fix. Thanks!

I'm pleased that you are acknowledging this bug, but I'm puzzled why the priority is "Low".  It impacts thousands of applets deployed on hundreds of web sites, including Sun.com (the 3D models of Sun's servers use an applet which malfunctions because of this regression).  This is the first time a Sun Java update has caused such as fatal regression with our deployed applets.  We've made a workaround version of the applet available, but it is not realistic to expect all the web sites in the world to update their applets.  I plead for you to give fixing this bug priority for the next update.

We have an application serving 1000 users that doesn't work in the new jres because of this issue -- please vote for it