Beyond Java - Bruce Tate [25]
My intuition tells me that the ultimate answer won't look much like a browser, but will have many of the same characteristics. You can well imagine that a better marriage between a browser and a dynamic language would make it much easier to give the user a richer experience. One thing to me is clear. The Java community has not had much success with richer clients. The mainstream rich client technologies of Swing and the Standard Widget Toolkit (SWT) keep the programmer at a very low level. Microsoft and Apple both have much better frameworks. While Java does do web-based development very well, increasingly users will demand a richer experience as they have access to more bandwidth and ultimately see the incredible power that a richer experience can unleash.
Enterprise Integration
As the emphasis in Java shifted from the client to the server (Figure 3-2), enterprise integration became more important. Here, the partnership of IBM, Oracle, BEA, Borland, Sun, and others paid huge dividends. They enabled Java connectivity to databases, transaction engines, messaging systems, and any other enterprise system that required a Java connection. The combination of vendor cooperation and support drove cooperation in standards and proliferation of useful connectors that we've never seen before. Java proved to be a good integration platform. Because of the backing of all the heavyweights, Java also became a very safe solution.
Figure 3-2. Java's focus shifted from the client to the server over time[*]
Java remains a good language for enterprise integration projects, because of the high number of frameworks that solve so many of the critical problems, like distributed transaction processing. Static typing is much more important for problems on a massive scale, since such problems are harder to test, bugs become more expensive. Relative to C++, in this space, the speed of authoring is more important than the speed of execution, because most execution time is spent inside of the various enterprise transaction, database, and networking libraries.
Moving Forward
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.