« Re: Gender bias in the tech recession? | Main | Adventures in browser-land »

Java I/O.. yah, it sucks

To quote from an eloquent entry:

I've said it before, and I'll say it 'till I loose my voice: I fucking hate Java I/O. All I want to do is get all the contents of whatever's in a stream, a reader, buffer, or whatever the hell else I have a handle on. Can I just call something like the below:

String contents = new File("somefile.txt").getAllMyShit();

Of course the fuck not! I have to keep track of byte arrays, char arrays, or some stupid ass shit in a while block. I just want the God damned content, I don't care how the JDK gets it out of there.

I always thought there should be a method on StringBuffer, perhaps called loadFromFile(), that takes a File object.

TrackBack

Listed below are links to weblogs that reference Java I/O.. yah, it sucks:

» Java Bashing from Jeremy Zawodny's blog
Everyone enjoys a good language bashing now and then--especially when it's a shining example of how the language makes it hard to do something amazingly simple, like reading a file.... [Read More]

Comments

You Java programmers sure have an odd definition of "eloquent", but it kinda goes with your definition of "elegant" :-)

ya think it'd be easy enough to write a method....

Yeah, in Ruby I can do this:

lines = IO.getlines("foo.txt")

to load up an array of strings, one per line. Or if I want the entire file as one big string, I can do this:

lines = IO.getlines("foo.txt").to_s

something like that would be nice to have in Java.

Steve, You should see our definition of 'humour deprived' :)

obviously other people have wanted the same thing:

http://jbind.sourceforge.net/api/org/jbind/util/other/Copy.html

actually there are a bunch of implementations.
unfortunately, they aren't part of the jdk.

http://search.yahoo.com/bin/search?p=java+inputstream+copy

if you think reading files is bad, try trying to get an integer out of a hashmap (supposing you had cached some database ids, for example):

int myId = ((Integer)cacheMap.get(myName)).intValue();

as opposed to something halfway reasonable like, oh,

myID = cacheMap[myName]

... but that would be far too sensible

It isn't too hard to write some convenience methods that will make JAVA IO behave as you would like, add in a magic mime facility, and some factory methods, decide how you want to handle blocking ...... and then you won't have to care anymore about JAVA IO.

Sam:

I agree with you, but why isn't that part of the libraries bundled with Java (wahtever the correct term is)? I mean it seems like something you'd want to use frequently. What sort of process do they use to decide what goes in and what doesn't?

Sam, yes, it's easy to write your own method, in fact I already have in the past projects.. but the point is this is something used widely and often.. Should be part of Java libraries.

errr.. what about php's "file" command

www.php.net/file


$my_file_array=file("somebigfile.txt");

$first-line-of-file=$my_file_array[0];

print $first-line-of-file;


simple. easy. fast.

Sounds crazy, but maybe there's a way to drop out of Java and use PHP , then drop back into Java for this sorta stuff?

Java isn't built or designed for simple stuff - it specifically designed for HUGE , scalable, multi-tier enterprise systems.

If you want file-input-output just use Perl or PHP.

thats my take on it anyway.

well, there's always

try
{
BufferedReader reader = new BufferedReader(new FileReader("myfile.txt");
StringBuffer b = new StringBuffer();
String line;
while ((line = reader.readLine()) != null) {
b.append(line);
}
} catch (IOException ie)
{

}

even if that does drop the line endings or whatever...

Joe, Kasia

the reason for this is flexibilty

although it may appear that parsing text is common to you
it really isn't, and to build a generic I/O API based on such a premise is bad design ( sorry guys ).

could be worse