Experienced developers likely will not understand the excruciating process of learning enough to build
the simplest web application in Java. Many of them will complain that I am overstating this issue. If
you're in that group, I challenge you to find a smart, inexperienced Java developer who's learning the
whole stack of applications that you need to do enterprise web development, and interview him. The
problem is twofold. First, it's hard. Second, the consequences for failure are dire. If you pick the
wrong horse once, or get locked up for three years on a big project with dated technology, you'll be
just about starting over when you move on to the next project. The implications of the churn are
staggering. To me, they may mean that code needs to be happening at a higher level of abstraction,
and we've been incapable of finding it in Java.
1.2.2.3. Unnatural stretching
Increasingly, you're probably stretching Java beyond its intended directions. It's just a plain fact that
the object you code with plain Java is not enough anymore. I made the point in Better, Faster, Lighter
Java that trying to code all crosscutting services and all behaviors into business objects is folly, and
inheritance does not go far enough. You've got to use tricks, like compile-time byte code
enhancement or runtime code generation with proxies, to make the object transparent. You are now
stretching Java beyond its intended purpose, and that's good...to a point. You're also increasing the
barrier to entry. Ask any novice who's tried to troubleshoot a problem with Hibernate's lazy loading,
or Spring's proxies.
I've also noticed that other, more dynamic languages rarely use things like AOP or dependency
injection. Those features solve critical problems in Java, but more dynamic languages like Smalltalk,
Python, and Ruby don't have the same level of pain.
I'm not saying that these are bad technologies. They absolutely destroy the closest heavyweight
alternatives, in terms of simplicity and power. They're solving hard problems. It's just that your mind
can learn only so much, only so fast. Java's rapidly becoming an effective tool set for elite developers.
Hey, maybe that's 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.