Over a million developers have joined DZone.
Platinum Partner

How many times are we going to "kill" Java?

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

Short answer: as many times as needed until polyglot programming really sinks in. Every day or so a new post on Java's demise appears, this has been happening for quite a while, but the truth is that Java (the language) has a lot of life in the years to come (after all COBOL and C++ are still around), the question is would still be the dominant language in the JVM?

To wit, here are some excerpts found recently, let's start with Harshad Oak from Kill The Java Language - A Message For Scripting Language Leads
At JavaOne this year I spent a lot of time following the scripting and dynamic languages space. The speakers for all these 'other' languages insisted that we had entered an age where developers would use multiple languages. They said that developers would select languages based on the nature and domain of the requirement.

Most also insisted that their language wasn't competing with Java and would compliment Java and be used along with it. Some of the leads also felt that developers need to get used to this paradigm shift as soon as possible.

I have serious doubts about this idea of simultaneous use of multiple languages. Most developers & architects that I know primarily work with one language at a time. If they develop a liking for a new language they might dump the old one and use the new language to provide all kinds of solutions.

I seriously dispute that. An architect must know well to a certain degree all pieces used to build the product. These days a web app mostly requires AJAX + WebServices, which means the architect must know some Javascript, XML (and it's micro languages), JSON and perhaps some proprietary database language, if not he runs the risk of designing into performance bottlenecks. He doesn't need to be an expert on all those languages but must take into account how they fuse together.

Harshad closes with the following
Similarly, all the scripting languages are being hailed as cool and promising for several years now. However the window of opportunity isn't going to stay open forever. Unless they move quickly they never will become a Java or a C++ and might start fading away once the current leads move on to other things.

My suggestion to all the scripting language leads, is to stop playing at being the Java language's best friend. You very well can be friends with the Java platform and the JVM but the Java language is not your friend. Aim at killing the Java language if you hope to ever make it big.

Again I digress here. I love Java, I code Java all day at my job and will continue to do so, but believe me the moment I'm able to use Groovy at work I will, and use it where it makes sense. The reason is simple in my mind: Groovy simplifies many tedious tasks that Java's verbosity makes hard, but I would never rewrite the whole product in Groovy, that doesn't make any sense. I would not do it because
  • Some components are legacy components and can't be changed
  • Some components are better expressed in Java.
  • Not all team members will switch to Groovy
Take for example GraphicsBuilder, a project where I'm free to make all the choices. Most of it is written in Groovy, I get to harness the power of simplified syntax and closures right away. But for custom Java2D shape classes I decided to use Java instead of Groovy for the following reasons:
  • The code aligns with the existing standard Java2D shapes
  • Perhaps in the future the shapes may be relocated to a non-Groovy related project
  • Lastly - better tool support at the time I created those classes
Playing the compatibility/synergy/polyglot programming card makes a lot of sense these days. There is no need to kill the previous king in order to get noticed and be popular, there is no need to be #1 just for the sake of being #1. If Groovy (or the other JVM languages) is a better solution for a particular problem then it will be used if the developer team is ready to embrace change (not an easy task I know but not impossible).

Harshad received some flame and later responded to clarify his point. Perhaps the message was lost in the form, it is clear that he likes Groovy and Grails, he has seen the advantages of putting them to work on real problems, but luckily his call to arms will not be picked up by JVM language leads. Except for the Scala camp enthusiasts that are still on that stage "Scala is the new Java, Java is dead", oh well, they'll probably get over it in a couple of months.

The next bit is from Dmitry Jemerov (full article can be found here), he leans on the opposing position, when asked about Scala support in JetBrain's IDEA he says
Honestly, I don't know any language today that would become the next big thing. Groovy is interesting, but it's a dynamic language and has all the problems of dynamic languages. It's OK for small pieces of code. But building something the size of IntelliJ IDEA [in a dynamic language] would be a complete nightmare.

Writing a full blown IDE-like application with just Groovy is crazy, same thing would be if you try with Jython, JRuby and Scala. It simply doesn't make any sense, there are some portions in that application where Java is more suited, again a single language approach is not giving you an edge. I bet there are some parts of IDEA that would be easier to implement with another JVM language (no matter if it is static or dynamic).

A statically-typed language is very much needed, but I can't tell what other language will fill the space Java currently occupies. Many people may not like Java for many reasons, and some of those people feel that Scala is going to replace Java in the niche of a statically-typed language.

I don't believe that, however: Scala is very complicated, it's tricky, and has a lot of surprises and edge-cases. I would say that Scala is at least as complicated as C++, and with C++ you need a hundred-page style guide before you even start writing C++ code, otherwise you'll end up writing C++ code that nobody will understanding.

That may be true, specially as the majority of Java developers only know how to program with the OO paradigm (some would say that is not even true), mix in the functional paradigm and you get a recipe for confusion. All I'm saying is that it will take time for the masses to assimilate both paradigms and put them to work, after all if functional programming were so easy to grasp for everybody we would be writing code in Lisp no? :-P

He concludes with
That said, Scala support is probably the most asked-for thing from us at the moment. But I don't think people ask for it because they use Scala today. People ask us to support Scala because they think that that is what they're going to use in the future, and expect that they'll need it. Whether they'll actually be able to use that feature [Scala support], I'm not sure about.

Which means that there is the perception that Scala may be the next big thing since sliced bread or since Oak was renamed as Java at the very least, but it still lacks the killer app other JVM languages that receive a lot of press already have. Scala has a Rails like web framework: Lift, but it has yet to live up to its namesake. Hopefully that will change in the coming months.

And if this year's JavaOne had a clear message from Sun I believe it was not "JavaFX (Script) is cool, it is coming, please bear with the prolonged delays", it was actually "the JVM is no longer a single language VM in our eyes", which is exactly what dynamic/scripting JVM languages leads have been saying for some time.

Enjoy the polyglot programming revolution!


The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


Published at DZone with permission of Andres Almiray .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}