the blog for developers

Is Java dead?

Is Java finally dead? There has been much discussion about the end of Java. As a developer, do you need to care? How do you need to change your decisions in the case that Java is dead? I have pounding this question for the last several years, beginning with my adventures into Ruby at the end of the 90s. I hope to give a thorough representation of my thoughts here.

In a very interesting thread on LtU Sean McDirmid wrote:

The Java death watch continues. Its future is tied up with Sun, which continues not to make money, and in this economy… JavaFX was late and didn’t make the splash it needed to make. Can Scala (or Clojure I guess) save the JVM? And who would take over the Java mantle if Sun imploded, IBM?

while Ross Smith is adding:

I think Sun will be widely recognised as doomed, if it isn’t already dead, by the end of 2009, and they’ll take Java (and the JVM) down with them.

A lot has happened since then: Orcale is buying Sun, the JRuby team has jumped ship to Engine Yard. 2009 has not yet ended, we will see if that prediction holds true.

Searching for java is dead with Google, one gets

Results 1 – 10 of about 8,620,000 for java is dead.

Dead indeed. Or at least lots of people think it is or will die 2009.

Update: Because some readers mistook googling for scientific research, as pointed out googling for “java is dead” results in ” Results 1 – 10 of about 170,000 for “java is dead”

For a start we first need to explore what “dead” means, and in particular what dead means for Java. What dead means to you as a developer. After that I will look into the potential successors and why they are better than Java – or not. Looking into the question “why should Java die” I want to make some prediction about Javas future and especially about some future Java programming style.

What does dead mean?

Let’s begin with some thoughts on what Java means. . Most people mean different things when they talk about Java. There are mainly three parts:

  • Java, the language
  • Java, the libraries (JDK)
  • Java, the virtual machine

So does “Java is dead” mean the language, the libraries or the virtual machine? Contrary to the commentors on Lambda the Ultimate the Java VM is safe. There are considerable efforts to open source the virtual machine beside the language. Indeed with the beginning of the Java language summit it looks stronger than before. Should Sun as a company die, Oracle drop Java or stop development on the VM, most probably some other players with their VM implementations or the OpenJDK community would jump in.

The VM as a platform has grown enormously in 2008 and 2009. Lots of people talk about JRuby as Rails for the enterprise – Engine Yards has pledged support. Scala is an object-functional language on the VM with a strong following and a lot of momentum in 2009. Both Scala and JRuby are established on the JVM, but there are newcomers. Clojure stirred up the Lisp community and the Java community in 2008 and made a lot of buzz in 2009. Just in time for christmas last year Ola Bini released Ioke, what he described as a mixture of Smalltalk, Ruby and Lisp. It looks like a more dynamic Ruby to me after some hours of playing around with it. Great feat. And recently Noop has been released.

Or does “Java is dead” mean the language? What does it mean to be dead for a programming language? Perhaps that it is no longer the default choice for projects? Default choice for what projects? It is obviously not any longer the default choice for web-sites and web startups. For some years this has been Rails, and with good reasons. Though I think a Wicket/WebBeans/Seam/JPA stack is as fast for development as Rails, Rails is a good choice for rapid development for a VC demo. The problems are down the road some years – or so I hear form some CTOs – and Grails might be a safer choice with the easy possibility to go to Java for your stable layer later.

The only large – and lets say profitable and growing – startup that uses Java is LinkedIn. Although some internal systems at FaceBook (Cassandra) and other sites run Java in their core, Twitter runs parts of it’s services in Scala. They show that it can be done. Contrary the German LinkedIn competitor XING is written in Rails.

With Rails and Python moving into the Enterprise, is Java no longer the default choice for new projects there? Not that I know of. Perhaps some grass root projects go with Rails, the default choice still is Java, C or C# depending on your enviroment. Beside some funny view on enterprise applications:

It’s been 10 years and there are still no compelling client side or desktop apps in Java and all the compelling server apps (sorry enterprise apps don’t count as compelling!) are done in PHP, Python, Ruby, Perl, Smalltalk et al.

I can’t see companies move their programmers and default choice to Ruby, Erlang, Python, Lisp or OCaml. As this would mean polyglott programming and as Alex Ruiz writes:

I haven’t seen any practical evidence yet to convince me this is a good idea.

For you as a developer, does dead mean you can’t get any more jobs in Java development? Looking at Dice


java Job Trends graph

java Job Trends java jobs

shows that Java jobs are still high, with a significant increase in 2008. The German news website Heise News showed the same for project work, a more than 89% increase since the beginning of 2007:

203 in Q1 2007

384 in Q3 2008

Is Java dead because other languages are better?

With a different angle we can discuss the death of Java in the view of it’s potential successors. As a matter of fact a language cannot die without successors, otherwise noone could develop any software. People suggest a lot of successors, some of them are:

  • Ruby
  • Python
  • Groovy/Grails
  • Scala
  • Fan
  • Erlang
  • OCaml
  • Ioke
  • Factor

Not all of them – although excellent and interesting languages – share the same goals as Java and fit into the same place. Ruby and Python seem currently not enterprise ready, mostly because of tools, skills and deployments. This might change in the future, we’re not there yet. OCaml and Factor are interesting and capable, but too far away from the procedural mainstream that is the C legacy. Most prospects have the JVM languages, Fan, Groovy, Scala, Ioke. Fan doesn’t seem to have succession ambitions, Ioke is specially designed as a testing ground for ideas. Scala and Groovy seem to battle it out as successors. Scala has momentum and hype, companies use it in enterprise environments – and it’s also my current favorite. Groovy looks stronger, it made some inroads silently in the enterprise and with Spring having bought the Grails committers – and now VMWare having bought Spring – it’s better positioned than before.

Those successors need to be better than Java, otherwise it would me a folly to replace Java with high costs and gain nothing. What does better mean?

  • Faster to write?
  • More cost efficient?
  • Higher maintainability, cleaner code?
  • Shorter code?

Most of them are faster to write because they have shorter code. As I’ve shown, Java is 1.7x – 4x bigger than Python in lines of code, but does that mean Java is dead?

Most comparisions take 5 to 10-year-old brownfield, legacy Java projects with hundreds of developers – many of them average – and compare them with 2-year-old Rails projects, where the initial developers – most of them excellent – are still on board. For a real comparison one would need to compare state of the art frameworks, Webbeans/Wicket, Stripes/JPA with rapid development frameworks like Rails and Django. I’ll spare this comparison perhaps for another post in the future, but would be happy if someone does a decent comparison. I consider this question open.

A Java successor needs to go through the enterprise. There is the main beef, the most money and the most developers. To die a language needs to die there. Enterprise software is used for longer periods of time, with many developers working on it. The longer time periods mean higher turn-over during the life-time. Were are the problems in the enterprise and how could successors solve them in better ways?

Enterprise pain points

  • Maintenance
  • Readability
  • Reuse

Do the potential successors solve those pain points better than Java? Partially. Some of them have richer reuse models, some of them have better readability and are less noisy. But I also consider this question open – from my experience with many languages those problems aren’t solved. Perhaps because many language designers today disdain the enterprise. Scala is a sweet spot for me, it gains on those issues but doesn’t introduce new problems.

Goals of Java and does Java no longer meet its goals?

What have been the goals of Java? Those are linked intrinsically to the success, so we need to take a look at them, and if those goals no longer represent what people need. Those goals are many, but the main ones seem to be:

  1. Solve problems of C++
  2. Internet capable
  3. Standard library – JDK
  4. Automatic Memory Management – GC
  5. No error prone pointer operations
  6. Enterprise-Ready – a goal that evolved after some time (easy to use, low entry, big departments)
  7. Easy concurrency in the language

I can’t see that those goals are no longer valid, or Java does no longer fulfill them. The goals are valid, and fulfilled. Only concurrency is the item which is highly discussed and can be an issue. Concurrency is the future. Concurrency can be an issue as the early lock and synchronize system of Java proved to be too difficult. The new trend is multi-core. Is Java unfit for massive multi-core machines? Java in later editions added easier concurrency with concurrent lists, queues and fork and join and is fit for multi-core machines. No worries at least for me that Java misses this trend.

One requirement to a language wasn’t seen as important in 1995 as it is today: Rapid development and rapid turnaround. Java still falls flat, even with JRebel which allows seamless reloading of classes, RAD web frameworks like Wicket and splendid IDEs. Rails, Django and PHP are better and have a faster turn around. Period. Java is lacking here, and reloading changes look to be the biggest problem with Java development today. Maven deployments are a pain after you’ve worked with Rails or PHP..

Faster turnaround has higher productivity. Which means more money. If Java doesn’t solve this – Java might be on the way to extinction.

Why should it die, what should we learn?

Java might die, because the drawbacks beside turnaround have gotten too big. Lots of concepts have been proven to be bad ideas.

  • Inheritance: outside of frameworks, inheritance is inflexible, leads to tight coupling and is plain bad. Composition is most often a better choice. As are mixins and traits
  • Noisy syntax: Lately there has been the enlightenment that too much noise in a language is a bad thing. Java is especially noisy in closures (anonymous inner classes) and generics.
  • Null / NPE: Null as the default for object references was a billion dollar mistake. An object should by default need a value. Otherwise NPEs will proliferate through your code. Newer languages prevent nulls or make the null behavior the non default one
  • Design patterns: Many design patterns are a good thing, but some of them are just covering inefficiencies in an only-OO language like Java
  • List processing: As shown by functional languages, list processing should not be done in loops. Many operations in applications are just that: get a list, transform the list, filter the list and return a list. Javas new for loop is better than the old – but solves the wrong problem. Java should have native support for easy list processing, not via the – best we have – constructs in Google Collections.

Those are valid concerns and one wishes Java would die for those. But the Java community is working on fixes – although as can be seen with the discussion on Closures in Java 7 sometimes too slow. I consider those problems painful, but not big enough that they will lead to Javas imminent death. They could lead to a death by thousand cuts.

Java Future and what does this mean for you

From what I’ve written  I come to the conclusion that Java is not dead. It’s not fundamentally flawed, it still meets it’s goal, there is interest in Java, no really clear successor has emerged, the platform evolves, the JVM shines, new languages flourish and new projects are started in Java.

But just because Java is not dead doesn’t mean it has a future. Developers need to open their eyes and learn new languages. I’m really disappointed in interviews when candidates show no interest in programming beside Java. So for you as a developer: no worries. As a student: You still need to learn Java to have a high probability to get a job – with the conditions you like. For you as a manager or CTO: have a plan ready for when the Java era ends.

It’s too early for a requiem. But if Java dies, what can we learn? Before and foremost one needs to learn from Javas success and eventual decline. The points I’ve written about, wrong concepts, enterprise pain points and what Java did right need to be remembered.

Is Java dead because no-one talks about it anymore?

Thanks for bearing with me through this long post, we now come to an end. Jitter about Java has significantly gone down. My blogging on Java has gone done. My twittering on Java has gone down. Some years ago everyone was talking about Java, now it’s mainly enthusiasts. Java is a none-hype. It’s not as bad as COBOL, but a lot like C and C++. Is a language dead when none talks about it anymore? You decide. In the end the only question that really matters: Is Java dead for me? Would I start a project in Java? I would have in 2008. Would I in 2009? Probably not, I’d use Scala.

About the author

stephan Stephan Schmidt has been working with internet technologies for the last 20 years. He was head of development, consultant and CTO and is a speaker, author and blog writer. He specializes in organizing and optimizing software development helping companies by increasing productivity with lean software development and agile methodologies. Want to know more? All views are only his own. You can find him on Google +

Discuss on Hacker News Vote on HN