My kickoff of the week was a session hosted by Boris Bokowski, Jim des
Rivieres and John Arthorne.
They started a session which was a bit different from what I expected. But
in the end it was a very interesting session about the aspects of proper
API design. The whole session revolved around the effects of introducing
Java 5 features into an API.
After a general introduction on API design with key statements like:
- Language used in API is important. (API means public interfaces along
with it’s documentation and specification)
- Start with a minimal API, opening up “doors” is easy. Closing them is
a royal pain.
- Watch out for binary compatibility between releases built with
After this general intro it started of with some Java 5 bashing. 🙂
- Auto boxing is bad, lots of temporary objects.
- Variable arity methods are bad. They obscure the method call signs
actually being called. Especially when combined with overloading.
- Binary compatibility breakage is the bane of your API life.
The thing is, Java 5 contains loads of cool features, but usage of these
features can cause binary incompatibility. Which requires your API users
to do full rebuilds. Something which you want to avoid when bringing a
version update to your users. Some things ca be done without causing
While I didn’t expect the content provided, it was a very interesting
subject. Personally I’ve never been in a situation where a full rebuild
was a problem. But then again all I know is enterprise development. Alle
major new language features of Java 5 were discussed. I’ve learned a lot
in this session, I wonder when and if I will ever need this knowledge. But
I had provided me with insights into the problems API providers face.