1.2. Boiling Frogs
Let's look at it still another way. You've doubtlessly heard that if you put a frog in
hot water, it will leap out, but if you slowly bring tepid water to a boil, the frog will
die contentedly. And of course, that's the debate that I hope to trigger in this book.
Are the waters around us warming? Notice at the end of my introduction, the owl
and the ostrich are exactly the same when it comes to consequences. They may not
recognize it, but motivations don't matter one little bit. If the water starts to boil, if
the conditions on the river change, they'll both die.
This past year, I decided to wake up to my surroundings to test the water around
me. I learned both Ruby and aspect-oriented programming (AOP) . After checking
the temperature, I think the water is actually heating up. It's not boiling yet, and I
don't know if it will ever boil. But I do know that I'm going to keep a close eye on
the temperature for a while, and I hope to convince you to do the same. Let me tell
you why.
1.2.1. Danger Signs
A large number of the applications that we write put a web-based frontend over a
database, sometimes with additional business rules and sometimes without. Yet,
after more than five years of solving this problem over and over, we still can't
solve it very quickly in the Java space. Further, most Java framework developers
are making incremental changes that won't truly revolutionize web development.
Building a new team to solve this problem in the right way is a demanding job.
Building a team from, say, COBOL programmers, is nearly impossible. The
language is too alien, the frameworks too extensive, and the landscape too
unstable. Even with seasoned developers, it takes a surprising amount of code to
get even simple applications off the ground.
Jason Hunter: The Next Big Thing
Author of Java Servlet Programming

What's next? JH: What's next? I don't think there's one thing.
There's definitely not one language. Java's still
the ubiquitous language. The innovation now is
happening on top. Exciting areas: web remoting
(a.k.a. Ajax), search (a.k.a. Google and
XQuery), and folksonomies (a.k.a. flickr tags).
I have a very practical way of evaluating what
is the hot technology: [determining] what earns
you the most money being a trainer of that
technology. Java definitely was the hot
technology for years. I earned twice what the
C++ trainers were receiving. It wasn't that Java
was harder, just that there was more demand
than supply.
If you train on something commoditized (like
C++ was and Java is now), you get mass-
market rates. If you train on something too
bleeding edge, you don't get enough customers.

I don't see any movement right now that's got
the same huge swell potential as Java had.
What are the "alpha geeks " doing, as Tim
O'Reilly calls them? Well, James Davidson dug
deeply into the Mac. But there's not a huge
amount of room for experts in that market.
There aren't enough business dollars to be
earned. I've gone into XQuery, which I've
found a fun and useful way to bring search
ideas "in-house" and put you in control of what
you find and what you do with it. Mike Clark

to confidently learn how to wield these tools with skill. AOP can also help, by
letting you write plain old Java objects
(POJOs) for your business rules, and isolate
services in prepackaged aspects like security and transactions. These abstractions,
though, make an ever-rising river for the novice to navigate. My question is this:
how high is too high? I think we're already getting too high for most novices. I no
longer feel comfortable telling a client that they can retrain the average COBOL
programmer on Java. There's just too much to learn, and it takes too much time.
In the past, complex problems drove higher abstraction. When computers got too
big for people to code with wires, experts programmed with machine code. When
those programs got too big for people to understand, they organized the machine
codes and data with symbols in assembler language. Rising complexity led to high-
level languages, structured programming, and object-oriented programming. My
contention is that this higher river of complexity will flood, forcing us to adopt a
new abstraction, sooner rather than later.
1.2.2.2. Rapid revolution
There's been an incredible amount of innovation around Java in the past three
years. You've experienced a transition from the heavyweight containers like EJB to
lightweight containers like Spring. You've likely moved from EJB or JDBC
persistence to iBATIS, JDO, or Hibernate. You're possibly seeing the wisdom of
moving beyond Struts to something like Tapestry. It's been my experience that
most innovation is driven by need. My theory is that revolution increases
dramatically when complexity hits a certain threshold. The only evidence that I
have to support this theory is circumstantial:
 The overpowering new mountains of persistence frameworks
 The proliferation of model-view-controller (MVC) frameworks
 The growth of containers
 The rapid introduction of XML-binding frameworks
I'm suggesting that inventions usually accompany a need. When we get something
that's right or merely close enough, like Ant or JUnit, we leave it alone until it

where programming is going. I'm just saying that this unnatural stretching is one
more clue that it may be time to take the temperature of the water around you.
1.2.2.4. Language evolution
Java 5 is strongly touted as perhaps the most innovative major release of Java in
half a decade. I do agree that it's going to have a significant impact. I'm not at all
convinced that all of the impact will be positive. I regularly attend a conference
called NoFluffJustStuff. The experts at the conference sit on a panel and answer
questions. One of my favorite questions deals with new features in the language.
The whole panel agrees that generics, as implemented, are a bad idea. That usually
shocks the audience.
If you think about it, the Java generics Java Specification Request (JSR) introduces
a whole lot of syntax to solve a marginal problem with no corresponding change to
the Java virtual machine (JVM). I'm guessing that the typical Java developer rarely
gets a class cast exception. And there are plenty of opportunities. Most of the
objects in a typical Java application are usually in collections anyway. Whenever
you take them out of the collection, you've got to cast them from Object
anyway.
At that point, type safety gives you about as much protection as a lap belt in a
burning, plummeting 747. Yet, the generics syntax is invasive, and the
implementation is worse. In an age when more and more experts assert that
dynamic typing leads to simpler applications and productive programmers, Java
developers are learning how to build stronger enforcement for static types.
Add questionable use of legitimate features like annotations , which can
completely change the semantics of your program without conventional code, and
you've got all kinds of possible trouble. Does the increase in power offset the
increase in complexity and obscurity? Annotations bring a completely new tool,
and in many ways a programming model, to the Java community. I don't know
enough t
o say whether we'll learn to use annotations well, but I do feel comfortable
predicting a few major disasters while we learn.

find enough developers to reach a critical mass? You're probably thinking: face it,
Bruce, there's .NET and Java, and .NET is, by design, as close as legally possible
to Java. Adopting .NET would be like overhauling your diet by swearing off
McDonalds, and going to Burger King every day. After that, there's nothing.
This much is true. If there is no credible alternative, your best course is to keep
looking inside the Java community for answers. In that case, this is a dead book,
and you can just let it be. But give me a few more pages, lest you close it too soon.