Java is not the new COBOL

If you Google “Java is the new COBOL” you’ll find a glut of articles proliferating this mantra. I don’t know its origins, however I’m inclined to think it’s mostly repeated (and believed) by the Ruby community. Ruby, from a developer’s perspective is a low-friction language. A developer can just sit down at a text editor and start banging out code without really thinking about such superflous things as types. Java on the other hand, well, you have to think a lot about types. Java is a statically typed language after all, and it makes the developer do all the heavy lifting.  That alone may answer your question as to why us Java devs think IDEs are so important.

Back when a lot of Java developers switched over to Ruby, Java was a bit stagnant. We hadn’t really seen much happen with the language, and anyone who has written a Swing application can tell you: Anonymous inner classes make your code 5x bigger than it should be. The point being: there’s a lot of boilerplate code present in a typical Java application and this type of code has nothing to do with the application/business logic you’re trying to implement.  It’s just language cruft.

So, I can see why one would have been inclined to say that Java is like a modern COBOL. It had the following characteristics in common with COBOL:

  1. The language is verbose
  2. The language is stagnant
  3. Only big stodgy Enterprises use it

Well, I’m happy to report that these are no longer the case.  Let’s address the issues at hand one-by-one shall we?

Verbose & Stagnant

The cure for these problems lie within a combination of the features found in Java7 & Java8.  Java7 addresses a lot of issues with verbosity, while Java8 pushes the language forward into adopting new paradigms (namely Functional Programming)

Java8 is really a turning point for Java, and shows that Oracle is actually serious about evolving the language while championing it’s proliferation while maintaining backward compatibility. Oracle can’t just gut the language and then post a meme to github to justify itself.  It’s a bit more mature than that.

Java7 addresses verbosity

As Mark Reinhold, chief architect of the Java platform said: Java7 is evolutionary, Java8 is revolutionary. With Java7 we gain some nifty features from Project Coin, a project which  set out to determine what language features could be added to improve developer friction and language readability without being all too complicated to add. Here are some of the features I’m looking forward to:

A switch statement that I’ll actually use

Yes, finally my Java brethren we have a switch statement that actually works on Strings!

switch (lang) {
   case "Java" :
      out.println("I like frameworks!");
   case "Ruby" :
      out.println("I like Pabst Blue Ribbon!");
   case "PHP" :
      out.println("I like WordPress!");

My God this has been a long time coming.

Type Inference: Yes, I REALLY DO MEAN Map<String, List<String>>

One of the reasons I like Scala is it’s ability to infer types.  This is such a pain-point in Java, when you use a highly complex parameterized type, both your carpal tunnel flares up and you’re eyeballs want to bleed.

So this:

Map<String, List<String>> peopleByDept = new HashMap<String, List<String>>();


Map<String, List<String>> peopleByDept = new HashMap<>();

They call this enhancement the “diamond syntax” as you are leaving out the types on the RHS of the expression and replacing them with a diamond <>.

I won’t go over all the nice little character-reducing features of Java7, Dustin’s Inspired by Actual Events JavaOne 2011 keynote post does an excellent job, there’s nothing more I could add really.

Java8 Moves the Language Forward

What do we get with Java8?  The two major features are:

  1. Lambdas / Closures
  2. A proper module system (aka Jigsaw)

I’ll only address Lambdas here because the module system is more an “in behind the scenes” feature. In my opening paragraph I spoke about how Anonymous Inner Classes cause so much bloat in a Java application.  Lambdas pave the way out of that mess.
For example…

Component button = new Button("Click me!");
button.onClick(new EventHandler() {
   public onEvent(Event e) {
      out.println("I was clicked!");

We’d write, using Lambdas (look ma! no types!):

button.onClick(e => out.println("I was clicked!"));

I like!

Cool Companies use Java too!

Is Java used in the Enterprise? Absolutely.  However Apple, Twitter, LinkedIn, SquareSpace are all committed to it too. These companies are the antithesis of the stodgy Enterprise.  Through JRuby, Jython, Scala and Clojure companies like these plus countless startups can both directly and indirectly use Java by means of leveraging the vast open source ecosystem written in Java.


Given the above facts I think you’ll agree, Java is not stagnant, it’s getting much better on the eyes and fingers and it has been adopted by cool, non-stodgy companies. Then perhaps you’ll also agree it’s wrong to say Java is the new COBOL, just as wrong as saying Ruby is the new Java.

Author: craig

Share This Post On


  1. You know, the String used in the switch() is the first thing that excited me about Java in a long time…

    Post a Reply
  2. I would add Google to the list of cool companies that use Java. And I’d also add that Java EE 6 was a huge step towards removing architecture cruft. The days of Java 1.4 and J2EE are long past. But many people outside of the Java camp are not aware of that yet.

    Post a Reply
  3. Well Java 7&8 are too little too late.

    Most enterprises and other big companies only use Java 2 or 3 afait and frankly that is where most java code is written and maintained.

    “Cool Companies use Java too!” nope they use the JVM with JRuby, Jython, Scala, Clojure and other such languages targetting the JVM.

    Map<String, List<String>> peopleByDept = new HashMap<>();

    is still pretty verbose.

    Lambdas arent a new invention so why did it take Java so long to incroporate them? Iirc even COBOL had something like them. (Inline functions/procedure)

    And here is the main flaw of Java: it isnt growable.

    Post a Reply
    • Well Java 7&8 are too little too late.

      Most enterprises and other big companies only use Java 2 or 3 afait and frankly that is where most java code is written and maintained.

      This is not really an argument against the premise of the post. If Enterprises can’t keep up with the JVM is not Java’s fault.

      Map<String, List<String>> peopleByDept = new HashMap<>();

      is still pretty verbose.

      There is no escaping the fact that Java is a statically typed language. In Scala you’d still end up with:

      val peopleByDept = new HashMap[String, List[String]];

      Type inference is unfortunately not at the level of reading minds (yet).

      And here is the main flaw of Java: it isnt growable.

      In my mind you haven’t proven this, you’ve only stated “too little too late”. People like to knock Java for being stagnant and out of date, but when it starts to adopt more modern concepts the same people fault it for doing so. Both positions are orthogonal. Or put more plainly: haters gonna hate.

      Post a Reply
  4. So Java 1.5 is basically going to be obsolete, and there is new language (1.7) very similar to Java.

    Post a Reply
    • Well, kind of. Your Java 1.5/1.6 will be backward compatible by the newer JVMs. New syntax added, old syntax still supported.

      Post a Reply
  5. Nice koolaid. But the fact still remains that Java is too verbose.

    I think some people love to spurt out millions of lines of code but you know, smart people realize that LESS IS MORE.

    Java does not understand this but it is ok. It will slowly fade to irrelevance.

    Post a Reply
    • Java does not understand this but it is ok. It will slowly fade to irrelevance.

      If that does become the case, then the title would still apply, albeit for different reasons. COBOL is still very relavant in today’s enterprise and will continue to be for many decades to come.

      Post a Reply
  6. Functional programming is an awesome enhancement to java, and is a long time overdue. The excitement around the switch statement though feels like a bit of oracle hyperbole.

    Without regex its just very limited in practical situations, and compared to scala’s pattern matching it’s infantile.

    Post a Reply
    • True, once you use a language with sophisticated pattern matching it is really tough to program otherwise.

      Post a Reply
  7. I’m confused. I always thought the “Java is the new COBOL” idea meant that there’s a huge source code base in production that needs to be maintained.

    It makes sense to me: all these projects back in the end of the 90s are now legacy code. It’s not that Java is dead (as COBOL), but from the professional point of view maintaining all that code it’s a good opportunity.

    Post a Reply
    • Yes, you’re right, the “Java is the new COBOL” isn’t about the language(s), but about the idea that both became business standards, are used in computation and reporting a lot, control the business main databases and as such become crucial to the business activity that they become irreplaceable, and would continue to lay there for ages and ages while their programmers become older and older.

      Aside, what this post claims to be “moving forward” is the same as what COBOL’s been doing for the past 30 years, patch a new paradigm on the existing, unbreakable syntax, hammer it on a bit, ignore the ugly corners and move on. The same as C#/.NET, only that C# is slightly more lenient in allowing for syntax addons.

      Post a Reply
  8. “However Apple, Twitter, LinkedIn, SquareSpace are all committed to it too. These companies are the antithesis of the stodgy Enterprise.”

    No, they aren’t.

    Post a Reply
  9. If those are the only similarities you can find between Java and COBOL, you might want to take a long hard look at yourself.

    Post a Reply
    • Please Bob, enlighten us to the other similarities.

      Post a Reply
  10. Java is the new Cobol. Your examples show that you can write fancier some code that was ugly in the past. That yet did not changed automatically the old code to use the new paradigms. In fact even Cobol have a lot of features, some really much more impressive than adding Generics to Java, like described in Wiki page:
    Your application have a desktop client? Does it use JavaFX or most likely AWT or Swing!? Do you have old code, does it use JSF, sometimes JSP, or always lightweight, Rails like frameworks?
    Java may be today with different runtimes, but the old non-generic code with non diamond notation is still around. In fact, ALL code before 2011 do not have this fancy stuff, but is COBOLesque by your description.

    Post a Reply
  11. You don’t get it, do you ?

    Java *is* the new Cobol. This has nothing to do with technical prowess, but with the community.

    Everyone and their dog can write java programs. Most especially their dogs. 90% of all java programs are written by morons, which is normal, since 90% of all programmers are morons.

    As a result, most java programs are clunky procedural shit, a mix of procedural mind-numbing “enterprise-ready” code, automatically-generated UI nightmare, and eventually, a few more bugs for good measure.

    You can try to change the language, you won’t change the community… same as Cobol, really.

    Post a Reply
  12. WTF String in a switch statement ? Why ? I never miss this. I’m using Enums.

    Post a Reply
  13. For the people who don’t hate Java.

    Check out this library for reducing Boilerplate:

    Not only are the existing features great, but the community surrounding it is very active and very supportive.

    Post a Reply
  14. I do Java for Android development, because I have to. When I write code for fun, I use Python.

    Python offers far more expressive power than Java—functions as first-class objects, user-definable operator overloads, generator functions, list comprehensions,functions returning classes—and yet its language definition is still only about a quarter of the size. Java will never be able to compete with that.

    Post a Reply
  15. What about language support for collections? That’s one of the most important things that makes scripting languages code much readable and shorter than java. They promised it will be part of Java7 but postponed to java8. For me that’s more urgent/important that Strings in switch (I still don’t see the big deal there).

    I don’t see Oracle’s seriousness and/or willingness to change the language.

    Post a Reply
    • And I’m not entirely sure we get Collection literals syntax in Java8 (I’ve not seen any info about that). The last I heard it was part of Project Coin, but then got knocked out of scope.

      It would be nice to say:

      List myList = {"Hello", "World"};
      out.println(myList[0] + " " + myList[1]);

      Instead of using all the accessor methods, that’s for sure!

      Post a Reply
  16. I’m always amused by these religious wars…

    Craig, while I don’t share your enthusiasm for String-switch statements and the diamond operator (those are really kind of trivial enhancements, so I’d rather skip Java 7 and all the upgrade hassle), I’m really excited about Lambda expressions and virtual extension methods to come. Now, everyone knows those features have been around for ages in those very fancy and fly new languages. True. So what? They’re utterly unavailable in one of the most popular yet simplistic languages: PHP. Nevertheless one of those “fly” companies uses it: Facebook. I bet, PHP developers wouldn’t mind lambda expressions (as well as generics, etc) either. Heck, they had to wait ages for subtype polymorphism, a trivial feature of OO languages, nowadays.

    So please, guys. Could you all stop reducing a language to its syntax and/or style??? That’s just one aspect of a language/platform.

    Post a Reply
    • I’m sure the PHP folks get their fix of functional programming by using JQuery.

      My point is… Java is better with Project Coin features than without. The diamond syntax, you could argue, has been given to us by IDEs like IDEA for quite some time via auto-complete and code folding.

      Post a Reply
  17. I have to say the features are nice but its not anything I can get excited about any longer, there’s a multitude of languages out there that carry some or all of these features for ages already. I can not be excited about a crippled version of function pointers or an optimalisation that is just on the syntax level (lets face it, switch on a string is just a compiler issue, basically what java is most likely to implement is the following:


    Post a Reply
    • You could switch on that value, but you couldn’t setup a case statement to save your life that would pass the compilation phase. The values expected by the case keyword need to be literals or finals (I believe)

      Post a Reply
      • Or use a hashmap to find the blocks to execute, provided that blocks are objects (lambdas).

        This solution wouldn’t require strings to be literals nor finals.

  18. The original criteria
    The language is verbose
    The language is stagnant
    Only big stodgy Enterprises use it
    is a straw man created to prove the point of this article. So lets focus on the more salient points, one and two.
    1. The language is verbose – project coin did almost nothing to address verbosity. Java 7 code size is epsillontically smaller than in Java 6. Verbosity is intrinsic to Java:
    Reified Types? – don’t have them, which makes templates difficult or impossible to benefit from in most cases.
    Enums? – hobbled, even more so by JPA’s lack of flexibility w.r.t. enums.
    … and the really big code savers?
    Polymorphism? – nope
    Multiple inheritance? – nope.
    Multi-File Classes

    Java developers will continue to find that just about any way they can imagine to write compact code is in some way or another forbidden by Java. This is what the Java designers wanted, a programming language that limited sophistication in favor of simplicity. Can we think of another language designed using the same principle? That’s right, COBOL. COBOL’s designers were told to create a language that any high school graduate could master, and so was born the original oversimplified insanely verbose language.

    1. The language is stagnant – the language IS virtually stagnant… not much to argue about there. A fair counterpoint may be that the available libraries continue to evolve.

    Clearly, Java is the new COBOL. I only hope that Oracle will bring sufficient vision and investment prove me wrong.

    Post a Reply
    • Toast, I do agree with most of what you’ve stated, for instance type erasure *sucks* and was basically a tactical solution to introduce generics to a language that didn’t have them, but wanted to maintain backward compatibility.

      However, I’m not entirely sure what you mean by Java not supporting Polymorphism… Sure it doesn’t when it comes to polymorphic functions consisting of generics in their prototypes, but it does with signatures consisting of concrete types.

      Java8 will do a lot to cut down on verbosity. Instead of hacking in full anonymous inner class definitions right smack dab in the middle of our code, we’ll be able to just pass in a code block via lambda syntax. We’ll also get a “kind of” multiple inheritance via Defender Methods.

      So I think it’s unfair to say the language is “virtually stagnant”, it’s coming a long way considering all the backward compatibility issues it needs to contend with. This issue will start to plague Scala as well, up until now they broke binary compatibility at the drop of a hat. However now that we have Typesafe, they’ll need to keep their enterprise customers happy by playing nice with backward compatibility…

      Post a Reply
      • Hi Craig, I can see how my comments could be taken as a wholesale rebuke of Java. That is more an unintentional consequence of making the point that Java is *supposed* to be the new COBOL rather that my feelings on Java. Java is a nice language… though a frustrating one at times; and as I alluded to, the libraries are usually outstanding.

        A lot of hard work went into Java 7, and it actually feels a little different than 6, but I am under the impression that 7 mainly prepared the ground for improvements to come… which contributes to the overall feeling of slowness in progressing the Java core.

        So how to characterize the situation? The libraries moving along at a reasonable pace, the core perhaps not virtually stagnant but slow to progress.

        My bad, polymorphism IS supported pretty well through interfaces, though this is where multiple-inheritance and/or better template support could have made it easier to cut down on code.

        I look forward to Java 8’s lambda functions and defender methods. I hope they deliver a snappy, faster paced development experience.

  19. I’d just add that actually, that’s not full type inference – it’s merely the generics that are inferred. Contrast with the C# Var X = (Or VB.Net Equivalent which omits a type… Dim X = )

    By placing the inference on the LHS, not the right, you can get the full type inferred. There’s also no risk of losing track of what your type is as

    A) That’s why you’ve got an IDE
    B) Its type will be checked when you attempt to use it in any way.

    I admit I’m coming from the POV of a .Net developer who’s currently required to maintain a Java app – so I’m biased – but even the “new improvements” in Java still feel like a step backwards to me.

    Post a Reply


  1. let x=x › case “String” – still FAIL - [...] Java is not the new COBOL | Craig Tataryn’s .plan: A switch statement that I’ll actually use Yes, finally…
  2. Java is not the new COBOL | Craig Tataryn's .plan | F1 Help - [...] Excerpt from: Java is not the new COBOL | Craig Tataryn's .plan [...]
  3. Java是新的COBOL吗? - 博客 - 伯乐在线 - [...] 英文出自 分享到: [...]
  4. Java是新的COBOL吗? | IT & 数码 - [...]   英文出自 [...]
  5. Lambda Expressions in Java8 – Perhaps not as sexy as intended? | Craig Tataryn's .plan - [...] my defence of Java, one of the features I looked forward to in Java8 was the introduction of Lambda…
  6. The Basement Coders Developer Podcast » Episode 49 – Paperless Offices & Java is not the new COBOL - [...] we discuss an article I wrote titled: Java is not the new COBOL. As you can imagine, there were…
  7. Java是新的COBOL吗? – 好工作博客在线 - [...] 英文出自 [...]
  8. Is Java (still) a good language? « blog - [...] in 2007, people were already calling Java “the new COBOL”. Of course, there are also arguments directly against this,…
  9. [热议]Java是新的COBOL吗? | 乐无忧 - [...] 英文出自 [...]
  10. Java不是新的COBOL | ImportNew - [...] Java不是新的COBOL 英文原文:Craig Tataryn,编译:ImportNew - 郑玮 [...]

Submit a Comment

Your email address will not be published. Required fields are marked *