Sunday, September 23, 2012

Is Java Dead or Invincible?


Is Java Dead?

Writer Isaac Asimov once said that "the only constant is change".  That isn't just a phrase in the software industry, it is an absolute fact.  Once, there was a day when Corba was king but it was usurped by Web Services.  Even within the world of Web Services, that used to be all about SOAP but now it's REST style services which are much more popular today.  Now somethings will obviously hang around a bit longer than others.  Relational databases have been around 40 years and aren't going to be kicked out by NoSql just yet. The HTTP protocol has been at version 1.1 since 1999 and has helped us use a thing called the Internet.  As for Java well that has been a pretty popular computer programming language for the last decade and a half.

According to Dutch research firm Tiobe in terms of overall popularity, Java ranked 5th in 1997, 1st in 2007 and 2nd in Sept 2012. At the time of writing there are over 2,000 Java progamming books on Amazon in English and there are almost 300,000 threads on Stackoverflow related to Java.   However, as George Orwell once said: "Whoever is winning at the moment will always seem to be invincible". But is Java invincible or beginning to die?  That's the question being asked more and more now.

In my humble opinion, the challenges to Java can be split into three categories:
  1. The rise of alternative languages
  2. Scalability / Multi-Core processors
  3. The return of the fat client.
Let's elaborate...

The rise of alternative languages

Alternative languages can be split into two groups: those that run on the JVM (Scala, Groovy etc)
and those that don't (Python, Ruby).  One interesting thing is that the first group is pretty large.  The languages that run on the JVM aren't mutual exclusive to Java and in a sense strengthen it reminding us what a remarkable piese of software engineering the JVM is.  Development teams can get that
extra bit of expressiveness in a niche language like Groovy, but can still call out to Java when they need some cool Java library or just need that extra bit of performance.  Remember the advantages in Groovy 2.0 speed it up but it is still not as fast as Java.

As for the features some of these languages provide that are not in Java, well that is the case but it won't always be the case.  Take a look at the roadmap for Java 8 and the features it will include. Just like Java EE 5 and 6 took ideas from Spring / Seam,  the Java lanuage in its 8th major release will be taking ideas from other languages. For example literal functions will be facilitated by Lambdas.  Java 8 Lamdas will have support for type inference and because they are just literals it will be possible to pass them around (and return them) just like a String literal or any anonymous Object.

That means instead of having to write an implementation of Comparator to pass to the Collections sort utility to sort a list of Strings, in Java 8 we will just do:
Collections.sort(list, (s1, s2) -> s1.length() - s2.length());

So, the alternative JVM languages don't exactly kick Java out of the party. It is still there, but in a party that has a better selection of music played and in a party where the guests encourages their host to be a better host.

Scaling on the multi-core platforms

As for multi-core and JVM - we all know that with a JVM running on a single core it was possible to spawn threads in the very first release of Java.  But these threads weren't executing in parallel, the CPU switched between them very quickly to create the impression that they were running in parallel. JStack may tell you that 50 threads have state "runnable" on your single core machine but this just means they are either running or eligible to run.  With multi-core CPUs it is possible to get true parallelism.  The JVM decides when to execute threads in parallel.

So what's the deal here?  Firstly, even though concurrency and threads were a feature of Java from the very beginning the language support was limited meaning development teams were writing a lot of their own thread management code - which could get ugly very quickly. This was alleviated greatly in JDK 1.5 with the arrival of a range of thread management features in the java.util.concurrent package.  Secondly, to get better parallelism something else was needed.  This came in Java 7 with Doug Lea's Fork / Join framework which uses clever techniques such as work stealing and double sided queues to increase parallelism. However, even with this Framework decomposing (and re-arranging) data is still a task that is needed to be done by the programmer.

Functional progamming gives us another option to perform computations on data sets in parallel.  
In Scala, for example, you just pass the function you wish to operate on the data and tell scala you want the computation to be parallelised.
outputAnswer((1 to 5).par.foreach(i => longComputation))

And guess what? The same will be available in Java 8.
Array.asList(1,2,3,4,5).parallel().foreach(int i ->heavyComputation())
Since scalability and performance are architectural cousins, it is worth stating that in many experiements Java still out performns other languages.  The excellent Computer Language Benchmark Game shows Java outperformaning many languages. It hammers the likes Perl, PHP, Python3, Erlang in many tests, beats Clojure, C# in nearly all tests and is only just behind C++ in terms in the performance results. Now,  performance tests can't cover everything and a context will always have some bias which favours one language over another but going by these tests it is not as if Java is a slow coach.

The fat client is back!

The return of the fat client

Since the advent of AJAX, Doug Crockford telling people how to use JavaScript and the rise of an excellent selection of JavaScript libraries the fat client is truely back.  Close your eyes and imagine what a cool single page web application such as gmail would look and feel like if it was just thin client web framework based on Spring MVC, JSF or Struts - you just cannot beat the performance of a well designed fat client.

One saving grace is that JavaScript is a lot more difficult to be good than some people think. It takes a lot more thinking to really understand  Closures, Modules and the various JavaScript best practises than it does to know your way around a web framework like Spring MVC and Struts. In addition, building a single page web application (again such as gmail) doesn't just require excellent JavaScript understanding it requires understanding of how the web works. For example, browsers don't put Ajax requests in the browser history.  So you gotta do something smart with fragment identifiers if you want the back and forward buttons to be usable and meaningful for the User.

There is a probably some room here for a hybrid approach which uses both a web framework and JavaScript and of course some JavaScript libraries.   This gives developers a structure to build an application and then the opportunity to use JavaScript, JQuery or whatever cool library takes there fancy for important parts of the Application that need to be jazzed up.   In a true fat web client approach, there should be no HTML served from the server (that means no JSPs), the only thing coming back from the server is data (in the form of JSON). However,  using a hybrid approach you can make a transition from thin to fat easier  and you can still put your JavaScript libraries on a CDN, you just won't get all the advantages of a full fat web client approach.

Summary

In summary, Java has had some bad moments. AWT was a rush job, Swing had performance problems, the early iterations of  EJB were cumbersome and JSF was problematic in comparison to other frameworks such as Struts and Spring MVC.  But, even today, extremely innovative projects such as Hadoop are built using Java.  It still has massive support from the open source community. This support has not only helped Java but also show Java some its problems and things it needs to get better at.   Java has shown it has the ability to evolve further and while other languages challenge it I don't think the game is over just yet.  It goes without saying, a lot will of the future of Java will depend on Oracle but let's hope whatever happens that the winner will be technology.

References

  1. Yammer and their migration to scala
  2. James Gosling taking about the state and future of Java at Google tech talk
  3. Article from Oracle describingFork and Join in Java 7
  4. Eric Bruno:Building Java Multi-Core applications
  5. Edgardo Hernandez:Parallel processing in Java
  6. IEEE top ten programming languages
  7. JDK 8 downloads
  8. Java Code Geeks article on Fork Join
  9. Good Fork Join article by Edward Harned
  10. Fork / Join paper from Doug Lea
  11. Fork / Join Java updates information from Doug Lea
  12. Scala Java Myths - great article by Urs Peter and Sander van der Berg

8 comments:

  1. Well, in my opinion the JVM will live on, java not that much.

    The JVM is portable, and has been ported to a myriad of platforms. The JIT features and other optimizations makes it quite the beast. So I belive the JVM definitively has a future.

    Java 7 is a nice step forward, and so will Java 8 be, but I cannot help feel "too little too late".

    ReplyDelete
  2. I've been dabbling in Ruby, Python & Groovy lately. And I have to say, the more I play with these languages, the more I appreciate Java. However, Java is not perfect. What is killing Java is that it takes so long to evolve. Yes, adding new features need and take time. However, adding syntactic sugar shouldn't. I know Java 8 will give us the option to iterate over a list or a map using .each, but why did it have taken so long to realize that this is a good thing? A language that also makes it fun for the developer is a 'feature' in my opinion. And a lot of this 'fun' comes from the syntax.

    ReplyDelete
  3. On the Javascript topic. I don't like Rails that much, and I know many people don't either. However, they do innovate and tend to think of things much earlier than other frameworks do. And they also tend to implement earlier. The rest, just follow. For example, Yehuda Katz recently gave a talk about Javascript & Rails and he coined something called Rails.js. This should make it easier to expose objects from the server side to javascript. So instead of duplicating the models in JS, the framework should do that and somehow make it available in the client. I would not doubt that they will be able to pull it off, and then the other frameworks will follow, but a little too late.

    ReplyDelete
  4. Let's not forget, Java was knocked off the TIOBE #1 spot by ... C !!
    Long live Java !

    ReplyDelete
  5. Java is NOT Javascript. JavaScript and Java HAVE ABSOLUTELY NOTHING IN COMMON. Why are you even..? I can't even begin to try to understand.

    Also, be a little careful. Ruby can run on the JVM. Welcome to JRuby.

    Java isn't dead, it isn't dying and it isn't behind anyone. It's the standard language taught in most computer science classes for a reason -- it's easy to learn and it lets you comfortably transition into languages like C++ that offer you more control over what's going on (though its platform-independent API is really useful even after that, nothing wrong with things being easier.)

    If anything, it's growing because people are continuing to find out how damned easy it is to write Java code. Using it for web servers is a totally plausible option, and even though people have been using Ruby (Rails almost always), Python and PHP for that for ages, Java is becoming a reasonable alternative.

    All in all, Java has many years ahead of it. It used to be that it wasn't super powerful (again in comparison to its competitor C++) but it was very easy to learn and pick up. However, it's growing more and more capable and the API expansions being made in Java 8 will be fantastic towards that effort.

    ReplyDelete
    Replies
    1. Conor, correct JavaScript is not Java. I think you misunderstood me. The point was that the fat web clients based in JavaScript and JavaScript libraries negate the need for Java Web frameworks such as Spring MVC and JSF. They are faster and slicker. So are another threat to Java's popularity.

      agree with you about Java 8.

      Delete
  6. Java is well behind C# and other languages, simply because of it's verbosity. The thought that requires one line of code in more modern languages often requires several lines of code in Java.

    "Array.asList(1,2,3,4,5)" is a perfect example. In Ruby this is simply "1..5". Still no array or map literals in Java 8? Java is now about ten years behind C#.

    ReplyDelete