Beyond Java - Bruce Tate [39]
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,