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:

The language is verbose

The language is stagnant

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!

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.

Java8 Moves the Language Forward

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…

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.

Stereotypes…

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.

32 Comments

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.

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.

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.

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.

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.

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.

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.

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.

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:

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)

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.

Toast

July 2, 2012

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? – nopeMultiple 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.

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…

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.

Simon

February 25, 2013

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.