Hi Bruce, can you introduce yourself to TheServerSide.com community?

Thanks for inviting me, Dion. My name is Bruce Tate. I'm a father, mountain biker, and kayaker from Austin, Texas. For a living, I write, teach, and consult. My last three books were Bitter Java, Bitter EJB, and Better Faster Lighter Java. I've got my own consulting practice, where I focus on design reviews. In a typical review, I'll read code and listen to customers, and then tell the customer what's working, what's broken, and how to smooth out the rough edges. My focus tends to be on persistence frameworks and testability. My passion is unquestionably communication.

I have tremendous respect for TheServerSide.com, where you have so many great minds, like Rod Johnson, Cameron Purdy, and Robin Roos. They have tremendous insight into corporate development and effective programming techniques. I'm much more of a pragmatic, and a communicator. I like to sit back and watch great ideas evolve, and take the ones that I like to my customers, readers and students. While I'm not a great inventor, others have told me that I do have very good industry vision.

What made you write the Bitter books?

Bitter Java was written in a time when the tech bubble was bursting, start-ups were going down in massive numbers, and huge technical books had lots of pages, but no soul. People didn't want to read yet another phone book telling them how easy Java could be, if you'd only read yet another encyclopedia of design patterns. I found Manning Publications, and together, we built a book that said that Java projects can and do fail, and these are some common reasons why. It wasn't a great book technically by any stretch, but it was very accessible. I'm proud of two ideas in Bitter Java. First, a technical book could be fun to read, and still be popular. I started each chapter with an extreme sports adventure gone bad. The second contribution was the idea that you can learn as much by studying as much bad code as good code. When you learn how things fail, you also learn why tight coupling can get you into trouble, and why round trips can break you. Further, with Bitter Java, you could read bad code without making the mistakes yourself.

Bitter EJB continued my evolution as a programmer and writer by showing how EJB could be misused. Most see Bitter EJB as a negative book for EJB. Actually, it was quite supportive of session beans, both stateful and stateless, and MDB. But I did make my first political statement, coming out against CMP. Mike Clark provided excellent chapters; Patrick provided excellent ideas around persistence, and Bob Lee rounded out the team with some forward thinking antipatterns. Though the book supported EJB, I began to understand that there were some holes that minor versions would not patch.

How did Better, Faster, Lighter Java come along?

Better, Faster, Lighter Java came around when I understood that I did not enjoy programming any more. It was getting too hard to keep up. While I wasn't having any fun with it, my customers were drowning altogether. I was ready to take my writing to the next level, so O'Reilly was the next logical step for me as a publisher. Mike Loukides, who has edited and sold nearly a million books, agreed to take me on, and I couldn't say no. I put together an outline, and started writing. I looked at some projects that I respected, like Spring and Hibernate, and began to distill the things in those projects that made them successful. Though it has some code examples, I think that the primary contribution is on a more philosophical level. My point is that J2EE with EJB is getting too hard, and we're going to have to work hard to unlearn all of our old thought patterns. We're going to have to simplify. We're going to have to focus on one problem at a time, and achieve transparent models and services. We're going to need to pay attention to what we buy, how we develop, and how our simpler applications can be extended. If you think about it, a huge percentage of Java applications don't need a full-blown J2EE application server, but we buy them anyway. And EJB comes with inherent costs. There's a better way.

Who's your new co-author?

Justin Gehtland, where have you been all of my life? He's a fellow pragmatic. He delivers with outstanding quality, and a technical depth that frankly, Bitter Java was lacking. Justin and I write with the same voice. He's a business partner of the developer that I respect the most in this industry: Stuart Halloway. I provide a lively and engaging style, and I'm not afraid to get a little heretical. Justin provides technical grounding, and brings me into check when I step too far out on a limb.

Sure, we cross over. In fact, after a first cut at a chapter, we'd trade to let the other partner have a crack at critical clarifications, communication, or blatant errors. I'd regularly let Justin have the last say with my chapters, and he trusted me in the same way. Get ready, TSS. If you've never read any of Justin's stuff, you're in for a treat.

What do you focus on in the book?

The core ideas in the book are five principles: simplicity, focus, transparency, foundations, and extension. I talk a whole lot about code, but also about the way that we build applicaitons, communicate with each other, view management, and buy software. Then, I show how those principles play, in major open source projects, like Hibernate and Spring, and in real-world problems. Instead of focusing on the toughest 5% of the applciations, I focus on the masses, because that's the community that is struggling right now. My reviewers say that the book is light and simple, but deceptively powerful. I hope that it's perceived as beneath most uber-programmers, but a statement book for the struggling majority. I want to give the everyday programmer enough ammunition to attack a simple problem in a simple way with simple technology.

What do you think about EJB 3?

I love a whole lot of what's been said about EJB3. Transparent persistence is critical, as are POJO facades. (They match my principles of simplicity and transparency.) I love the idea of testability. I'm not so fond of injecting a new persistence standard into the mix. I would have much preferred a pluggable service model, with pluggable persistence defined elsewhere.

The best standards focus on one problem. With EJB, that problem should be the production, consumption and packaging of services. It should not attempt to define the services. I would have much preferred an approach that defined a persistence standard in a separate JSR, and focused on the services problem. So I guess that my overall opinion is that we're moving in the right direction, but I'm still concerned about the idea of buying a single-vendor container.

I'm also concerned that annotations may bind you to a container. When all is said and done, EJB is all about selling application servers. It should be easy to mix and match pluggable services. You can't do that very well with EJB.

The meta model is a bit dicey. Some of the annotations, frankly, should not be in the code base. They should instead be in some separate configuration, to separate configuration from implementation. In some ways, we may be going in the wrong direction.

Finally, I'm concerned that EJB may be late to the party. I mean, you can do all of this stuff today, with lightweight containers and a variety of persistence APIs. Tell me what the compelling value proposition of this stuff two years from now is likely to be? And I think that it will take at least 2 years for the market leader to deliver EJB3, and it will easily take that long for the average customer to adopt Java 5. (Does that sound strange to anyone else?)

Why do you think the lightweight container movement is doing so well, even though it isn't "standard"?

Lightweight containers let you focus on a single problem at a time, with transparent objects that can live outside of the container, or inside it.

Testability is fantastic. You can break an object or service completely away from the application, and unit test it. Or, you can inject stubs or mocks in appropriate places, and do limited integration tests. The big vendors simply haven't put enough emphasis on testability. It's the most critical slice of the problem.

I also think that it's easier to get your head around a POJO than an EJB or web service. It makes it easier to build simpler applications, and layers with maniacal focus.

Finally, I think that lightweight containers let us apply some simpler AOP concepts, today. Look, AOP is going places. It's going to pop, and pop big. But we're not ready for it yet. We're just starting to understand what an aspect is, but for the most part, don't understand how they can be applied in reliable, performant systems. But ligthweight containers let you dabble in those areas instead of eating the whole elephant.

What research did you do for the book?

The nice thing about my business is that I'm in a perpetual state of research. I travel with some of the greatest independent consultants of our day. Imagine being able to bounce ideas off of Mike Clark for unit tests, Dave Thomas for process or programming theory, or Stuart Halloway for reflection or metaprogramming.

Justin has a similar set of connections. I also do design reviews, which means that I see what ideas that the industry is struggling with, and what ideas are working. So just about all of the research was in the field.

That said, I owe a couple of huge influences thanks. My friend and colleague Dave Thomas is at the top of the list. He's been preaching pragmatic for as long as I've been in the industry. I leaned on his ideas hard. Also, Stuart Halloway is a huge influence. As I was doing my research for the book, I kept running across articles that hit right into the heart of what I was preaching: configuration, meta-programming, class loading, and reflection. But he was doing all of this stuff in real applications five years ago. I'm just now getting around to writing about it. The guys at IDEA have a great IDE, and it's influenced me. Rod Johnson gave me a great review, and we've gotten closer through this process. His book on J2EE without EJB is brilliant.

There were many others, and way too many to thank here. But those are some of the major ones.

But won't EJB3 crush the lightweight container?

It's certainly possible, but I've got to push back, and ask what EJB3 can do that Spring can't? I mean, you've got security, but most of my customers need instance-based security. You have distribution and messaging, but these things are easy to expose as Spring aspects. The bottom line is this: it's not about the container. It's about the production, consumption, and packaging of services. The lightweight containers will be around. I think they'll even thrive and prosper.

In fact, you can look at this movement as the idea that's brought an end to EJB2, or J2EE as we know it. It's the force behind the remaking of EJB. It's not going away. In the end, I may wind up more deeply involved in the Spring project. I certainly believe in it, and am certainly moving toward a more formal relationship.

Where does technology such as MDA fit in? Can modelling / code generation help simplify things?

I think that Java is in a crisis period right now. As it's used, it's too bloated and complicated for most of us to use. You can respond in very few ways:

1. You an put your head in the sand, and pretend everything will be OK. It won't. The world is getting more complicated.
2. You can wait until the new paradigm emerges. AOP is one. This is not a bad option, but I think it may be a little early.
3. You can simplify. That's what I preach in Better Java. Think Tomcat, IDEA, Kodo and Spring instead of WebSphere.
4. You can trust vendors to insulate you from the pain. That's the approach that MDA is taking. It could happen, but it's not the first time that people have tried. I'll need to see those ideas applied, and applied well, before I'm convinced. I'm a skeptic right now.

Do we have more abstraction left in us? If so what?

That's a good question. Abstraction, design patterns, tools. These are not bad things. They can, however, be misused. I say, "let need drive any decision." I often joke that you can tell what design pattern book that a junior developer is reading by reading their code. You'll see every design pattern pressed into service, whether it's necessary or not. It's better to let the need emerge, and use tools, patterns...in general abstractions...to fix real problems.

What are your thoughts on AOP? Can it simplify, or does it go the other way?

AOP is going to happen. The timing of AOP is no accident. New paradigms do not emerge because they're cool or new. They emerge because we need them. Every 20 or so years, the current paradigm runs out of gas, like OOP is today.

But at first, AOP going to happen badly. Think back to the early days of OOP. We all learned that if we were to have any hope of reuse, then we had to use inheritance, and use it liberally. That thinking was flat out wrong. Inheritance is best used sparingly, but with tremendous impact. Aspects will be the same. Early adopters are already using AOP, and with good success. People like my friend Ramnivas Laddad are already using AspectJ to solve real problems, and solve them well.

But object technology adoption was very slow. We started with SmallTalk, which never achieved commercial success. Then, we moved to C++, which was commercially successful, but not really pressed as an object oriented language. In many ways, we had C++ --, meaning we were writing procedural code with an object oriented language. Microsoft tried to sell COM with C as an object oriented platform, but it did not support true inheritance. Still, we were learning as an industry. Those ideas accumulated momentum and mass, so that when the planets aligned, OOP exploded with Java. AOP will be no different. We're going to have to learn, and experience success, and lots of failure, before it's actually applied in the main stream. Tools that cross over, like Spring, AspectJ, and Pico, will have tremendous impact, much like crossover languages did for OOP. Ada introduced encapsulation. Visual Basic introduced component models. C++ let procedural code and OO code live side by side. We'll see this history repeat itself.

But I think that we're first going to have to simplify, and strip off a whole lot of dead weight, before we're going to be ready for AOP, becuase it's not yet time. And that's why Better, Faster, Lighter Java is such an important book.

PRINTER FRIENDLY VERSION