Die Flagge des Marasek



Current Texts Comic Imprint Calendar Search PHP-Classes Container-Wizard main.s21


Class Library
Global Politics
World Outlook

Is the Java API bad?

Previous: Happiness pursuedNext: Armies of Exigo
Assigned keywords: Programmieren

I read Amazingly bad APIs and afterwards read the Wikipedia Article on Paul Buchheit, which made me think whether its a good idea to oppose his opinion, as I might end up with page rank 978.

Anyhow, what he writes is stu a little bit short sighted. He complains about the complexity of Java's API, which gets especially apparent when compared to Python. Now he pulls out one example, which is to produce a thumbnail from an image, which happens to be one line of code in Python and about 50 lines of code in Java.

However, I'd favor Java on this one, even though I see his point and often enough despair of Java's intricate abstractions. But my own PHP library is somewhat inspired by Java's way of handling things, with a lot of abstract classes and interfaces. Mayhaps the reason for such intricate complexity is that I actually enjoy writing APIs over writing actual applications with them.

But there are real world reasons to refrain from writing API methods like Image::thumbnail:

  • Image::thumbnail is only needed by a fraction of people, but a language API should be neutral. The clear reason why the Python guys implemented methods such as thumbnail is to make Python more attractive to developers of web applications. There is a certain justification for this - look at PHP and how it is geared towards developing web applications - but Java wants to be a general purpose language, and certainly isn't the language of choice if you want to hack away a script which displays some pictures as thumbnails
  • a lot of task specific methods will clog up the API with a lot of methods. Personally, I enjoy light weighted APIs because it limits the amount of clutter I'll get when pressing "auto complete". Even Java feels gruesome to me, as usually I have to scroll down felt thousands of methods, especially when working with Swing.
  • Whenever a new task arises, you're faced with the decision whether to change a class or not, which will subsequently get more and more bloated if you do. I did that earlier, but I'm much more content with a more modular system. In former times, I felt that my own API was becoming some sort of jail, allowing me to do common tasks very fast and made it very difficult to implement functionality outside the common area. With a much more modular approach, it is easier for me to implement application specific functionality, leaving the main API entirely untouched.

For APIs, I favor the Unix approach: have a lot of tools which do a small task very well, and then finally plug a series of good tools together to get the desired result. Doing so will allow you to reap a high level of reusability as a reward.


Please note: comments posted won't be visible immediately, as they will be checked for harmful content.

* Title  
* Nickname  
* Comment