Figure 3-2. Java's focus shifted from the client to the server over time[*]
Today, Java can talk to just about any enterprise system that's important to you. Beyond integration, Java now provides excellent facilities for mapping object-oriented models to relational databases. You can do distributed coordination of transactions, and manage massive messaging systems with first-class rules engines and workflow. You can reach beyond Java into C++ using a native wrapper called the Java Native Interface (JNI), or using coarse-grained strategies like web services. You've got dozens of remoting strategies available, from the 1990s standard CORBA to the Java-only RMI. Or, you might decide to use many of the lightweight HTTP strategies for remoting and web services. Different standards and free frameworks will help you manage the services for your business objects, do text-based searches, write games, or even write mobile applications.
This is the massive front that a challenger must conquer. But Java has a critical weakness, too. The easy Enterprise problems have been solved, so the key vendors spend most of their time working on the hard problems. That presents a problem for the at-large programmer. As Java moves into increasingly complex places, it has a tendency to leave the programmers of the more basic problems behind. EJBs, the intense proliferation of XML, and the massive web services stacks are just three examples of ever-increasing complexity.
In the end, Java is sacrificing its primary base, exchanging what was productive and hip for something that is tedious and slow, but powerful. Many applications don't need any of the extra enterprise stuff. I'd guess that as many as half of all commercial applications involve a web frontend that baby-sits a plain old relational database. A challenger in that space need not try to make a frontal assault. It need only provide a much more productive solution to a niche problem than Java. Watch a framework called Ruby on Rails. Its sweet spot is the web-based UI on a database. Still today, that's a tremendously important problem. It lets you capture and share information, which can in turn be used in any way imaginable.
Erik Hatcher: Java's Success
Coauthor of Java Development with Ant
Erik coauthored Java Development with Ant and Lucene in Action (
http://lucenebook.com/). He commits on several open source projects, primarily at the Apache Software Foundation where he also serves as a member. Erik once kayaked with Bruce, barely living to tell the tale.
What do you like best about Java?
EH: It has lots of built-in capabilities and a cornucopia of third-party (meaning open source for me) libraries.
What don't you like?
EH: I sympathize with newcomers to the Java "platform." We all know Java the language is pretty easy to grasp, and that makes it seem like it won't be too hard, but in reality, you cannot build even the most trivial utility in Java without a pretty hefty learning curve.
CLASSPATH gets us all, for example; even the "experts." To really do something useful you have to learn tons moreAnt, servlet containers, JMS, JDBC, and a zillion other things. It scares me just to think of this massive beast I've somehow spent the last five years of my life on.
How does Java hold you back?
EH: I don't feel held back with it personally, but I often feel that it takes more time than it should to accomplish a particular task.
What would prompt (or did prompt) you to move away from Java, or .NET?
EH: If Ruby had a component-oriented web framework with Ajax-capable components, and there was a port of Lucene to Ruby, I'd be able to build my current projects entirely there. I expect that to happen sometime this year!