Extreme Advice Considered Harmful

From APIDesign

Revision as of 14:58, 23 January 2009

Have You Ever Wondered...?

I've just finished reading the theoretical and practical parts of your book, are you saying me that I have to apply all your advices to be successful? No, not at all. One of the the worst things to do is to follow advice completely, to the extreme. The chapter 13 builds on the Considered harmful phrase and expands it meaning into the world of API Design.

API has to be Correct

One of the advices that can often cause more harm than be useful, is the attempt to make an API fully correct. Well, nothing about correctness, correct version of an API is better than incorrect one, in case all other features of those two versions are on par. But often, in the search for correctness one sacrifices simplicity.

An example of this can be seen in Java's java.io.File. Have you ever tried to read a content of a file in Java? Painful, isn't it? I have when I have to write that code as instead of loading a file content into a String, one needs to allocate an array, write a loop to populate it and only than convert it into so desired string. I wrote that code many times, especially as a utility method in a unit test, so I at least know how to do it. However imagine a newcomer, a refugee from Perl, trying to rewrite a single line of Perl code to Java. One needs to allocate the array, understand concept of FileInputStream, etc. How can such trivial task be so complex!? Why we cannot have simple methods like:

File f = new File("config.txt");
String text = f.asText();
byte[] arr = f.asBytes();
for (String line : f.asLines()) {
  ...
}

I explanation this unnecessary complexity is as an extreme search for correctness. Plus little bit of copy based design. The way reading is done in Java is the same as it is in C. E.g. malloc a bit of memory, read data into it, process them, read additional data, etc. This C way is know to be correct, never exhaust available memory and be robust even for design of operating systems. As such the designers of the Java I/O libraries just copied this correct and well-working principle.

Nobody of its designers considered it too complicated, as they were familiar with it from their C days. In fact it is not that complex compared to other C constructs. Just try to concatenate two strings and you'll find out how verbose that code is. The C libraries leave the memory manipulation up to the programmer. However Java is different, concatenating strings is a matter of single +. Memory is allocated and freed automatically as needed. API users usually do not need to care. And they like it. As such the Java I/O API for reading from a file seems like a relict of stone age. So complex and hard to use (but correct).

For a while I was advocating the Java library to be enhanced with simple reading utility methods. However only few weeks later I realized that in fact, we do not need to wait! The NetBeans project has own virtual filesystem library and we can add the methods there! Today I am proud to announce that I started an API review to do that (see issue 157362).

Users of NetBeans 7.0 APIs, say farewell to painful reading of files! And please accept my apology for using copy based design and realizing only so late that our users might use those asText(), asBytes(), and asLines methods.