Beyond Java - Bruce Tate [6]
Complexity
Java seems to be moving away from its base. You might solve the hardest problems more easily, but it's much harder to create simple web apps than it ever has been before. James Duncan Davidson calls this problem approachability . When Java was young, you didn't have to know much to build a basic applet. Now, to build a simple web app using the most popular frameworks, you need to know much more.
True, open source tools are changing the productivity of Java dramatically, in the best possible ways. Tremendous tools like Hibernate and Spring can let you build enterprise-strength applications with much less effort. But it can take a whole year to confidently learn how to wield these tools with skill. AOP can also help, by letting you write plain old Java objects (POJOs) for your business rules, and isolate services in prepackaged aspects like security and transactions. These abstractions, though, make an ever-rising river for the novice to navigate. My question is this: how high is too high? I think we're already getting too high for most novices. I no longer feel comfortable telling a client that they can retrain the average COBOL programmer on Java. There's just too much to learn, and it takes too much time.
In the past, complex problems drove higher abstraction. When computers got too big for people to code with wires, experts programmed with machine code. When those programs got too big for people to understand, they organized the machine codes and data with symbols in assembler language. Rising complexity led to high-level languages, structured programming, and object-oriented programming. My contention is that this higher river of complexity will flood, forcing us to adopt a new abstraction, sooner rather than later.
Rapid revolution
There's been an incredible amount of innovation around Java in the past three years. You've experienced a transition from the heavyweight containers like EJB to lightweight containers like Spring. You've likely moved from EJB or JDBC persistence to iBATIS, JDO, or Hibernate. You're possibly seeing the wisdom of moving beyond Struts to something like Tapestry. It's been my experience that most innovation is driven by need. My theory is that revolution increases dramatically when complexity hits a certain threshold. The only evidence that I have to support this theory is circumstantial:
The overpowering new mountains of persistence frameworks
The proliferation of model-view-controller (MVC) frameworks
The growth of containers
The rapid introduction of XML-binding frameworks
I'm suggesting that inventions usually accompany a need. When we get something that's right or merely close enough, like Ant or JUnit, we leave it alone until it doesn't fit our purposes anymore.
Experienced developers likely will not understand the excruciating process of learning enough to build the simplest web application in Java. Many of them will complain that I am overstating this issue. If you're in that group, I challenge you to find a smart, inexperienced Java developer who's learning the whole stack of applications that you need to do enterprise web development, and interview him. The problem is twofold. First, it's hard. Second, the consequences for failure are dire. If you pick the wrong horse once, or get locked up for three years on a big project with dated technology, you'll be just about starting over when you move on to the next project. The implications of the churn are staggering. To me, they may mean that code needs to be happening at a higher level of abstraction, and we've been incapable of finding it in Java.
Unnatural stretching
Increasingly, you're probably stretching Java beyond its intended directions. It's just a plain fact that the object you code with plain Java is not enough anymore. I made the point in Better, Faster, Lighter Java that trying