4.5. 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 ab out 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. 4.5.1. 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. 4.5.2. 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. 4.5.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. 4.5.4. 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. 4.5.5. 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. 4.5.5.1. 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. 4.6. Why Not Just Fix Java? You might argue that we need to fix Java, not scrap it. That would be easy if you could pinpoint the problems. If you thought the problems were in the language itself, y ou could just do some major surgery and offer a new version of Java. That's easier said than done. Sun has been very careful to preserve backward compatibility at all costs. If you look at the lack of commercial acceptance for Visual Basic .NET, it's easier to respect Sun's point of view. Microsoft made some radical changes to the language and libraries , and they weren't well received. Regardless of whether it's a good idea, Sun will continue to be conservative to protect customers. Still, even if you look at relatively aggressive changes, most experts that I interviewed tend to think Sun is even now moving in the wrong direction. Instead of making Java more nimble and dynamic at the foundation, the changes, for the most part, amount to additional type safetysyntactic sugar hacks built into the syntax rather than the JVM that often lead to inconsistent behavior. 4.6.1. Libraries and Community It's clear that libraries are problems, too. Sun has launched several belated simplification movements. So, if it's Java's libraries that are broken, and not the language itself, couldn't we just scrap a few libraries and start over on a more simplified foundation? That's the approach we suggested in Better, Faster, Lighter Java. For Java's most important and basic job, a web-based user interface on a relational database, I don't think Java's frameworks are moving in a healthy direction at all. Most frameworks are moving to add more compelling features rapidly, instead of simplifying what's already out there. One bad library might point to a few local mistakes. Java's problems are more global. They target very complex problems at the expense of the easy problems that most Java developers need to solve. The problem is clear. The Java leadership is abandoning its base willingly and rapidly. It's a cultural problem, inherent in the Java community, vendors, programmers, and leadership. Java has become strictly a language for hard-core enterprise development of large-scale problems. 4.6.2. Alternatives Over the next five years or so, the question in play will be this: are the Java community and expansive code library base worth sacrificing the productivity that other alternatives will bring to bear? So far, the answer has been a resounding "Yes." But we're nearing a point of no r eturn. Java needs radical changes if it wants to continue to be all things to all people, but the community, culture, and leadership behind Java have never produced the kind of structural, sweeping changes that we need. Sun has always treated Java conservatively. The community process has always built the kind of software you'd imagine a community process would build: bloated compromises that please no one in the end. The Java community has always tolerated too much architecture, too much XML, and too many layers. In the second half of this book, I make the case that a clean, dynamic language could gain footing easily in the gap between Visual Basic and enterprise Java. Once entrenched, it could take the same path Java did, into the enterprise. After all, the lion's share of Java development, even in the enterprise, is not full of distributed transaction and backbreaking loads. Five years ago, most developers that I talked to on a regular basis wanted a good way to baby- sit a big, fat relational database with a web-based user interface. Five years later, they want the same thing. So far, I've shown you how Java is drifting away from its base. In the next chapter, you'll see the rules of the game for the next major successful language. In the next half of the book, I'll explore what alternative languages have to offer, and whether that will be enough to take you beyond Java. . 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. 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 4.5. Parting Shots Of course, you could write a whole book about the strengths and weaknesses of Java alone. I don't think