It's here now: https://jdk6.dev.java.net/6uNea.html !!
This release includes 64-bit Java Plug-In. Try it now!
Nope! Still broken...
Java Plug-in 1.6.0_12-ea
Using JRE version 1.6.0_12-ea Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Administrator
java.security.AccessControlException: access denied (java.io.FilePermission D:\BlueHostSite\public_html\images\LongShot4.jpg 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.File.isDirectory(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.initializeHeaders(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.getContentLength(Unknown Source)
at java.lang.Thread.run(Unknown Source)
my own mistakes. The problem I've given the stack trace for is from code I've used
for over 5 years. Never had a problem. I posted a snippet in another thread but I'll
post here again the snippet where this problem is happening.
I want you to understand that this only happens when I test my applet on my own
machine. So the HTML page, the image file and the applet jar file are all on my own
disk. I develop in Eclipse using 126.96.36.199. I haven't upped my development environment
to 6.0 yet because a lot of people are still running 1.5 and I compile for 1.5.
In the snippet below, I've pointed to the exact line where the AccessControlException
begins. I use <<<<<<<.
When the applet loads, I spawn a thread in start() to run my file fetching code. I just
download the bytes into an array and decode those bytes into an image later.
This code is only downloading the file as a byte array. And I've used this code for
over 5 years. Same code, no problems until 6u11. I would probe deeper into this
problem but that would require me to set up a 1.6 development environment and
I'm not ready to do that yet.
I strongly suggest that you look at:
and see if you are doing anything different when a local applet is reading a file
from the local disk.
The AccessControlException does not happen when I open the HTML page from
my remote website. Same jar, same image, same HTML page.
I'll have to post the snippet in a separate file since someone has limited the size
of these messages:
I'm having trouble posting the snippet. This blog keeps truncating the code so
here is the whole class file:
XXXXXX size = urlConnection.getContentLength(); <<<<<<<< here is where the exception starts
I see. This must be a consequence of one of the security-related bug fixes that went into 6u11. We will file a bug and post the bug ID here. Can you provide us a test case? Or at least tell us roughly the scenario? (i.e., is the applet signed? is it expected that the applet can read arbitrary locations on the local disk? what is the directory layout of the applet's jars, html file and the file it's trying to read?)
From memory, applets hosted on the local disk are only allowed to read directories underneath the codebase, not arbitrary directories on the disk. There might have been a vulnerability that was tightened up, and it might not be possible to provide backward-compatible behavior without reopening the vulnerability.
NOTE: Here is an applet that reproduces the AccessControlException on my Windows 2000 SP4 machine in
both FF2 and IE6 [b]if you run it locally[/b]. If you run it
from my server, both FF2 and IE6 runs without the AccessControlException.
The AccessControlException happens at:
size = urlConnection.getContentLength();
If you want to compile and run it on your machine copy:
to your own machine. All jars and images are visible to
everyone. If you can't figure out where everything goes,
ask me a question. Set up the directory structure as
NOTE: this applet started off as a demonstration for
an Out Of Memory Error so the names of the applet and jar
are confusing -- sorry. I haven't taken the time to rename it properly.
> I see. This must be a consequence of one of the
> security-related bug fixes that went into 6u11. We
> will file a bug and post the bug ID here. Can you
> provide us a test case? Or at least tell us roughly
> the scenario? (i.e., is the applet signed?
The applet is not signed. For a test case, you could use
my whole applet. The jar file is visible to anyone. I'll provide
assistance in setting up the directory (folder) structure.
> is it expected that the applet can read arbitrary locations
> on the local disk? what is the directory layout of
> the applet's jars, html file and the file it's trying
> to read?)
The html file is in the top level folder. The jar and image folders
are in the top level folder.
Looks something like:
> From memory, applets hosted on the local disk are
> only allowed to read directories underneath the
> codebase, not arbitrary directories on the disk.
I believe I reference off the document base using (from the docs):
If the spec's path component begins with a slash character
* path is treated as absolute and the spec path replaces the context path.
So for example if the HTML page is at this document base:
documentBase = file:/D:/Eclipse/eclipse/PanCyl3/bin/ImageFile.html
and the codebase was:
codebase = file:/D:/Eclipse/eclipse/PanCyl3/bin/
Then I would append "images/ImageFile.jpg" to the codebase to get an absolute
path to the image file as in:
codeBase = file:/D:/Eclipse/eclipse/PanCyl3/bin/images/ImageFile.jpg
You can look at the applet tag in the source to my web site index page to see what I do
to get a path to the images I load.
The directory (folder) that has the images is directly below the HTML page but
at the same level as the directory (folder) that has the applet jar file.
This is EXACTLY the same as on my web server and the applet works when
downloaded from my web server.
If you have changed access privilege such that "applets hosted on the local disk are
only allowed to read directories underneath the codebase" Then the top level folder
would then have to be the jar folder and the HTML pages and image files would have
to be below the jar folder and that doesn't make a lot of sense because then one would
have to do "../images/ImageFile.jpg" to get the path to the image instead of just,
I hope you haven't imposed that foolish restriction. It would be meaningless since the
jar file (codebase) can be above anything just as the HTML file (documentbase) can
be above anything. It would be a pointless restriction.
Now anything above the document base probably should be restricted access.
Remember what the difference is between document base and
code base. The code base is where the class files are --
the jar file.
And the document base is where the HTML page that contains
the applet tag is. The document base is the logical top
level folder. Not the code base.
> There might have been a vulnerability that was
> tightened up, and it might not be possible to provide
> backward-compatible behavior without reopening the
If this is the case, can you please point me to the discussion about this issue? I've
never been aware that anyone has found that having the document base as a top level
folder has caused a security issue.
If you want to use my applet as a test case I'll help you set up what you need...
Thanks for the test case. I can reproduce the regression in house. It is in fact caused by a security fix in 6u11. I have filed 6784894 to track the regression.
The problem can be worked around by moving your jar one directory up, out of the "jars" subdirectory. This will allow it to read data in directories underneath the one it is contained in.
Permissions are granted differently to applets loaded from the local disk and those loaded from the network, which is why the regression affected only applets loaded from the local disk.
Sorry about breaking your setup. We will try to address this as soon as possible.
Thanks for addressing this problem. I'm sure others will also find inability to test
their applets locally annoying to say the least.
I'm sure permissions are a real hairball to manage.
I can revert to 6u10 for now and wait for this problem to be fixed in a future release -- not
too future I hope. I have too many HTML pages that would
have to be edited to implement your suggestion but will
keep it in mind as a workaround.
Thanks again for looking into this problem and if I can contribute anything else, just
post a request...
This bug is fixed in 6u12b03!
No detectable problems.
Thank you for your prompt response to this problem.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.