Tuesday, September 09, 2003

Interdependency vs. Reuse. The proliferation of pseudo-standard Java libraries, such as the various commons libraries, has me a bit nervous.  On one hand we've got some extraordinarily useful stuff out there -- byte code engineering libraries, XML handling, mathematics, you name it.  We Java programmers have riches that no other environment has, right now.  We even have handy tools like maven, which are designed to have a look at what's being built and automatically download dependent libraries.  I've never personally used Maven other than to build someone else's project; I'm not really a command line kind of guy, on a day-to-day basis.  In my day job, we use an ant build system for the baseline and release builds, but nobody uses it incrementally (we all use Eclipse, except for this one guy who insists on using JEdit, and we all laugh at him but he's really good so we don't laugh too much). It's just way too easy to pluck one or two bits of functionality out of a huge library, and drag a huge mess of dependencies and the accompanying work into the VM.  Most of the time those .class files are going to sit there out of reach and you won't have to worry about them -- the VM isn't going to be doing much extra work.  But are you sure?  Have you watched the classloader to see what it is doing?  The internal dependencies of libraries are a funny thing.  You never really know what you're going to be bringing in, when you touch something that you think it quite simple and quite isolated.  Back in the Day, we used to have these funny things called linkers.  You old guys know what I mean.  You'd compile your stuff down into object files, link with library files, and voila, you'd have your nice tight executable.  All is well.  The thing is, the main function of a linker is the throw away the things you don't need (well, there are other things too, but it's still a main point).  When the compiler and linker know what's being used, there's a lot of optimization that can take place. Java, with its dynamic linking capability, is another story.  You never really know what's going to be used.  We have optimizers (like yGuard) that can do some of this optimization for us, throwing away some of what we need.  Still, it's an uncomfortable thing.  Too much gets dragged in; things just get too complicated. The bottom line is, you've got a huge library of base functionality sitting there in J2SE.  Consider using it as much as you can.  Logging?  Unless you have some pretty specific requirements, just use what's in there.  Same goes for XML, regular expressions, collections, and so forth.  Come up with a damn good reason before going outside the base kit. Second, before pulling in something huge, evaluate your level of usage.  Do you really need the whole thing?  Can you just pull out a small part of it and use that?  Seriously consider a little cut-and-paste reuse.  You might just be able to get by quickly and easily, and not create additional dependency problems. Third, be sparse in your use of code from another library.  Restrict yourself to the smallest set of interfaces, and the smallest set of methods that you possibly can.  Cutting these dependencies will pay dividends later, when that library morphs in a way you didn't expect, which happens with distressing frequency.  I don't begrudge library authors their right to change; they can and should.  It's simply a matter of balancing the cost of the various methods of adapting, copying, or reusing library code.  Keep in mind all three methods, and make conscious decisions. 9:52:29 PM