Is Java the new COBOL? Yes. What does that mean, exactly? (Part 1)

"If you want to know the past, look at your present. If you want to know the future, look at your present." -- Gautama Buddha

Java is the new COBOL, whaaaat?



    If you are software developer that mainly writes applications for the web; even if you aren't a Java/J2EE developer, you have probably heard the new meme circulating the web and blogosphere. "Java is the new COBOL". Most blogs and technical writers regurgitate that statement and follow-up by saying that EJBs suck, and some companies are considering Ruby on Rails. I didn't really think much of these posts. I get the impression that a lot of these "managers" don't write any Java or COBOL code. They are really not highlighting the seriousness of the problem. COBOL development has remained stagnant for decades. Java may see the same problem in the future. The Pentagon/DOD has a trillion dollar COBOL problem because it is so difficult to change their ancient infrastructure. Anyone who is exposed to the Java world will become frustrated with some aspects of the environment. The beginner will certainly become frustrated with the amount of work it takes to perform simple tasks like opening a file or working with Swing to create a small GUI application and they will find it much easier to perform these tasks in a language like Python. The seasoned developer will find fault with Java's stability or the complexity of the various web frameworks (XML hell). The programming language designer will find fault with all aspects of Java. I believe that the "Java is the new COBOL" is a politically correct way for saying "Java sucks". I won't disagree with those statements. I am not overly partial to any technology, I just want to get work done and find the technology that makes that work as painless as possible. As an added bonus, I want to ensure that my time is spent on a project is worthwhile. What is worthwhile? If I had a choice, I would much rather work on or learn more about the software used to work with the Phoenix Mars Lander [1]. The lander was sent 422 millions miles and the robotic systems must operate autonomously, sending data and images back to Earth. The software used to build this software is probably more complicated than what is on the other side of the spectrum, for example MySpace or a MySpace application. Some software is more complex, more interesting, and generally more useful than other software. I am sure that the JPL team had to plan for almost any contingency from the physical complexities of the Mars environment, from the hardware components as well as within the Phoenix's internal software components. Not everyone can or would want to work at the JPL, creating robotic software. There are always going to be different software needs and different requirements, but the software development community should make an effort to plan for contingencies and seek out the best technical solutions for their users. Does a Java architecture provide the best solution? Does a COBOL one? I guess depends on the requirement.

What about actual COBOL developers? What do they think?

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." -- Dijkstra, 1975 [22]


    What about critical applications like in the banking industry? Use your imagination to come up with the possible requirements for web oriented banking software for internal and external applications. These applications might need to keep up with credit-card, or debit-card transactions for online payments. They might want to store personal profiles of the users. Users will need to login into, register for, pay for and maintain their accounts. The application has to be secure and follow all of the SEC guidelines. Depending on the company, you might have hundreds of thousands of users with a running database that has been collecting data for 40-50 years. Imagine the number of transactions that must be logged in order to run your business. This activity must be logged and must be accurate 24/7. I can only imagine if I logged into my SunTrust account and my bank statement said I had $40 when I really had $40,000. There are issues with these systems and errors due occur, but they are kept to a minimum. Imagine the requirements for the external application used by members of the public and then imagine the number of internal applications needed to maintain the public facing tools. You could have log-monitors of the logs. You could have sophisticated, custom build tools. You could have custom requirements document management systems. I remember laughing and reading a recent article about DreamHost's billing issue. "On January 15, 2008, the billing system was mistakenly used to bill users up to December 2008." That couldn't happen for all of the users at Bank of America or SunTrust.

    Back to COBOL. COBOL was created in 1959 and is a mainstay of business programming in the finance industry. It is normally being used for the back-end and data processing work and various Java and .NET middleware libraries are being used to connect web interfaces to the running mainframe COBOL software. "In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.[4] IBM is one of the larger mainframe hardware vendors. So, if you hear about a mainframe shop, you can safely assume they are running a bunch of IBM hardware and software. There are still COBOL jobs available, there are still software and hardware vendors like IBM pushing their products. And it doesn't have to be an z/OS or AIX system. You can run SUSE linux on a virtualized LPAR (logical partition) or any other supported operating system all on the same machine. I don't understand any of the terminology and architecture of COBOL/Mainframe systems. Most COBOL (COmmon Business-Oriented Language) interact with large databases, that might include launching stored procedures and manipulating. A mainframe JCL (Job Control Language) script that will be placed on the queue and run as a job on the mainframe. It can compile and link a COBOL program and then execute the program.



    The listing below is a brief snippet of COBOL code, without spending much time with COBOL you can get a glimpse at why it isn't something one would consider to be a beautiful language.

00000-MAINLINE.
OPEN INPUT JCL-IN
OPEN OUTPUT JCL-OUT
PERFORM 1000-READ-MOVE UNTIL EOF
CLOSE JCL-IN
CLOSE JCL-OUT
GOBACK. 

1000-READ-MOVE.
IF NOT EOF
READ JCL-IN INTO WS-RECORD
AT END MOVE 'Y' TO WS-EOF
END-READ
MOVE WS-RECORD TO JCL-RECOUT
END-IF 

    Actually, these systems are fairly stable. Like I said before, a bank system has to run 24/7, collecting and manipulating data. In a J2EE/Linux/Unix environment, if the your JVM lock-ups or crashes due to memory leak issues or unforeseen NullpointerException bugs; normally you have to call someone, identify the problem and immediately get your server running again. A mainframe zSeries system may only experience a couple of minutes of downtime a year and all of your hardware sub-systems can be hot-swapped.

Why are you telling me this?

    That is COBOL. So, why isn't it used for new and exciting web-development today? It is obvious once you start working with the language. Here is a good explanation that a hybrid Java/COBOL developer told me; "It is too basic, there isn't a lot of new development or methodologies for COBOL. It isn't exciting to work with. COBOL doesn't have many modern web development libraries or frameworks". From my talking with a working COBOL developer, he wasn't excited about working with it. You don't even have to build any COBOL applications or look at any code, you can already tell that the language is dead. There aren't any new books being written for the language. There are no conferences or training. A COBOL program 10 years ago is written in the same manner that one is written today. The same methodologies are used, same best practices, etc. In 2008, COBOL could not keep up with the demand for the user's requirements. I can't say for sure (I haven't written or deployed any COBOL code either). User's want sophisticated web user interfaces and GUI applications, modern 3D games. A COBOL application is ok for moving 100 credit-card transactions from one database to a separate log history table but it is not the best tool to build a game like Halo 3 or software systems for the Phoenix Mars Lander (using my original example). Essentially, new development with COBOL is dead.

What about Java, is Java the new COBOL?

    I haven't taken a lot of the blogosphere seriously on the "Java is the new COBOL" meme because of the way that a lot of technology leaders frame the statement. The question is, "Should Java be used for new development and applications?". If you are a die-hard Java fanboy and your answer is yes under all circumstances; then you are doing a disservice to your users and your career as a technical professional. You are moving in the right direction, if your answer is no or maybe; you are dedicated to looking at:

• The various software technologies and evaluating them with a rational, objective analysis on how the technology can benefit your user's needs
• The available developer resources (this may include only one developer)
• The overall future maintenance of your application

What is wrong with Java?

"One does not accumulate but eliminate. It is not daily increase but daily decrease. The height of cultivation always runs to simplicity." -- Bruce Lee

    I won't add more to what has already been said about Java and J2EE, later I am going to post some of my favorite "Java Sucks" quotes. You might also see some misinformation on the blogsphere with their use of the term Java. Some use it to describe the Java programming language, some use it describe the entire Java platform. Some people even take it a step further to include Java the programming language, the virtual machine runtime created by Sun or other software vendors, J2EE (Enterprise Edition, including EJBs, Servlet Spec, JMS, JTA, etc), or any libraries built with Java. In my blog post, I am talking about Java-everything (including third-party applications) unless I specifically target the "programming language" or "virtual machine", for example. From some people, if they say "Java Sucks", you can always respond with; "Well, Sun's HotSpot just-in-time compiler is used to achieve great runtime speed. And just a note, some mistakenly criticize Java's(the JVM) performance based on Sun's early Sun's implementation. In 2000, Sun released the HotSpot VM with just-in-time complication which including much improved performance, compared to the bytecode interpreter released in 1995. [12] And Java is still used in many complex production systems. Plus, you are not always tied to using the Java programming language to write your applications. Many other programming languages run on the JVM, including.

• JRuby (The Ruby language on the java virtual machine) [9]
• Jython (Python on the JVM)
• Scala (A multi-paradigm (OO and functional programming) strongly-typed programming language [8]
• ABCL (Common Lisp)
• Clojure (A lisp implementation on the JVM

Interesting quotes about Java

• "The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python....frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages." -- Paul Graham [16]


• "What in the world is application-level crap like checkPrintJobAccess() doing in the base language class library? There's all kinds of special-case abstraction-breaking garbage like this. ", "Interfaces seem a huge, cheesy copout for avoiding multiple inheritance; they really seem like they were grafted on as an afterthought. Maybe there's a good reason for them being the way they are, but I don't see it; it looks like they were just looking for a way to multiply-inherit methods without allowing call-next-method and without allowing instance variables?" -- jwz on the java language [17]


• "Scala is a far superior language to Java...The status of “Java” has been artificially elevated by its groupthink members such that any attack or suggestion of inferiority is reviled, even if the suggestion is perfectly rational and able to be supported with evidence" -- Tony Morris, Offending Religiosity [18]


• "Static typing is limiting", "Arrays are broken", "A double-whammy when combined with static typing. There is this weird distinction between object types and primitive types", "Instead of adding expressive features to the language, the Java designers decided to focus on promoting code duplication, aka design patterns instead". "No REPL". -- Slava Pestov (November 21, 2004) [19]


• "WebWork, Tapestry, Spring, and pretty much every non-Struts framework users scoff and laugh at JSF. It’s ugly, it’s not intuitive, and it is hellbent on the Microsoft style approach; fuck the users and force them to use clever tools." -- Hani Suleiman, author of the BileBlog


• "Deployment is still the painful arduous hope-and-pray-you-get-a-helpful-hint process we’ve all come to know and love. The smallest hiccup will cause the server to flail about wildly, spewing error messages with a frequency that is only matched by the number of new pointless codehaus projects every week. The error message themselves are as delightfully whimsical as they’ve always been. Random ObjectNames, with tantalisingly empty ‘I depend on:’ proclamations. The ‘Depends on me’ of course still impressively manages to insist that ejb’s within a module depend on a seemingly random other ejb in a far flung module that has absolutely no dependencies to anything. Hot redeployment of apps that failed to start up doesn’t work worth crap, the stacktraces seem longer, and the whole thing just makes you run to your nearest j2ee vendor and beg them to let you fling cash at them just to stop the pain." -- Hani Suleiman on JBoss
  


• "Java desktop apps succeed only in niches where UI design and usability don't matter: development tools and enterprise software. Programmers expect things to be crude and complicated... and the poor users of enterprise software don't have a choice..." [27]
  

XML Configuration Hell

XML and property configuration hell does not plague all Java development, this is one misconception that permeates the blogosphere. If you aren't writing web applications, you can certainly avoid XML oriented frameworks. And if you are working with web applications, you can use lighter frameworks like Wicket. One of Wicket's selling points is a "refreshing lack of XML". But there is a certainly a tendency with Java web frameworks to be configured by needlessly complex XML configuration files. You can attribute some of this universal standard to Sun's default J2EE XML configurations. The J2EE web.xml, application.xml, WEB-INF/*. One or two simple system XML configurations are not bad. But, you start to enter XML hell when you want to combine technologies. By default, you have to deploy a web.xml, application.xml. If you are using and combining common frameworks like Struts2 MVC, Hibernate ORM and Spring2, Log4j, JSF, Google Web Toolkit, Axis you could have one to many different configuration files per framework. Essentially, you could have a minimum of five or six different configuration files to setup even the simplest web application (if you mistakenly use those frameworks). The practice of over-engineering every solution is very prevalent in the Java community, this is why some may consider Java to be the new COBOL. COBOL was so stuck to its niche that it couldn't really evolve to match the ever changing software world. It wouldn't make sense to provide COBOL web portals or portable GUI applications even though the back-end systems were originally developed in COBOL. Java is falling into the same trap. Why should a developer have to waste time worrying about five to six hundred line configuration files, on top of a poorly designed, inconsistent Java API when web frameworks like Rails or Django can accomplish similar tasks in twenty or thirty lines of code? More code means that more things can go wrong.

Web 2.0 and New Requirements



    Grace Hopper, the author of COBOL, helped standardize programming languages used by the Navy to integrate incompatible embedded systems. Hopper helped build many of the Navy's onboard computers; "Hopper was tasked with developing a program for shipboard ADP equipment support, building compilers for shipboard minicomputers was a major part of her workload". [15] Web development is not the end all of software development, but a lot companies understand the benefits and safety net associated with this ubiquitous style of computing. And a lot of companies and users don't just want a basic MVC-1 database driven application. They want more, they want applications that interoperate with other successful services. For example, the popular web application Yelp.com [14] contains user-driven restaurant and business reviews in and around large cities. The application also links the location of these businesses with google maps. You can pinpoint on a particular restaurant and if you don't like that restaurant, you can highlight similar restaurants in the area on the map.



    These are the new wave of applications that users are wanting. They have seen it done and they want more of it. Is Java capable of keeping up with new requirements? Are other languages and platforms better and easier to use to meet these software demands? Here are just a couple of applications that are being developed in the Web 2.0 world. And yes, the term Web 2.0 doesn't have any real meaning; it is yet another tech buzzword created by the consultants and trade magazines to describe trendy software technology. Essentially, these software problems are not complicated and certainly not new.

• Ajax and JS Widget Support
  
• Wiki Sites
  
• Web Forums
  
• Portlets
  
• Mashups
  
• Social Networking and User Driven Applications
  
• Web Services
  
• Semantic Web (E.g. FOAF)
  
• Rich Internet Applications
  
• Cloud Computing
  
• Clustered Applications

*GASP* Where are the libraries?

    Building modern web applications around the Java platform is skirting on the edges of web-development, programming, and network administration. I don't think the term Java programmer is an accurate term to describe a Java developer's functions and workload. Java developer's aren't always programming to put together an application for the user. I was once tasked with converting HTML output to PDF documents. Most of the work involved finding good opensource libraries that supported at least HTML4 tags, XHTML and CSS. Most of the libraries required an input HTML string and streamed the output PDF to a file or some other medium. There was a requirement and a need; I researched various tools and integrated the library with our web application. I didn't do much programming. A lot of Java work follows a similar work flow. Traditional programming is not always required. How do you add Lucene full-text search to your application? Add Lucene to your classpath, come up with strategies for indexing your documents, provide text edit box for user's to query the system and you are essentially done. Once again, programming is not required for you to add this functionality. Let me say it another way; imagine if the Lucene library wasn't available and you still needed to provide full text search. If you wanted to build a search library, more programming work will be involved building the API then using an existing one.

What about the other Programming Language Alternatives? Could you use more than one General Purpose Language in your Architecture?

(Actually, to say languages like Lisp, Scala and Haskell are alternatives to Java is kind of an insult to these technologies. Java is really a corporation inspired alternative to existing software systems that garnished a lot of momentum over the last ten years.)

    One thing I never understand about the Java group-think community is the fear of integrating new programming languages into their environment. At a minimum, most Java web developers have to work with Javascript, XML/XSLT, HTML/XHTML, SQL and Java itself, sometimes even C/C++. Designing an application with one or more general purpose languages is not totally a foreign concept. Twitter attempted to solve some of their scalability issues by integrating their Ruby on Rails web platform with Ejabberd Jabber/XMPP server as their instant messaging platform. Erlang is the most widely used programming language that has been known to use a message-passing concurrency model. [21] Erlang is strong at parallel, distributed applications. If your requirements change or you see an increase in demand that your current set of resources can't meet, then shouldn't investigate other options. Other programming languages? Here are just a dozen or so stable languages that have vibrant developer communities and capable libraries that can even be used for enterprise development:
Popular and Mature Modern Programming Languages

• Python/Jython
  
• Ruby/JRuby
  
• Erlang
  
• Haskell
  
• Scala
  
• Clojure
  
• Smalltalk/Seaside
  
• Lisp (Common Lisp/Scheme; SBCL, CLisp, PLT Scheme)
  
• Factor
  
• OCaml
  
• F#

To boldly go where no man has gone before, The Enterprise



    The requirements for web development are not going to change and will increasingly get more complex. In defense of the Java developer, he may believe that his only option is to architect his application with a J2EE platform because the application server may have all of the libraries that he or she needs to complete his requirements. Normally, this is not the case. He probably doesn't need JCA, JMS or all of JAAS or EJBs. Yet, a compliant J2EE server will provide all of this whether you need it or not. But, if the enterprise developer is considering new languages and platforms, he might need a minimum set of libraries. If we go back to the requirements of the online banking software; you aren't going to consider a web platform that doesn't support HTTP over SSL. And you probably don't have the resources to implement SSL yourself. Most modern languages have some of the features listed below. They are mature and have been a part of the language for years. If the language doesn't have the particular feature, there is nothing preventing you from using a combination of general purpose languages in your architecture.

Some Typical Enterprise Requirements

• Mature IDE (E.g. Eclipse, RAD, IntelliJ IDEA)
  
• Unicode Support
  
• Stable XML Parsing Libraries
  
• Database drivers (E.g. JDBC)
  
• SSL support and Security platforms (E.g. JAAS)
  
• Email Libraries
  
• MVC Web Frameworks
• (Soap, REST, RPC) Webservices libraries
  
• Search (E.g. Lucene)
• Legacy communication libraries (E.g. JCA, CICS, POS
  
• Chart generation libraries
• Image manipulation libraries (E.g. JAI)
  
• Scalable - handle an increase in users or demand
  
• Good Speed Performance
  
• Technical Support?

Conclusion

    So the question for the 2008 age developer is this; to all the millions of one language Java developers that are out there, are you going to continue to only work with the Java language and platform, five, ten, twenty years into the future? Are you going to consider the alternatives? Do you think your users might benefit from other technologies? And I am sorry but if the answer is no, fear of change is not the most adequate response. I have been reading a lot about Richard Stallman, the free software advocate. He has one central theme that he uses to defend his free software movement; free software is not about the developers, it is about the users. If you are dedicated to providing robust software, wanting to make a lot of money is not going to be one your goals. It really boils down to what you want to accomplish as a software developer. Is your goal to defend some programming language religious ideology or provide useful computing applications to users and the software community?

References
[1] http://phoenix.lpl.arizona.edu/
[2] http://www.cnn.com/2008/TECH/space/05/26/mars.lander/index.html
[3] http://en.wikipedia.org/wiki/DreamHost
[4] http://en.wikipedia.org/wiki/COBOL
[5] http://en.wikipedia.org/wiki/LPAR
[6] http://en.wikipedia.org/wiki/Job_Control_Language
[7] http://en.wikipedia.org/wiki/Java_Virtual_Machine
[8] http://en.wikipedia.org/wiki/Scala_%28programming_language%29
[9] http://en.wikipedia.org/wiki/JRuby
[10] http://en.wikipedia.org/wiki/Jython
[11] http://en.wikipedia.org/wiki/HotSpot
[12] http://en.wikipedia.org/wiki/Star_Trek (Image from wikipedia)
[13] http://www.sun.com/smi/Press/sunflash/2000-05/sunflash.20000508.3.xml
[14] http://www.yelp.com
[15] Grace Hopper: Admiral of the Cyber Sea", Kathleen Broome Williams 2004
[16] http://www.paulgraham.com/gh.html
[17] http://www.jwz.org/doc/java.html
[18] http://blog.tmorris.net/offending-religiosity/
[19] http://vampteam.com/1/Why_I_dont_like_Java-posted-by-slava-pestov.htm
[20] http://wicket.apache.org/
[21] http://en.wikipedia.org/wiki/Concurrent_computing
[22] http://cadrlife.blogspot.com/2008/02/is-java-new-cobol-no.html
[27] In Which I Think About Java Again, But Only For A Moment

Footnotes

[23] A lot of developers have many suggestions for what and what not to teach in computer science. I recommend a course on the History of Computing/Software. I wouldn't have been so happy-go-lucky about Java and Fortran languages if I knew the entire history of software at the time.

[24] Why did you disable commenting? I am intentionally disabling comments. I don't want to get into the "Java Sucks", "Rails is awesome", "Lambda the Ultimate laughs at the Java community" argument. There are a couple of people that can bash Java and get away with. Slava Pestov (creator of Factor), Tony Morris (developer on ScalaCheck and works with Scala), Hani the Bile Blogger can get away with criticizing Java. They are fluent in the language and are great programmers. However, my blog post may encourage a bunch of wanna-be Rails fan-boys or Java drones to tell me how I have gone wrong. I had two goals with my post. First; I wanted to respond to the "Java is the new COBOL comments". Second; I wanted to understand why we use X or Y programming language. In some respects, I was talking to myself. Why Java? Why Lisp? Why Haskell? I know I probably have flaws in my posts and criticism is certainly welcome. Disabling comments will encourage healthy criticism. If you want to add something to the blog post or other comments, you can email me: berlin dot brown at gmail.com