Setting the size of the BufferedReader will only change the size of the buffer, not the amount of data it can read. Setting this too large will cause performance problems. The default (8k) is good enough unless you want to do extensive memory profiling and
testing.
You should print the exception and its stack trace to the console. If something bad happens and it breaks something else in your code, you'd never know it. It's also a good idea to sprinkle System.out.println()'s throughout your code when debugging. Gives you an idea as to what's happening in the code. I like to put System.out.print(".") statements in my file read loops to act as a progress indicator.
Rather than concatenating String objects with +=, use a StringBuffer. That will save you numerous object creations, each of which cost processor time and system memory.
Move your close() to a finally block following your catch. If an exception were thrown, your file would never be closed. I've seen enterprise applications killed by similar code leaving database connections open. Take a look at the
Java Tutorial: Handling Exceptions for more info.
Applets operate within a limited memory space. This is to prevent malicious applets from growing so large they kill a system. You can control the size of this memory space. For the 1.5 VM, Open the Java Control Panel, click on the Java tab and click on the "view" button in Java Applet Runtime Settings. The settings are described in the
Java Tool Documentation.