« Chapter 3 [Java's Technological] Crown Jewels | Main | Patterns Of Enterprise Applicaton Architecture (by Martin Fowler) Chaper 1 and 2 »

Chapter 4 [Why Java Now Sounds Like] Glass Breaking

Java is now in danger, it's getting too difficult to manage, and both evolutionary and revolutionary steps to remedy the problem are failing us. The basic problems.

4.1. Java's New Job Description


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.

Java is now in danger, it's getting too difficult to manage, and both evolutionary and revolutionary steps to remedy the problem are failing us. The basic problems.

4.1. Java's New Job Description


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.


4.1.1. Typical Requirements


  • Java's become indispensable for writing middleware, the systems software that fits between an application and an operating system.
  • For servlets and web programming in general, Java needs a faster feedback cycle, and needs to get better at managing strings.
  • 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.
  • For large enterprise projects requiring things like distributed transactions across multiple resources, heavy legacy integration, and code that relies on niche libraries ,


The most common Java job is to take a big, fat relational database and baby-sit it with a web-based user interface.


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.


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.


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 *Automated unit testing
  • Shortened iterations

4.2. Basic Java Limitations


  • The many frameworks designed to simplify the Java development experience do make experienced Java developers more productive, but make the learning curve too steep for those new to Java.
  • Compile-time checking of exception and types adds safety, but comes at a cost of additional time and syntax.
  • Java's inability to express structured data leads to an over-reliance on XML, with the corresponding additional complexity and bloat.
  • Java's many compromises, like primitives, make Java harder to learn and more complex to write.
  • Java is more dynamic than C++, but is nowhere near as dynamic as languages like Smalltalk and Ruby. Java developers are finding metaprogramming, but they're not able to execute on those ideas fast enough.
  • Java's long compile/deploy cycle is much longer than interpreted, dynamic alternatives.

Taken alone, none of these issues hurts enough to matter. Taken together, Java becomes much less productive for most developers.

4.3. Typing


One of the most fiercely debated topics in programming languages is the benefit of strong, static typing strategies. Java's strategy opts for as much compile-time checking as possible. Let's take a quick overview of programming language design, in layman's terms. Then, you can put Java into context. When building a language, a designer needs to answer two typing questions relatively early in the design process.

  • Strong Versus Weak Typing

    • Static Versus Dynamic Typing
    • Syntax
    • Thought Process
    • Code/Compile Cycle
    • Adaptability
    • Generics
    • Overloading
    • Other Costs

  • The Benefits of Static Typing

    • Static typing reduces certain types of errors
    • provides more information for your IDE and other tools

  • A Safety Net with Holes

    • Primitives

      • Primitives Are Limited
      • Primitives Are Unnaturally Verbose


  • The Big Trade-off


4.5. Parting Shots


  • Sun - Sun is not the company that it once was, placing Java's future in doubt. It's being squeezed on the low end by companies like Intel, Dell, and AMD. IBM is squeezing Sun from above.
  • Exceptions - Like static typing, Java's emphasis on checked exceptions seems like it's on unshakable footing.
  • Expressing Data - Programming and data go hand in hand. In most other languages, structured data becomes a natural part of an application. Part of Java's over-reliance on XML comes from its limited ability to express structured data.
  • Strings - Java, ylacks convenient, high-powered text manipulation, when it's a core job that we ask Java to do. Servlets, XML, JSP, HTML, and many other constructs are strings.
  • Simplicity - Java's already a good language for big, hard-core enterprise programming projects. It's getting better at solving that problem. And Java's never been good at tiny applications.
  • Tools - One of the symptoms to this problem is Java's over-reliance on tools. We Java developers love our IDEs. The truth is that we can't live without them. But,You simply need an IDE to do any real degree of refactoring.

Why Not Just Fix Java?


Most experts that I interviewed tend to think Sun is even now moving in the wrong direction. Instead of making Java more nimble and dynamic at the foundation, the changes, for the most part, amount to additional type safety—syntactic sugar hacks built into the syntax rather than the JVM that often lead to inconsistent behavior.
4.6.1. Libraries and Community
It's clear that libraries are problems, too. Sun has launched several belated simplification movements. So, if it's Java's libraries that are broken, and not the language itself, couldn't we just scrap a few libraries and start over on a more simplified foundation? That's the approach we suggested in Better, Faster, Lighter Java. For Java's most important and basic job, a web-based user interface on a relational database, I don't think Java's frameworks are moving in a healthy direction at all.

4.6.2. Alternatives


Five years ago, most developers that I talked to on a regular basis wanted a good way to baby-sit a big, fat relational database with a web-based user interface. Five years later, they want the same thing.


Java is drifting away from its base.