Btw, I unearthed a Java concurrency bug the other day. Here’s how.
April 16, 2009
February 25, 2009
November 1, 2008
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.
July 26, 2007
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.
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.
July 24, 2007
Comments Off on Re: The Open Source Frameworks I Use
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.
May 22, 2007
Comments Off on Updated book library: Design and fantasy
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 Artima.com:
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.