Skip to main content

Is Java the wrong language for business programming?

Posted by johnreynolds on November 15, 2005 at 5:11 PM PST

Business needs applications that can be maintained long after the original coder is gone. Java is a great language, but does Java's richness lead to unmaintainable code?

This thought was prompted by a discussion with my colleague, Jim, who has managed large projects for many state agencies over many years. To paraphrase his statement a bit:

"COBOL programmers are interchangeable, Java programmers aren't"

This comment was made in the context of an effort to migrate legacy COBOL and Java applications to an enterprise-wide Service Oriented Architecture. Should we implement all future services in Java, or is COBOL still a viable option?

Jim is not a luddite, but he is tenaciously pragmatic. In his experience in managing large projects, he has found that any competent COBOL developer can maintain another programmer's code, but Java modules are often inextricably tied to their authors. Despite coding practices and design reviews, the Java modules take on the personalities of their owners. The nuance of each Java programmer seeps into the code that they produce.

You can write bad code in any language. You can write good code in any language. Is Jim's observation about Java and COBOL valid beyond his own personal experience?

I can't confirm that COBOL code is easy to inherit, but I can confirm that Java and C++ code is more difficult to inherit than assembly language**. When a language is tightly constrained, you tend to write code like everybody else. Is increased freedom leading to unmaintainable code?

Clarification: My comment about assembly language has caused a lot of confusion among some readers... I'm not suggesting that assembly language is appropriate for business programs, or that it's easier to write or maintain assembler than Java. I've just witnessed more variation in the programming styles of Java developers than in that of assembly language programmers.

Phil Murphy of Forrester Research recently dove into the issue of maintaining applications in his report:Java, COBOL, And Perl Share A Common Problem.

The report is not free to share, but the abstract sums it up:

"The wholesale loss of application knowledge creates most of the maintenance issues, whether the applications are written in Java, Perl, or COBOL."

Phil's telling us that the primary culprit of unmaintainable applications is the loss of knowledge about how those applications do what they are supposed to do, not the language that they are written in.

Let's try to rationalize Phil's findings with Jim's observation and see what we can come up with: COBOL is not a language that encourages abstraction. Java relishes abstraction.

It is relatively easy to inherit COBOL because what you see is what you get. Perhaps a boring narrative, but it has the advantage of leaving nothing to the imagination.

It is relatively hard to inherit Java because you have to comprehend the abstraction. It is like trying to explain a concept by using an analogy. If your listener shares your cultural background, an analogy can open the doors to greater insight. If your listener doesn't get the analogy, you may have slammed the doors to understanding shut. The wrong abstraction choices can destroy code maintainability.

"The problem" with maintaining Java code sometimes comes from "abstracting away" the business process and the business logic. We often use Java to write engines that execute business logic, not to write the business logic itself. In this model, the business logic itself is scattered across numerous configuration files (often written in some custom XML-ish dialects of our own design). Although in some ways an elegant approach, this coding style can be a real maintenance nightmare if executed poorly. If you can't step through the business logic in a debugger, then you probably haven't written a maintainable business application.

Back to my original question: "Is Java the wrong language for business programming?"

The answer is in how you use the language, not in the language itself.

Related Topics >>