Andres is a DZone Zone Leader and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

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

  • submit to reddit
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!

Published at DZone with permission of its author, Andres Almiray. (source)


Rick Ross replied on Wed, 2008/06/04 - 6:25pm

In many ways, I think the frequency with which we hear the death of Java proclaimed is testimony to its enduring relevance. Java is the big guy on the block, and the obvious target at whose expense each new contender hopes to achieve prominence. It's not so different from Windows, which is the obvious target for every would-be virus-writer and hacker. Java just seems to attract these premature obituaries!

Steven Baker replied on Thu, 2008/06/05 - 12:25am

I agree with Rick.

Alot of the Java bashing is just because its a big target. Most of this bashing can be directed at the other popular languages as well.


As for polyglot programming, I really hope it doesnt take off. In any size organisation, it simply complicates things, and I think this will become very much apparent when people actually jump on this band wagon of fail. 

Andres Almiray replied on Thu, 2008/06/05 - 12:52am in response to: Steven Baker

The point is that polyglot programming is already happening, and in fact has been happening since applications were run on UNIX servers (C/C++ + shell scripts [perl|python|bash,etc], but in recent years it has been more apparent due to the rise of webapps (html,xml,json,javascript), xml micro formats, svg. It is my belief that the new polyglot programming (Java+others) will really take off in approximately 1 or 2 years, once those languages get proper IDE support there will be less excuses to embrace them (from a team's perspective); from an enterprise perspective there would be enough discussion by then on why they may be useful for project X.

Ian Griffiths replied on Thu, 2008/06/05 - 1:14am

When I started programming 30 years ago, we looked down on COBOL as a dead language. Curiously, even today, I keep on coming across packages of millions of lines of COBOL with teams of dedicated developers keeping them alive. So even after al language is recognized as obsolete, it will live on for tens of years until the applications written in it are no longer useful. For a popular language such as COBOL, FORTRAN, C, C++, VB, etc. probably 50 years or so.

In the case of Java, the doomssayers started their work very early. Before version 1.0, in fact. Java would never catch on: it was only good for writing Applets, an interpreted language could never be fast, support for CORBA was inadequate, the memory model was corrupt, Swing was too slow and low quality, etc. etc.

In fact, it would be interesting to go through the archives of Javalobby to chart the reasons Java was doomed over the last ten years. Not only have these predictions been proved wrong, but their authors have been demonstrated to have little or no grasp of the dynamics of IT economics and decision making.

Java covers an enormous field in IT from smart cards, embedded devices, mobile devices, desktop and enterprise computing. It has had, has and will always have, shortcomings somewhere or other. These shortcomings may only be a source of doom a) if they are really serious and there are no workarounds, b) if they will not be corrected in a reasonable timespan, c) if there is a clearly better alternative and d) if the better alternative offers guarantees of being around for twenty or thirty years.

Despite this constant bickering, no language available today offers sufficient advantages over Java to make a move worth while. Of course, for specialized jobs, there are interesting alternatives (scriptin languages, etc.). There are also interesting experiments going on out there (f.e. Scala).

Today, if I have five million lines of Java code to manage, I can see no language that would justify using my budget to rewrite them rather than finance new functionality. I can not even find another language that would entice me to create a second pool of developers to write ne projects (that have to be interfaced with my main package). This does not mean that we don't use other languages, particularly scriptin languages, for special tasks and prototyping or even proving algorithms.

I think the day when Java is recognized to be outdated and unsuitable for new projects is a long way off. And even then, it will still be around for thirty years or more longer. 

Tiago Brito Spindola replied on Thu, 2008/06/05 - 1:51am

Let's be honest, polyglot programming??? Do we want to change languages like we change clothes? Does it make sense to use 3 or 4 different languages in the same project? I really don't believe it. It's already difficult to find people that know how to develop software in one language. Which language at the moment is able to offer a stack like Java does?


Arpit Agarwal replied on Thu, 2008/06/05 - 2:35am

I agree with Tiago. Come on! who the hell would like to make the code unreadable and hard to understand by writing it in more than one language. Really... i feel that its not a good option certainly when we are talking about mantainence of the project.

Gerhard Balthasar replied on Thu, 2008/06/05 - 3:14am

A classdefintion should abstract from the language inmh to provide an access interface for the object. In which languege it is written shouldn't matter. I mean, why not just allow any class content, which could be put into other files, if needed?



public class MixedCode {

    groovy {

        def x = 12
        println "$x"


    xml myXML = {



    properties me = { = "Help to get this working"


    public static void main(String[] args) {

        Properties p = Properties.load(me);
        //... this.x or this.groovy.x ?




If it would be supported by java natively like this, I would use groovy code porttions everday at my project.

Ayodeji Aladejebi replied on Thu, 2008/06/05 - 4:36am

Typically most modern Java developers know at least Java, Javascript, CSS, XML configurations based on various DTDs and schemas, HTML, SQL maybe some PHP, some groovy, some ruby, then JavaFX is coming, a little flex. Just how many languages will developers stack up in thier heads. And believe me, if you are in recruitment, you will realize how difficult it is to find people competent in all these.

Also remember that under the JavaHood alone are countless frameworks. Spring, Guice, GWT, Struts, Wicket, Tapestry ...and the list never ends and all these frameworks deliver efficiently at different ends. Infact these fantastic frameworks are the reasons Java's death will be really prolonged.

Meanwhile IDEs are playing a great role in polyglot . For instance Netbeans is the only reason I decided to even taste ruby, groovy and javafx. I think IDEs can also play a big role in the process

Mark Thornton replied on Thu, 2008/06/05 - 4:46am

Programming to interfaces with multiple languages is fine until something goes wrong. Then the bug is on the other side of the fence ...

 If all developers are comfortable and proficient in all the languages involved, then there is no problem. Otherwise you have to wait for the availability of someone who is prepared to cross the fence(s).

Maxim Zakharenkov replied on Thu, 2008/06/05 - 5:08am

To develop the discussion about the polyglot programming I've also created a separate post here:

Jesper Nordenberg replied on Thu, 2008/06/05 - 5:34am

Writing a full blown IDE-like application with just Groovy is crazy, same thing would be if you try with Jython, JRuby and Scala.

I don't agree. It wouldn't be any problem at all writing an IDE, or any other Java app, in Scala. Scala is statically typed language just like Java and they compile to virtually the same bytecode in many cases.

Serge Bureau replied on Thu, 2008/06/05 - 6:52am

I have to disagree with you Andres,


polyglot programming is a ridiculous idea.

Confusing and very hard to maintain and change.

Groovy is an interesting case because you do not really have to forget Java as it is an exrtension to it.


Even mixing XML/HTML and Javascript is an abheration to me. Ajax is the ugliest of all.

 All this mess is why we have today's gigahertz machines making us not much more productive than the first few megahertz machines, really pathetic.

Andres Almiray replied on Thu, 2008/06/05 - 12:23pm in response to: Tiago Brito Spindola

Java does not offer a stack per se, it offers a set (a very huge one) of libraries and frameworks. Many of the other JVM languages offer an easy way to call those libraries and integrate those frameworks. The other way around (Java calling the other languages) it is not so easy for some cases. That is precisely the point of JVM integration (and polyglot programming): reuse your Java (language) knowledge in libraries and frameworks but supercharge it with modern features and paradigm shifts (OO -> FP)

Granted, not everyone will jump into polyglot programming for reasons they consider vlaid given their context/constraints and that is ok, but It is my believe it will happen for many devs out there.

Steven Baker replied on Thu, 2008/06/05 - 6:04pm

Wow Serge Bureau! I agree with you so much!

Especially the comment about the hardware improvements not yielding much productivity improvements.


But if this were the real priority to companies, than we would all be coding in C or assembly...

Although, product development time/maintainability is a major concern to software companies, rather than the performance of the product developed. 

Peter Thomas replied on Fri, 2008/06/06 - 12:22am

To tick people off I'm going to refer to "PolyFlop" or "PolyGlop" programming from now on...


Now back to work 

Tiago Brito Spindola replied on Fri, 2008/06/06 - 3:27am in response to: Andres Almiray

Well, Java is a platform ( where others can build on top of it. Only with a language in the hand you cannot make too much. A lot of those new languages are riding on Java's success and if Java dies they will also get in problems. It may happen that some folks are going to do polyglot programming, but I don't believe it will be the rule due to the the complexity related to this approach.


Des Oates replied on Fri, 2008/06/06 - 6:58am

No I agree with Andres here. The polyglot programming paradigm is somewhat new to the JVM, not to the industry in general.

Furthermore DSLs will continue to gain momentum as they put more 'solution power' into the hands of the domain experts. I.e. the people that best understand the problem being solved. That may not seem attractive to IT professionals but its a compelling notion for those who sponsor large IT projects.

So I don't see the polyglot landscape disappearing anytime soon. However, this is a good thing for Java in general as long as the languages continue to target the JVM. More languages==more use cases == more Java deployments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.