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!
switch (lang) {
case "Java" :
out.println("I like frameworks!");
break;
case "Ruby" :
out.println("I like Pabst Blue Ribbon!");
break;
case "PHP" :
out.println("I like WordPress!");
break;
}
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>>();
Becomes:
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:
- Lambdas / Closures
- 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.
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.
23 Comments
Trackbacks/Pingbacks
- 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 ...
- Java is not the new COBOL | Craig Tataryn's .plan | F1 Help - [...] Excerpt from: Java is not the new COBOL | Craig Tataryn's .plan [...]
- Java是新的COBOL吗？ - 博客 - 伯乐在线 - [...] 英文出自：tataryn.net 分享到： [...]
- Java是新的COBOL吗？ | IT & 数码 - [...] 英文出自：tataryn.net [...]
- 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 ...
- 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 ...
- Java是新的COBOL吗？ – 好工作博客在线 - [...] 英文出自：tataryn.net [...]
- Is Java (still) a good language? « errantlinguist.com blog - [...] in 2007, people were already calling Java “the new COBOL”. Of course, there are also arguments directly against this, ...
You know, the String used in the switch() is the first thing that excited me about Java in a long time…
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.
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.
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.
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).
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.
So Java 1.5 is basically going to be obsolete, and there is new language (1.7) very similar to Java.
Well, kind of. Your Java 1.5/1.6 will be backward compatible by the newer JVMs. New syntax added, old syntax still supported.
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.
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.
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.
True, once you use a language with sophisticated pattern matching it is really tough to program otherwise.
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.
“However Apple, Twitter, LinkedIn, SquareSpace are all committed to it too. These companies are the antithesis of the stodgy Enterprise.”
No, they aren’t.
If those are the only similarities you can find between Java and COBOL, you might want to take a long hard look at yourself.
Please Bob, enlighten us to the other similarities.
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.
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.
WTF String in a switch statement ? Why ? I never miss this. I’m using Enums.
For the people who don’t hate Java.
Check out this library for reducing Boilerplate:
http://projectlombok.org/
Not only are the existing features great, but the community surrounding it is very active and very supportive.
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.
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.
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:
switch(“”.hashcode()){