O''''Reilly Network For Information About''''s Book part 10 pdf

4.1. Java's New Job Description
So far, I've tried to make the case that Java's always been a generalized
programming language, with the syntax and core community coming from the C++
systems language. Also, I've suggested that most early Java applications focused
on the user interface. You could download Java and get something running very
quickly.
Once Java moved to the server side, it became the core server-side development
language. Java carries an increasing load in enterprise development, from object-
relational mapping with distributed transactions to messaging with XML binding
for service-oriented architectures. So the job that we use Java to do is ever
changing. The language is remarkably flexible, so it's lived up to the challenge so
far.
But all of the extra power comes with added complexity. Where does that leave
people who need to learn a language quickly, or the Java programmer who wants
to solve a simple problem, or companies like start-ups that value productivity over
all else? As competitive pressures force us to meet shorter and shorter schedules, a
generalized Java is just not enough anymore. At some point, Java will prove
inadequate. Let's look in detail at what we're asking Java to do.
4.1.1. Typical Requirements
If Java dies, I think it will be replaced one niche at a time. Java's
popular in several
niches. It's floundering in some and thriving in others:
 Java's become indispensable for writing middleware , the systems software
that fits between an application and an operating system. Java's many
libraries, performance, portability, and ubiquity make it a good fit for
middleware, and that's likely to continue.
 For servlets and web programming in general, Java needs a faster feedback
cycle, and needs to get better at managing strings. PHP is far more

productive for this environment. Java's not the only reason: web
programming is a mess for many reasons. But Java just isn't very good for
the simplest and most typical applications.
 For XML processing, better alternatives exist. I'd argue that Java's over-
reliance on XML is part of the problem, but let me point out that Java is not
a particularly good language at handling XML either. XML requires
excellent strin
g parsing and manipulation, and Java is just too verbose in this
space. Already, the Ruby XML processing libraries, for example, are
friendlier than the Java versions, and nearly as fast, for most jobs. Some
other languages have excellent XML support. They will only get better over
time.
 For large enterprise projects requiring things like distributed transactions
across multiple resources, heavy legacy integration, and code that relies on
niche libraries , Java's large libraries and the availability of Java developers
make it a natural fit. It will continue to find a role here for quite some time.
Be careful, though. Most projects in the enterprise are smaller projects that
could benefit from a more productive language.
Instead of looking at the entire Java landscape, let's narrow it down a bit and
consider the requirements for the most typical Java job. I'll go out on a limb and
suggest that the most common Java job is to take a big, fat relational database and
baby-sit it with a web-based user interface. As a consultant, I see variations of this
job more often than any other.

I realize that I'm painting Java into a smaller niche than it's currently occupying. I
do think there's cause to do so. From the beginning, Java has been a converted
systems language. The impressive list of libraries expands that scope, and the
broad and deep pool of programmers makes it compelling for large enterprise
applications. But Java never really has been a general-purpose applications
language, though that's the place that most of us use it today.

4.1.2. The Learning Curve
If you're concentrating on putting a web-based frontend on a relational database,
Java framework designers have solved this problem repeatedly for eight years. I've
got to admit, Java hasn't gotten much better at this job since the invention of JSP.
Take a look at one of the earliest servlet APIs in action:
public class HiMom extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
response.getWriter( ).println("<HTML>\nHi, Mom\n</HTML>");
}
}
True, this programming style leads to ugly code with nearly impossible
maintenance. It couples view logic much too tightly to business logic. But it is very
easy to understand. With the first release of Tomcat, after a few minutes of setup
and less than 10 lines of code, you could write a "Hello, World" servlet.
Now the same application involves more effort. With the latest release of Tomcat,
you can't just write a servlet anymore. You also need to code up a deployment
descriptor and package it all up in a standard WAR file. That means you've got to
learn more about Tomcat , more about the servlet specification, and more about
XML. As a consequence, the getting-started documentation for Tomcat has grown
from a couple of pages to dozens of pages.
You might not think that substantial increases in the learning curve for Tomcat
matter much. You might be willing to make such an investment in Tomcat,
because it's such a core technology. The problem is that it doesn't stop with the
servlet API. You need much more to build a typical Java application today than
you needed five years ago:
 You'll likely need to understand Ant , the typical tool that most of us use to
build and deploy web applications.
 Then, you'll need to understand Tapestry , or Struts , or some other web
MVC framework, to help you organize your user interface code base.

 Most of us try also to learn an object relational mapper, like Hibernate .
While it does relieve some of your persistence burdens, it also imposes a
steep learning curve.
 You'll probably want a framework like Spring to organize your application
resources and make this whole strategy testable.
 You'll need some education on how to use these tools to integrate them and
use them together effectively.
My clients that move to Java from another language just shudder when they see my
recommendation of five weeks of education, which lets them cover only the
fundamentals. Java is no longer an approachable language for them.
4.1.2.1. Java for the typical application
True, Java has improved some aspects of this problem. If you've got a highly
normalized relational database that doesn't lend itself to an object model very well,
you can map it better today than you could then, because of the emergence of
object relational mappers like Hibernate and JDO . You can better separate the
business logic from the view logic, with Struts and better emerging alternatives
like Tapestry. You can attach services like security and distributed transactions to
any Java object with frameworks like Spring.
But if you really come back to the core problem, a web-based user interface on a
relational database, you have to learn much more to do the job today than you had
to learn five years ago. And you have to work harder to achieve the same results.
Most of the added value deals with corner cases, or noncentral problems. When all
is said and done, these advanced frameworks will drive the Java language away
from the base that made it so popular. When that happens, Java will be a niche
language for large-scale enterprise development.
4.1.3. Agile Processes
While the requirements for the typical Java application have remained relatively
static, radical changes are transforming the typical process that you might use to
build it. While not many Java programmers would say they use agile methods like
SCRUM or Extreme Programming , more and more of them are using the core

techniques from agile processes :
Simplicity
Agile methods suggest that you should use the simplest thing that will work.
Simpler frameworks like Spring now displace complex frameworks like
EJBs with increasing regularity.
Automated unit testing
We are in the midst of a testing renaissance, and the JUnit framework and
agile processes light the way. At conferences I attend, classes like test-first
development garner ever-increasing attendance, and polls to the audience
indicate that testing is much more common than it has been.
Shortened iterations
Shorter schedules and the need for better integration of customer feedback
shorten product development cycles, and also the smaller iterations within
those cycles.
4.1.3.1. Development processes and Java
Java's community and tools provide excellent support for agile development, but
there's a catch. Java is not such a good language for agile development. Java is not
the simplest of languages. Nor is it friendly to very short iterations. If these two
ideas are not clear to you now, they will be clear by the time you finish this book.
Other languages let you move from one change to the next without a cumbersome
compile/deploy cycle. Other languages have a more expressive syntax, and other
frameworks take you to a higher, more productive level of abstraction.
Even as we begin to understand that Java is not the most agile language, those
using other dynamic languages are using agile techniques like automated testing to
shield them from the problems related to programmer-friendly type and exception
strategies. Java's founders believed that it's always better to catch potential bugs at
compile time. They did not consider that features like static typing and a heavy
emphasis on checked exceptions come at a cost.
If we were to choose a language based on the development methods that we value
today, Jav

a would almost certainly not be our language of choice. As the principles
promoted by agile developers become prominent, the Java language will
experience increasing pressure.