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.