Monday, July 15, 2013

Signs that Java is Fading

My website is losing traffic. It never had terribly high traffic, other than the days it was mentioned on Reddit or Hacker News, but in the last year that traffic has been cut in half. There are no doubt many reasons for this, but I'm going to take a dramatic interpretation: it's another indication that the time of Java is passing.

Bold words for someone who only gets a few hundred hits a day, but the character of those hits are changing. The two most-hit pages on my site have consistently been those on bytebuffers and reference objects: topics that are of interest to people doing “interesting” things, and not something that you'd use in a typical corporate web-app. Recently, these two have been eclipsed by articles on parsing XML and debugging out-of-memory errors.

This sense that Java isn't being used for “interesting” projects comes from other sources as well. Colleagues and friends are looking into other languages, some on the JVM and some not. One of the best recruiters I know, a long-time specialist in Java (and founder of the Philadelphia Java Users Group) is now emphasizing other languages on his home page.

Of course, Java isn't going to disappear any time soon. There are billions of dollars of sunk costs in Java software, and it needs to be maintained. And with hundreds of thousands of Java programmers in the job market, employers know that they can always staff their projects, old and new. Corporate inertia is all but impossible to overcome, as evidenced by the fact that you still see plenty of COBOL positions open.

Java is occasionally called “the COBOL of the 21st century,” and I've never found the comparison apt. But the position of Java today seems to be similar to that of COBOL in the 1980s: a huge installed base, huge demand for developers, but slotted into a specific application area. If you wanted to venture out of the accounting realm, you looked for something else.

Yesterday was my birthday. This upcoming January will mark 30 years that I've received a regular paycheck for making computers do what other people want. In that time, I've switched areas of expertise several times. I figure that I'm going to be in this business for another 15 to 20 years, and I want to be doing something interesting for those years. So it's time to re-evaluate Java, and think about what my next area of expertise should be.


Unknown said...

I agree with your verdict of Java's demise. Though Java might be fading (let's see what Java 8 does there) the JVM itself is still holding strong with languages like Scala that benefit from the strong performance of JVM. A lot of the skills acquired from working with Java carry over to this new world. I still think other languages will eat what was normally Java territory (stateful server, HTTP server etc). Languages like Go shed a lot of C's issues while still offering great control over memory layout. The byte buffer tricks that you refer to in your article become unnecessary here. It's like 5 lines of code to create a HTTP or TCP server in Go that uses epoll/select. HTTP clients also have a synchronous syntax but do non-blocking IO behind the scenes. Imagine doing that in Java NIO. Go also like Java has corporate backing though it might not have the same amount of marketing that Java enjoyed. Java introduced a standard thread which was a great improvement over native languages at that time. Go goes one step further to introduce light weight threads backed by a threadpool as a part of the core language. Combined with their synchronous looking IO implemented as non-blocking IO behind the scenes this leads to some really easy to read yet performant code. They have primitives for communication between these light weight theads too, which is way higher level than the normal Java synchronization primitives. Rust yet another language which is still massively experimental is even more bold in trying to make memory management compile time checked, thus eliminating gc for the most part. Though I imagine it will eat more into C++ land if it ever matures. This new breed of languages have taken a lot of Java's USPs (large std library, no header files and long compile times, concurrency model etc) but have managed to give programmers more control over memory layout (no byte buffer or unsafe tricks) and reduce on Java verbosity. I feel like Java's biggest legacy is the JVM which is still going to be difficult to beat in terms of performance. The language itself is only useful for maintaining old projects or the large developer pool.

Rüdiger Möller said...

I disagree. From what I see, Java grabs more applications which would have been done in C(++) 10 years ago (mostly because of the massive improvements in JIT compilation technology and faster hardware).
On the other hand, faster hardware allows "higher" level languages to replace java in the standard business application-domain where productivity matters more than performance.