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. . 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. 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. 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