My Applet hits a snag when it tries to find a file. But the same code works in the Eclipse environment. This is from a class called PollPanel which is an extension of a JPanel.
Here is a code fragment:
It took a bit of trouble-shooting to get it down to this point, where I am pretty sure the offending line is when I try to instantiate a new Scanner. I went through the process of adding code line by line and testing. Instantiating polltxt causes no problems.
In Eclipse, the file "polldata.txt" is sitting in the project file folder, and the Applet is able to instantiate the Scanner. An Application version that calls the same code uses the File address "polldata.txt" and successfully connects with exactly the same file. I use the two different addresses because the base address of the Applet includes a "/bin" subdirectory.
Testing the code outside of Eclipse, in a mockup of my website, the Application version JAR works fine, but the Applet version does not. Or rather, the Applet version runs until it reaches this point in the code and then does not execute any code following this point. Since the website mockup directory is on my C: drive and both JARs are addressing the same file (to the best of my knowledge), I know this shouldn't be a permissions issue. I am at a loss as how to troubleshoot this further. I can't use the Eclipse debugger because the program works perfectly well in that context.
Almost forgot to show the structure of the website! The file folder "/HowWide" contains:
HowWide.JAR (the applet)
HowWideApp.JAR (the application version)
I have considered tapping into the "polldata.txt" file as a Resource, and AM able to read this file as such in both the Application and Applet forms. It certainly seems safer to have the polldata.txt embedded in the JAR (not that we are terribly concerned about the file being hacked--it's a casual project). But I don't know how to write to a Resource, and suspect that writing to a Resource is not a commonly accepted practice. Yes/no? Maybe we don't do this as the amount of memory for the file is fixed within the JAR structure? Or because a new JAR will overwrite existing resource data? This is new territory for me.
Is the notion of reading/writing to a text file with a relative address simply not a good idea for Applets? Or am I overlooking how to do this? I could definitely use the insights of a more experienced programmer.
Actually, it is a permission issue. Applets can't use the File class and related I/O streams and readers/writers due to the security sandbox in which they operate. There are ways around that (mainly signing the applet); see HowCanAnAppletReadFilesOnTheLocalFileSystem for details. It seems that Eclipse does not set up a proper applet environment that enforces the sandbox rules.
The resource mechanism only works for reading, not for writing, so the basic options are a) sign the applet (if you want to store data on the client machine), or b) have the applet access an active server resource -like a servlet- (if you want to store data on the server).
posted 9 years ago
Drag. But thanks for the quick response and information. You have saved me a lot of grief.
I saw the article you listed for Client side reading/writing. In this case, though, I need server-side persistence, as we want to tally votes from the clients.