Btw, I unearthed a Java concurrency bug the other day. Here’s how.

I have a new article up on how to debug class loading with AOP at Cubeia’s site, in which I briefly discuss how Aspect Oriented Programming (AOP) using AspectJ can be used to debug class loading, in particular in instances where a system have multiple class loaders. Check it out!

My brain’s hurting. I must be getting old.

For reference, this is some of the programming topics I’ve read up on (or at least tried) lately:

  • Guice and Spring
  • Declarative transactions and JTA
  • EDA, Pipelines and CEP
  • SOA and ESB and NMR
  • Column databases and distributed file systems
  • Wicket and various related Ajax components
  • OSGi in various permutations with the above
  • BI, in-memory BI and CEP (again)
  • AOP and/or IoC patterns

And now I’m contemplating the fultility of programming.

Perhaps I’m being a bit grumpy today, but this article rubs me the wrong way. It describes the Singleton pattern in Java but contains some problems. And one of the is a pet peeve of mine. The article claims:

  • There can only be one singleton instance per JVM == Plain wrong in every respect.
  • Singletons are good for object pooling (such as connection pooling) == Dangerous.
  • You can get away with synchronization problems with a nested inner class == Naive.

The singleton pattern does not guarantee anything regards to the number of instances of an object, and certainly not per JVM. You see, even if we disregard cloning, serialization, reflection or thread safety the following is still true: A class instance of an object is guaranteed to be unique per class loader, not JVM. In other words, if you have multiple class loaders (as do almost all application servers) you can have multiple instances of a singleton per JVM; one for each class loader.

Singletons can help guard limited resources such as object pooling. That is correct, but the implication that it is good design to use it to do so is wrong. Statically held object pools in larger and long running applications and servers are not a good idea as their lifetime cannot be directly controlled by the code. Also, if there are multiple class loaders… See the paragraph above.

And the synchronization discussion is naive as one of the comments suggests. See this, this, this or google it yourself.

So, yes, the Singleton pattern is useful, but not as massively so as many articles and tutorials suggests. In a world of serialization and class loader hierarchies it can be a real pain in the ass as well. Use with care.

The Codist asks what open source frameworks we use. Now, he says frameworks, but it looks more like libraries and utilities. Which is fine by me as I generally tend to avoid the larger frameworks, and just as The Codist himself wrote my own web framework for my regular site.

So, without further ado, here’s some regulars:

  • Jetty – good stuff
  • c3p0 – JDBC pooling
  • log4j – logging, I don’t really like it, but…
  • jgroups – data distribution/messaging
  • JBoss Serialization – for high throughput servers
  • JBoss Cache – data replication
  • Mina – network IO framework
  • XFire – for all your SOAP needs
  • HSQLDB – just works, but I’ll probably check out H2 soon
  • Jaxen – very good xpath engine
  • Hibernate – ORM, because it is more or less standard
  • GNU Trove – primitive fast collections
  • Wicket – if I really must code an web UI

But I must admit, for my home coding I use a lot of my private libraires, I’ve got my own XML API and XPath engine. My own commons collection, UUID API, simple object -> XML lib, logging, email API, etc.

My book library have been updated. First, the latest installment of Steven Erikson’s epic fantasy series, The Bonehunters. I am, as I suspect many others, slightly in awe of Erikson. Extremely complex. Extremely well written. Extremely good stuff.

The second update is the classic The Design of Everyday Things, by Donald A. Norman. This is really good stuff, and anyone aspiring to design software, be it GUI or API’s, really, really should read it. I picked it up after reading an interview with Ken Arnold over at

Taste is a very personal thing. There is no textbook. When people ask me about books on object design, the books I hand them have nothing to do with object design per se. I commonly recommend The Design of Everyday Things, by Donald Norman. This book promotes focusing on usability in the design of doors, teapots, and faucets – everyday things. If you do that for objects, you’ll have the idea.

Oh yes, Ken Arnold as in:

State is hell.


Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, it is evident that every program can be reduced to one instruction that does not work.

This years JavaOne announced several important Java technologies. The one that got most initial attention was of course JavaFX. Well, exciting as this may sound I wasn’t alone in wondering how on earth Sun could hope to launch such a technology on their existing platform. Take these bullet points:

  • Huge download (JRE)
  • Slow startup (no pre-loading here, no)
  • Crappy browser integration (seen any applets lately?)
  • Bad JRE detection (part of the above problem)
  • Somewhat slow graphics performance
  • Sub-standard installer

As a profoundly specialized server developer (I still have nightmares about the one time I had to dive deep into the source of JTable and JTree, the horror! the horror!) I’ve never been very concerned personally. It has annoyed me on an academic level, as I’ve never understood why Sun just didn’t smarten up and fix it.

So why launch JavaFX now? Well, it turns out someone was a bit smarter than I first thought. You see, there was an announcement made on JavaOne which got drowned out a bit, the Consumer JRE. It would appear Sun has finally granted all our wet dreams. Here. And here.

Wheee! Damn good stuff!

Next Page »