Question

I went into this understanding this would not work, but I am trying to find out why it does not work, and possibly a way to fix it.

Anyway, I tried using java.io.File objects in an applet, and as soon as I did, it gets an error… Anyyway, based purely on speculation I believe this problem exists (at least partially) because there are two filesystems everytime the Applet is run and the virtual machine cannot choose between the local computer’s filesystem and the servers… I also believe (based on the fact that my java got an error whenever I tried to import java.io.* that another contributor to the problem is that I am importing this thing. If I defined ‘File’ within the applet, and somehow specified the filesystem to use for the JVM, would that fix either or both of my problems? And if yes to either, how wouldI go about doing that?

Answer 1

Java applets run in a "sandbox" – they don’t get access to the local filesystem (unless you sign them and jump through some hoops)

Since applets execute on the "client" they don’t get confused between server and client filesystems – the server filesystem is completely inaccessible (other than as intermediated by some protocol such as FTP or HTTP).

Oracle say

If you tried to run the applet example, you undoubtedly saw errors when you clicked the Click Me button. This is because the Java 2 Platform security does not permit an applet to write to and read from files without explicit permission.

An applet has no access to local system resources unless it is specifically granted the access.

---

Update: Some clarification of the concepts:

A "java ftp applet" is a Java applet that is some Java bytecode stored in a .jar file on a server where it can be served by a web-server like Apache or IIS to web-browsers like Internet Explorer, FireFox, Chrome, Safari etc.

The usage goes like this

• A web-browser on a personal computer loads a web page from a server using HTTP.
  • it sends an HTTP request
  • it receives an HTML response
• As it parses and displays the HTML "page", the browser finds in it tags that refer to an applet
• The web-browser uses HTTP to request from the server, the jar file for the applet.
• The web-server returns a copy of the contents of the jar file.
• The browser launches a Java Virtual Machine (JVM)
• The browser hands the applet jar file contents to the JVM
• The JVM on the personal computer (Not the server) runs the applet
• The browser displays the applet and passes mouse clicks and keypresses back to the JVM.
• The applet sends an FTP connect request to a server that runs an FTP daemon/service
• The server responds.
• The applet sends an FTP request for a file.
• The server sends an FTP response containing the file.
• The applet does something useful with that file.

The applet is running in a personal computer, it is only allowed access to files on that computer if the applet is signed and is granted permission by that personal computer.

If the personal computer separately was using a file-sharing protocol (e.g. NFS or SMB) that makes some directories on the server look like local directories on the personal computer (e.g. a drive mapping) – then local applications (such as a signed applet) might be allowed access to those files using regular ordinary plain file IO. This is probably not the case.

The applet never has direct access to files on the server.

The applet may communicate with services on the server by using network protocols (not regular file IO) Some of those services (such as HTTP and FTP based services) may allow the transfer of copies of the contents of files on the server.