Beyond Java - Bruce Tate [30]
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.
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 string 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.
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("\nHi, Mom\n");
}
}
True, this programming style leads to ugly code