Online Book Reader

Home Category

Beyond Java - Bruce Tate [31]

By Root 674 0
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.

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.

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

Return Main Page Previous Page Next Page

®Online Book Reader