Those frustrating bits of API

; Date: Tue May 22 2007

Tags: Java

Not everything about writing code in a programming language is easy and wonderful. Sometimes a particular API is hard to figure out, or it doesn't do quite what you want, or the documentation is obtuse, or nonexistant, or wrong, or sometimes the implementation is buggy and the approach you're trying is bumping up against bugs, etc. And you spend long hours trying to figure out what's wrong and how to fix the bloody thing.

It seems it doesn't matter what programming platform you're using; they all have these characteristics. At least the ones I've used.

I've been thinking about this, as the last few weeks I've been toying with Groovy and writing a toolset (using the ROME library) for RSS/Atom feed aggregation and processing. Using ROME made it real easy but there were several times getting Groovy to do what I wanted just didn't make any sense and wouldn't work out.

Where this has taken me is - maybe some of the difficulties I had are bugs in Groovy. But I spent some time with the thing and found a way to do what I wanted to do, and then moved on, without really determining whether I'd found a bug or what. Of course my task was to solve the problem at hand, rather than explore and test Groovy.

This is a common behavior in programmers, right? When I, or any programmer, does this, does the platform lose out on a chance to improve? We just find a workaround and get around the difficult parts with whatever we can figure out to do. We do this whether those difficult parts are bugs or not. Okay, some diligent people actually report bugs and write test cases, but that's not true for all of us. In the perfect world there would be an easy way to capture these difficulties and turn those into tests or bugs or requests for enhancement.

Hmm, I don't know what to suggest, just noticing the problem. I wonder if anybody else has a thought on this.

Source: (

About the Author(s)

David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.