Whether you worked on small-scale application or if you have developed enterprise-wide applications all of your life, at some point you've likely encountered the need to read a file. This has likely lead to your seeing the joys of the java.io package. While the package in itself is well designed and structured, it doesn’t solve a basic problem - the fact that you are dealing with a file system. As such your application's response time can be limited by the response time of the file system itself.
In the case of most local file systems that might not be a problem (though if you have a busy file system and some large reads you might start to feel it!), but it does become a problem for things like NFS or mapped drives. A lot of integrations with really old legacy systems are based on files exchanged on network paths. The hospitality industry (hotels, pubs and restaurants) in particular seems to be full of such systems that haven’t been changed since the 1980s. In such cases even though you might exchange just one kilobyte of data at a time, because you're dealing with a remote file system and in most cases a very busy one with anything from 50 to 100 such "message files" exchanged per minute and then propagated through the network, you’re occasionally looking at about 1-2 seconds for reading such a small file.
In a normal web-based application this might not be a problem because the user is used to waiting (however, even in such cases the attitude is beginning to shift!); however, it would be much nicer if instead of waiting in a InputStream.read() for the bytes to become available to your application, you were also doing something else in parallel. Sure you can turn your application execution flow around so that you only do the read at the end. In this case, the user experience suffers only in the last step - after you have offered a pretty smooth and fast experience throughout. However, this is not possible sometimes and even if it is, it doesn't eliminate the problem, but instead hides it behind the fact that most of the user actions have been responded in a timely-fashion and therefore the user will have more tolerance for such a "small" glitch at the end.
Read the Rest of this Article at Developer.com