Rod Johnson wrote the book I’ve always wanted. I like to think that if I’d had it, read it, and understood it years ago I would have produced finer software architecture and enterprise Java apps than I can claim to. But my happiness at finally having it in hand is balanced by a lingering sense that in doing such a good job of defining what enterprise Java architecture really should be…he’s also revealed how expensive and complex it truly is.
![]()
Don’t be put off by the thickness of this tome. Almost any 10 pages at random yield the kind of nuggets that you know will more than pay back the time and money to acquire them. His notes on selecting an application server are lucid and to the point. His critical analysis and indictment of EJBs is superb. His code samples are realistic and so real that they are now part of an open source project called the Spring framework.
I actually like the cover portrait, because it seems to convey the intelligence, rigor and fairness that Johnson brings to his Herculean task. My wife found it “creepy” and in the interest of harmony I covered it with a vacation photo of us smiling from a beach somewhere. I suspect the picture was taken after he completed it, reflecting some of what he expressed in his dedication. It cured me for the time being of wanting to try and write a book — mostly because he wrote the book I wanted to create.
There’s too much to list, I can only say that if you even touch Java you should go buy it quickly, and bribe yourself into consuming it as much as you can. It’s heavy, and thick with ideas and wisdom. It finally settled some nagging doubts and worries, and provided some nice examples of elegant solutions. His arguments against typed exceptions are provocative and compelling, for instance. He puts his money where his mouth is by then going and demonstrating a complete working package for encapsulating awkward SQL exceptions with meaningful RuntimeExceptions that you can choose to handle or not.
In the end I feel that this book has somehow closed a chapter for me on J2EE, serving to define it in practice and ultimately underscore it’s greatest weakness: it requires this degree of experience, critical thinking and rigorous attention to details to make it work properly in production enterprise environments. It’s not fair to say that’s just about Java, since it seems to be the truth about scalable distributed application architectures in general. But Microsoft’s VB promises have never seemed so appealing, and BEA’s massive layers of code beckon like comforting lights as dusk falls.
It could be that I’m suffering a bit from fatigue at the scope of his appetite and output. My gut critique is that Johnson doesn’t want to compromise; he wants the best of each and all approaches, and so he may over-design his solutions so that no one could criticize them for the shortcomings he finds in others. I like the idea that imperfect architectures sometimes work well in practice, even in production for the enterprise, as long as you understand the choices you’re making and why. And in the end I am grateful to Johnson for demonstrating many ways to get there on your own, even if he sets the bar pretty high.
Related posts: