December 2005

Wonderful quote from the Electric XML documentation:

“First off, Ruby does iterators differently than Java. Java uses a lot of helper classes. Helper classes are exactly the kinds of things that theorists come up with… they look good on paper, but using them is like chewing glass. You find that you spend 50% of your time writing helper classes just to support the other 50% of the code that actually does the job you were trying to solve in the first place. In this case, the Java helper classes are either Enumerations or Iterators. Ruby, on the other hand, uses blocks, which is much more elegant. Rather than:

for (Enumeration e=parent.getChildren(); e.hasMoreElements(); ) { Element child = (Element)e.nextElement(); // Do something with child }

you get:

parent.each_child{ |child| # Do something with child }

Can’t you feel the peace and contentment in this block of code? Ruby is the language Buddha would have programmed in.


Just when I feel like weaning myself off the synaptic teat…

One feels a great ruffling of feathers and desire to stroke one’s beard sagely, when one has just set up bind, postfix and dovecot, fought through poor documentation and idiotic default settings to achieve maildir folders and local delivery into same.

Next: will postfix accept mail from outside the domain?

Wonderful stuff, free software. (I steadfastly refuse to use one of the politically correct acronyms such as FLOSS (Free / Libre Open Source Software) – the venerable Mr. Stallman coined the original term, and it’s understandable as is, without having to invent some other term because the great unwashed can’t change their understanding of “free”).

I can see, however, why people would choose Exchange. I’ve been through the pain of setting up a mail system for a company and my own domain (with various versions of Sendmail on Red Hat 4.2 to 7.3 – now there’s complexity for the sake of maintaining that beardy high-priesthood aura). I can quite easily see how people would choose a mouse over Postfix makes things a bit easier (although I saw some mention of UUCP in a config file, come on, people – who still uses UUCP?!) … but it still requires a guru. Which I’m not – haven’t really got time to get deep into these things.

And then a sharp jolt from the wallet reminded me that to get Exchange (for a very small domain) would still require some exorbitant MS OS and client access licenses. Vive la revolution…

You simply must read To Thread or Not To Thread?, which is about the NetBeans Java IDE. I used this system for a while before becoming too frustrated with it, switching to Eclipse, which is Generally Wonderful.

“It is difficult to describe the current state of threading in NetBeans precisely; no one is completely sure how it works. Various aspects of threading were introduced into the code base incrementally, to address particular issues, and there has never been a comprehensive review of the whole architecture.”

Words fail me! Sun are still promoting this clustermess! Refactoring, anyone?

The article redeems itself with a good warning against heavy multithreading in the “Dangers of Threading” section.

Swing programs must ensure that all GUI work is done on the Event Dispatch Thread. Failure to do this leads to unpredictable results. You can use SwingUtilitiies.invokeLater() and SwingWorker, but it’s easy to get the correct use of these wrong, or forget. (Come on guys, it’s 2005, we should have a Thread-safe GUI library by now…)

So, thinking I could be clever, and use a dynamic proxy to intercept all method calls on Swing objects and check that they are being invoked on the EDT, dumping a stack trace if not, off I set.

Wrong – the standard Java dynamic proxy only works when you have classes implementing interfaces, and I just wanted to attach an interceptor on all Swing component classes.

Enter CGLIB, and its Enhancer class. Much better, and I could write a custom ClassLoader that attaches the MethodInterceptor to each class – solution!

Er, no.

This’ll work fine, if I use the target class as the Enhancer’s subclass, then create an instance of the class, and use the – now proxied – class in my app.

The problem comes when I realise I have many zillions of JButton b = new JButton("Some Text"); lines in my software. I really don’t want to have to change all of this to use a Factory that instantiates a proxied component.

I feel there really must be a way of doing this, but it eludes my sight at the moment, and I really have more pressing concerns ATM.

However, a random search on good old Google turned up:
ClientJava – Easily find Swing Threading Mistakes – which achieves the end result in a different way.

Result! Oh frabjous joy…..