Java

What the OO solution to this problem gives you, though, is some nice name-spacing, the potential for type safety in your map method and a potentially much more readable batch of code. What's the major issue with this?

Anyone who's spent much time using the Eclipse IDE knows that this piece of software is all about plugins. In fact, in many ways Eclipse itself is basically just a platform into which various plugins are installed. All of the Java IDE stuff, in my understanding, is implemented by the Eclipse team using the same plugin architecture that other developers use to make their own plugins.

I recently spent some time in Eclipse plugin land. I'd been avoiding this for a couple of years, because sometimes I just get tired of learning how to use new tools. Java development, especially, seems to call on you continuously to master some new best-of-breed framework (Struts, Hibernate, J2EE, JSTL, and so on). So a certain amount weariness had set in. But SourceJammer (my open-source VCS product) did not have an Eclipse plugin and users were constantly crying out for one. So finally I just broke down and got to work.

My saga of frustration and woe in trying to build a simple Web Objects application continues.

I hope I don't come off as someone who just wants to crack on Web Objects, but the more I work with it, the less there is to like. I think my essential problem is with the "one-tool-fits-all" approach behind Web Objects. As I explained earlier, WO is basically a case tool for web development. And like all such tools, it requires developers to do everything in exactly one way, using proprietary tools, while hiding all kinds of relavent information.

I've got a solution to some tricky Java printing problems. The bottom of this post contains code that you can re-use, for free, to very easily print the multi-page contents of Java Swing components.