Okay,
Please allow me to "defend" my implementations.
closeQuietlyActually I think that is are pretty handy function. After all the proper handling of a input stream looks like this:
Code:
InputStream in = null;
try {
in = new ...
/* R/W operations */
} catch (...) {
/* Error handling */
} finally {
if (in != null) {
try {
in.close();
} catch (IOException e) {
// nothing
}
}
}
That is the only way to make sure that the created input stream is closed properly. And this always has to be done on the same level where the input stream is created or requested. (excluding methods that clearly create a new input stream to return it). This source code looks pretty bloated, while its correct and required. This was the reason I created this closeQuietly function.
Code:
InputStream in = null;
try {
in = new ...
/* R/W operations */
} catch (...) {
/* Error handling */
} finally {
IOUtils.closeQuietly(in);
}
Looks better, doesn't it?
This function is not really "needed" or required or anything... but it makes the code easier to read and lowers the inhibition threshold for developers to write the clean code for handling input streams I think. I don't know how it is for you but I always have to force myself to write that block of code I wrote up there. So I think this method makes it easier.
Method overloading... okay that was a little over the top maybe
But many of the methods are actually used, because they use each other and only the copyLarge functions really transfer the data between the Reader/Writer or the Streams. So most of the functions become "natural" a part of the implementation plainly by following the call structure. After all I guess the most often used "entry" call for the toString() method will the toString(CharSequence[, String]) as it uses Slick ResourceLoader to fetch the resources.
Also the optional "charsetName" parameter I consider as extremely valuable. Some application don't have to care for the charset because the data load contains only characters from the lower 128 characters that are shared between all commonly used charsets. But some (such as myself) require the ability to load data that are charset sensitive. For example the german umlaute (ä, ö, ü).
Surely the amount of implementation can be trimmed down a little. But not to like 2 methods.
For the readLine methods. Yes they are slower. But I think they have the better design. But a faster method something like a "Iterator" like implementation that scrolls over the buffered data from the file would be needed. Could be done, but I need to do more tests to get something like this working in a fast way. And this was a little too much for a first implementation.
For the StringBuilderWriter... that is a class that is only used by the IOUtils. And its in the same package. If you don't want to expose it to the user... just make it package local.
Nitram
Edit: Don't trim my documentation!! Its awesome!
Login
Register
FAQ
Search
Nitram if it is okay, we trim the class a bit to the needs (if we can settle on the ones we need) and then add it 
