Parting Shots

Of course, you could write a whole book about the strengths and weaknesses of Java alone. I don't think that's productive. I won't rehash the "EJBs stink" message that's been presented prominently in my last three books. I also don't want to launch into a debate about the meaning of whitespace, Java's commenting styles, or the relative benefits or evils of byte code enhancement. Still, there are more things to cover. Exceptions and strings play a huge role in most Java applications.

Sun

Sun is not the company that it once was, placing Java's future in doubt. I'm not saying that Java will disappear, but Sun might. It has lots of cash in the bank, but where is it going to make money? It's being squeezed on the low end by companies like Intel, Dell, and AMD. IBM is squeezing Sun from above. Sun's software and services businesses have never really taken off. I think Sun is a ripe acquisition target.

If Sun does have major problems, what happens to Java? I fear that an IBM acquisition would put too much emphasis on the hardest enterprise problems, moving Java further away from its base. Open sourcing Java could effectively splinter the language. Other potential suitors, like Oracle and BEA, could lead to a conflict of interest that could stymie new standards.

IBM may be getting nervous. It has begun to hedge its Java position in several ways:

• IBM is aligning closely with BEA on standards like SDO, and it is increasingly at odds with the JCP. IBM may well be positioning itself to challenge the JCP, or establish standards outside of the JCP.

• IBM looks like it may embrace PHP more closely, to take advantage of that swelling marketplace. PHP would be an effective hedge for smaller and intermediate businesses.

• IBM continues to invest in XML technologies with Microsoft.

In any event, Sun's ultimate health, or lack thereof, casts doubt on the shape of Java's future. If you're trying to maintain market dominance, uncertainty is not the best place to start.

Exceptions

Like static typing, Java's emphasis on checked exceptions seems like it's on unshakable footing. The argument goes something like this: if a typical developer doesn't have to deal with an exception explicitly, he probably won't deal with it at all. For me, and for many of my customers, checked exceptions tend to hurt more than they help, for many reasons:

• The exception syntax is incredibly invasive. Exceptions easily dominate a typical method, even at very low levels, when you can't do anything about them.

• Most of the time, you can't deal with an exception, so you can only throw it up the chain anyway. You shouldn't have to do a job explicitly that the compiler can do for you.

• Having so much exception syntax deadens you to the few lines of exception code that actually do something important. Said another way, it's hard to see the diamond through all the mud.

Recently, Java frameworks like Spring and AspectJ have begun to recognize the power of unchecked exceptions. Hibernate founder Gavin King has often said that he would have built Hibernate on an unchecked exception model if he had a chance to do it over again. Hibernate converted to unchecked exceptions at Version 3.

Expressing Data

Programming and data go hand in hand. In most other languages, structured data becomes a natural part of an application. Part of Java's over-reliance on XML comes from its limited ability to express structured data. In Ruby, I can quickly declare a hash map of arrays, for example. Such structures dramatically ease configuration and allow natural metaprogramming.

Strings

If you look at Perl , you can quickly understand what it's designed to do. It's a turbo-charged text manipulation engine. Though it's very complicated in other ways, Perl has been so popular because it does what it's designed to do.

By contrast, if you look at Java, you don't have the same convenient, high-powered text manipulation. That's surprising, especially when you look at the core job that we ask Java to do. Servlets, XML, JSP, HTML, and many other constructs are strings. In fact, I probably work with strings in some form more often than I do anything else. It's amazing to me that Java's not any better than it is when it comes to strings. Its pattern-matching support is second class, and the major string APIs are at an extremely low level.

Simplicity

Java's already a good language for big, hard-core enterprise programming projects. It's getting better at solving that problem. And Java's never been good at tiny applications that you might write for a small business in Visual Basic . There's a huge middle ground between these two problems. Java stepped into this gap with a vengeance and ripped the heart out of Microsoft's enterprise programming community. But Figure 4-2 shows Java is leaving that community behind rapidly.

Figure 4-2. Java has controlled the gap between enterprise projects and small ones, but is now leaving that community behind

In my past three books, I've made the case that Java has to get simpler to thrive. That's not happening. Java's power structure is entrenched firmly in the enterprise space. In the past three Java One conferences, Sun has paid lip service to the need to simplify the Java API, but we're seeing only limited focus on richer user interfaces. The big vendors claim a drive to simplification, but the ultimate answer is EJB 3.0 , generics , and Java Server Faces (JSF) .

In fact, Java is moving away from its base. Remember, huge numbers of us are waiting for better, simpler ways to baby-sit a relational database with a web frontend. Instead, we're seeing more XML, more configuration, more layers of abstraction, and a steady drift away from the user interface and the end user. Java takes longer to learn and is no longer approachable.

Tools

One of the symptoms to this problem is Java's over-reliance on tools. We Java developers love our IDEs. The truth is that we can't live without them. In the not-too-distant past, I did some research for a major application server vendor. I found that the most productive developers liked the command line better. You can always find a command line, and an editor. If you're comfortable with these tools, you can go anywhere.

But in the past three years, we reached a tipping point of sorts. The smartest developers are moving toward IDEs, because the language has become too complex to manage without them. You simply need an IDE to do any real degree of refactoring. Other languages have IDEs, and also good programmers who are very comfortable without them.