Changing the world through software

Computing for the environment and Computational Linguistics


1 Comment

OOPSLA 2006

I’ve been deciding which sessions to attend at OOPSLA 2006. There’s a lot going on so, unfortunately, I’m going to have to miss some intersting ones. Ther Onward track is particularly insteresting but i want to achieve a balance.
Here is what I have decided:

Tuesday

Brenda Laurel Designed Animism: Poetics of a New World

Onward!: Gabriel Conscientious Software

Onward!: Baniassad The Geography of Programming

Linda Northrop Scale Changes Everything

Virtual Machines

Panel: GoF Design Patterns: Beginnings and Futures

Wednesday

Guy L. Steele Jr. A Growable Language

Onward!: Simonyi Intentional Software

Onward!: Knöll Pegasus: First Steps Towards a Naturalistic Programming Language an area I am very interested in.
Joshua BlochHow to Design a Good API and Why it Matters

Practitioners Reports including some talks realted to Domain-Driven Design
Thursday

Philip Wadler Faith, Evolution, and Programming Languages: from Haskell to Java to Links

Panel: Convergence of XP and SCRUM

Panel: Young Guns/OO: The Next Generation

Software Engineering

Advertisements


Leave a comment

Dates and java

java.util.Date is not perfect and a lot of the original methods have been deprecated yet people persist in using these methods. java.util.Calendar should be used (no that java.util.Calendar is any great shakes either).
I’ve seen a project in which the joda-time library was referenced, using Date.toString() and then using String.substring() to pull out the day month and year! If you see code like this on your project, buy the author a copy of ‘Effective Java’. There is no excuse for not using the API available to you correctly.


Leave a comment

Deprecation and bypassing apis – calling code you shouldn’t, clearly defined APIs

It is a joy to work with a clean, clearly defined API. As an API evolves some methods (or classes) will be deprecated over time. Often the method or class will not beremoved for compatibilty reasons.This does not mean that it should continue to be used. Of course, the deprecation should be documented and i Java the @deprecated javadoc tag is the perfect way to do this. It should explain why the method/class was deprecated and the preferred replacement.

Of course not all classes in a libaray form part of its API. Various conventions are followed such as *.impl.* or *.internal.* packages. Sometimes this hint is ignored by devlopers using the API and this inevitably leads to broken code when a new version of the library is released. One project which makes good use of the *.internal.* convention is the eclipse platform but some plugin developers insit on ignoring it!

One possibility is to use AspectJ to highlight design violations. Adrian Colyer has an example of something like this, using an Architecture aspect in Simplifying Enterprise Applications with Spring 2.0 and AspectJ .