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
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.
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
Copyright: Tài liệu đại học ©