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

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) .

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