Keith Devens .com

Java I/O

Since Java IO is such a pain in the ass, and I never remember how to read and write files (not even the experts can), I'm going to post sample code for future reference here.

Also see Sun's tutorial on Java I/O.

Ack! You can't do a .putback() on a BufferedInputStream, even though it's buffered! What the hell. I still say that C++ is often easier than Java.

Ok, I really, really hate Java. All of my other driver programs worked just fine, but I had to make a special case for the special child that is Java because when I passed it the absolute path name of the driver program, it considered the full path a class name and then complained it couldn't find the class. Hello?? Freaking slashes (/) aren't allowed in class names anyway! Get a clue.

Anyway, here's the driver program I promised:

import [MY SECRET CLASS]

import java.io.*;



public class driver{

    public static void main (String args[]){

        if(args.length < 2){

            System.out.println("Usage: driver input_file output_file\n");

        }else{

            Object o = null;

            X x = new X(); // my secret class

            try{

                FileInputStream fin = new FileInputStream(args[0]);

                o = x.load(fin);

                fin.close();

            }catch (IOException e){

                System.err.println ("Something borked reading the file");

                System.exit(1);

            }

            try{

                FileOutputStream fout = new FileOutputStream(args[1]);

                fout.write(x.dump(o).getBytes());

                fout.close();        

            }catch (IOException e){

                System.err.println ("Something borked writing the file");

                System.exit(1);

            }

        }

    }    

}

What's also super annoying is that Java has separate but pretty much symmetrical I/O class hierarchies that are different only because one deals with bytes and one deals with characters. I know with Unicode characters aren't necessarily bytes anymore, but it seems like there must have been a better way to handle that.

If you had an input stream and were able to specify that you should open it in character mode, Java should be able to filter that just like it can do with the character-based I/O classes. I don't see why they needed a whole separate class hierarchy to do that. I'd want to give the designers the benefit of the doubt on this one, but Java has traditionally been riddled with so many poor design decisions that this is probably just more of the same.

Lastly, I'm finding that Java has a much higher cognitive load than any other language I know of, including C++. If they had allowed operator overloading it would have made things easier. str.charAt(n) instead of str[n]? str.equals(foo) instead of str == foo? Give me a break.

Permalink | 9 Comments | Tags: Programming | id 4150

12:53 (utc-4)
edited: 2003-08-04 08:45 (utc-4)

Comments

Got to admit, the IO stuff is a pain in the arse, however I would take issue were you state "...Java has traditionally been riddled with so many poor design decisions that this is probably just more of the same." Apart from the IO and Calendar API's I'm strugling to think of a dodgy area in the API's, and I know Java VERY well.
Much of the problem areas with IO came from historic reasons. Java was originally developed to work on embeded systems, and as such the original IO was kind of a lowest common demoninator (many such systems didn't provide much in the way of high-end io features). This old code was left in so as to preserve backwards compatibility. The nio package in Java 1.4 aims to aleviate this by finally providing some decent high-end (and bloody fast) IO classes, and much of the old IO stuff has now been reversed engineered to use the nio classes. This work will be continued in the Tiger 1.5 release as part of JSR 203 (http://jcp.org/en/jsr/detail?id=203)

The nio package in Java 1.4 aims to aleviate this by finally providing some decent high-end (and bloody fast) IO classes, and much of the old IO stuff has now been reversed engineered to use the nio classes.

Wow! Java's getting decent IO? I had no clue. Here's a link for my future reference.

As for dodgy areas in the libraries, IO is a pretty big one. Apart from that, I tend to see notes all the time that say "This method is deprecated because it didn't work right. Use this instead." "Don't use Vector anymore... use ArrayList instead". So, I think the container classes were another big case where they got things wrong.

I've come across other examples of people complaining about design mistakes in the API, but off the top of my head I don't remember what they were complaining about or where I can find links to what they were saying. One thing I just remembered is Tim Bray's discussion of Java's string handling. In general, I don't get the impression that Java has a particularly clean or well-thought-out design. Then there are other parts of Java outside of the main libraries. I'm not sure, but haven't they replaced their component model a few times? And, using JSP 1.0 was a horror (though it could have been 1.1, I don't remember).

Of course, I wouldn't consider myself a Java expert, so I may not have a large enough perspective. It's possible that the majority of the API that I never use is extremely well designed, but the parts I've had contact have always underwhelmed me. But then again, Java in general underwhelms me

Thanks for the note about NIO. Now you've got me interested.

One more thing... another part of Java that has always given me problems is classpath wrangling. I think it's gotten better in recent versions, but messing with Java configuration has for whatever reason almost always been a headache for me.

And then note the main thing I was complaining about in this post, that I wasn't able to do something as simple as run a Java program by giving =java= an absolute path name. I have a bad impression of Java's design because problems like that always seem to bite me in Java, whereas they're never an issue in other languages.

The thing with deprecated methods is that they were coded and worked in a certain way, but then better ways of doing things were found. Sun has always made a big thing about making the different JDK versions backwards compatible, which means leaving in these methods as deprecated, as well as making sure that these methods still worked in the same way. The fact is that EVERY language has had old/bad methods/classes/whatever that have been refined, they just get removed or changed behind the scenes (often subtily changing their behaviour). With Java's use of deprecated this old code is FAR more visible. You also have to consider the size and richness of the API's that ship with Java - nothing else really compares (although I must admit my knowledge of the .net framework is limited).
The Vector issue was a simple one - in the first JDK versions (1.0) there were only 2 collection classes - Vector and Hashtable. They both work perfectly well even to this day. However the decision was made to make them synchronized therefore adding a significant performance disadvantage. The New collections API in 1.1 added a whole wealth of collections classes (I'm struggling to think of a programming language out there with a collection API as rich) which didn't replace Vector and Hashtable, just added new classes to them.
Not sure what you mean about the component model - the JavaBean component model has been used for ages ever since Java 1.0.
The classpath thing always annoyed me when I was starting off, but I have to admit after programming with Java a bit something seemed to of 'clicked' in my head so I don't find it a problem any more.
I guess the point I'm making is that Java wasn't perfect when released, it needed refinement and new development. Consider C++ which has been around for FAR longer than Java, and IMHO has more intrinsic flaws than Java does - but this is only to be expected, Java is a more modern language. Having programmed in both C and C++, I must say that I much prefer Java.

Hehe, no problem. I'll delete the first two

The thing with deprecated methods is that they were coded and worked in a certain way, but then better ways of doing things were found.

From the descriptions I've seen, often they were just wrong. Like "This didn't do Unicode right, or this isn't binary safe, so use this instead".

The fact is that EVERY language has had old/bad methods/classes/whatever that have been refined, they just get removed or changed behind the scenes (often subtily changing their behaviour). With Java's use of deprecated this old code is FAR more visible.

Yes, good point.

the JavaBean component model has been used for ages ever since Java 1.0.

Hmm, I thought they had used something else originally, and then switched to JavaBeans. Maybe I'm thinking of something else.

They both work perfectly well even to this day. However the decision was made to make them synchronized therefore adding a significant performance disadvantage.

Yeah, I know... design mistake

I'm struggling to think of a programming language out there with a collection API as rich

If you're just talking collections, I'd say C++, at least, has a more extensive collections framework, although there's no hash table implementation (map uses a BST), though many implementations provide a hash_map (and one will probably be in the next version of the standard), but they also can't hold any kind of object by default (though that's a property of the language, not the libraries). If you're talking about the standard libraries as a whole, then you may be right. Though, while I've never done a comparison, but I bet Perl with CPAN, Python, etc. probably beat Java in a lot of ways in this area too (Plus, they have a lot built in that you need libraries for in Java). .NET is probably comparable also. But you're right, Java's class libraries are very extensive.

Last thing I'll mention about design mistakes... one of Java's biggest was their distinction between primitive types and object types. There's no reason they couldn't have completely hidden that distinction from the programmer. That's what Eiffel does. It treats everything uniformly as an object, but when it can it uses normal primitives for efficiency and doesn't bother you about it.

Sunday, August 3, 2003

Java I/O

Comments

Recent comments