December 18, 2002 | co.mmentsMike Clark's Weblog
But the kind of classpath problems that don't conveniently throw exceptions are really nasty. You only suspect there's a problem because the version of a class you think is being used is not. It usually turns out that the class you're expecting to be used is masked by another version of the class at a higher precedence in the CLASSPATH variable. Those kind have a way of robbing massive amounts of your time.
Close, but not quite. CLASSPATH headaches are symptomatic of another problem: versioning. The sofware industry sucks at versioning. What Mike describes above I often call CLASSPATH Hell - named after DLL Hell. In reality JAR packaging offers no significant advances previous component /packaging efforts like COM. In J2EE things go from bad to worse: there you need to keep client and server jarfiles in sync (as Steve Loughran has pointed out). This has the effect of tightly coupling the evolution of clients and servers in a very nasty way. And let's not even talk about what making something Serializable does for managing versions of a class.
Webservices is one area where I feel versioning problems will become truly ugly. Things are difficult enough to manage where clients and services are within the same administrative boundary - on the web they're not. Anyone who thinks you can keep clients and services in lockstep or just frig systems into shape like you would on the LAN is in for rude awakening. Indeed Martin Fowler has indicated we need language support for differentiating between public and published interfaces.
But trying to bite off the versioning problem at the level of languages seems to be going in too low, for the web at least. We might be better off instead looking at architectural models and protocols that are better designed to cope with the independent nature of clients and web services, such as REST.
And I'm really looking forward to trying out Mike's tools :)
December 18, 2002 03:23 PM
TrackBack URL for this entry: