Ah, from the
server. That's different. By default, any applet is able to access the server it was loaded from. The easiest way to access files on the server is simply by HTTP (java.net.URL) or, if the files are in the applet jar, using getClass().getResource()/getResourceAsStream(). Writing files is most easily accomplished using an HTTP POST request to a
servlet (or PHP or CGI page or...) on the server. If the server will take PUT requests then you won't even need servlets -- but it'd be a security hole.
If you want to read or write files on the client machine that the applets is running on, you need two ingredients: (1) a signed jar using a bona fide certificate and (2) a security policy for that jar which allows reading and writing of local files. The java.sun.com thread you referred to was started by someone who'd used a self-signed certificate; that's why I started talking about that. There's another problem with applets doing local filesystem I/O though. The Sun Java plug-in, Microsoft's Java applet implementation and Netscape all use different ways of escalating a applet's privileges. It's a minefield and one of the reasons why applets never took off. If you really need to do this, consider Java Web Start which has a far better delivery and security model. But from the sound of it you don't want to do this at all.
- Peter