Death of java, Film at Eleven

by Charlie Martin

Once upon a time, there was a language, Java, that was going to solve the world’s problems. Cross platform, it wouldn’t have the portability problems of C and C++. It ran in the browser, so you could put functions close to the user; it ran on servers, so you could write programs in the same language at both ends of a web application. It talked with databases. It talked with devices. It could be big, it could be small.

Whatever happened to Java, anyway?

It’s a topic close to my heart; I started programming Java about as soon as it escaped from Sun Labs. I’ve followed it for twelve years, through two tech crashes and half a dozen revisions. I still like programming in Java, but it’s never really lived up to its promise. Now, with Sun’s problems and the current economy, we ought to wonder, will Java survive? Should it? And what should we learn from the story of Java?

To understand Java, it’s worth thinking a little bit about the history of the language.

It started out at Sun Labs as a language for devices like cable set-top boxes. Why? Because the set-top hardware changed fairly often. If you could write programs that didn’t care if the platform changed, life would be much easier.

Just about that time, the World Wide Web took off. Sun realized that browsers had the same problem as the set-top boxes: you didn’t know what hardware or graphics or operating system the browser had to support. But if you had a language that didn’t care, you could make programs that, well, you could write a program once, and it would run anywhere.

Of course, this immediately ran into a problem that it only worked if people wanted programs to run anywhere. Browser-embedded Java immediately suffered, as Microsoft decided it would rather have control over the Java that ran in Internet Explorer. Microsoft’s solution, ActiveX, was too platform specific; it didn’t take off either. What did take off were Flash and HTML/JavaScript.

There was still the server side, though; besides, Sun actually sold servers. They’d just had some dramatic successes in the dot-com boom, with companies like eBay, so the new buzzword was the “E”-word: “enterprise”. This led to J2EE, Enterprise Java Beans, and so on. Running Java in the server, with J2EE, meant bringing in a lot of complicated expensive infrastructure and it needed arcane knowledge to manage effectively — but when you were done, you had a system that would happily support something as big as eBay.

There was just one problem: almost no one got to be as big as eBay.

For every major web business site like eBay, there were tens of thousands of smaller sites that needed to be built cheaply, and that changed quickly. J2EE solved the wrong problem – it made it relatively easy to build a really big high performance web system, while most of the market was in small, easily programmed and easily changed web systems, which were much more easily build with relatively lightweight infrastructure, like PHP and Apache.

So now, in 2008, we’ve got rich user interfaces being build not in Java but in JavaScript and Flash; we’ve got server-side programming being done in PHP, Python, and Ruby. It sounds like there’s really no longer a niche for Java at all. Does this mean the end of Java?

Someday, maybe, but not yet. What it does mean, though, is that we have to stop thinking about languages, and start thinking about customer problems.

Applied to web applications, we still have lots of possible different platforms on which our programs will run. Web application platforms change slowly; what changes quickly are the application requirements, and the Java language just isn’t as effective in that environment as an interpreted “dynamic” language. It’s still useful to be able to change platforms, but quick development is much more useful. There are a number of new languages that run on the JVM platform, either versions of popular languages like Jython and JRuby, or whole new languages, like Groovy and Clojure. [Clojure, a Lisp-like functional is especially interesting. Functional languages are going to become important; I’ll talk about why another time.] In the applications world, the Java Virtual Machine and dynamic languages combined are a good match for the real problems.

Java, as a language, is built around ideas that make it very effective for programs that need to be small, but easily tested and very reliable. These ideas – a compiled language, with the potential for extreme optimization, static typing and completely defined semantics – are the very things that make it less suitable for fast-changing web apps, but very well suited to embedded applications – the world for which Java was originally intended. This is, effectively, what Sun calls the J2ME: a configurable platform for devices, programmed using the Java language.

The lesson, and the key to Java’s future — if it has one — is that Sun must start thinking about the customer problems that Java technology can solve; Java can’t continue to be the giant download that tries to solve all problems. JVM-based agile applications platforms, and embedded devices, are both exciting markets but they present very different problems.  Java, if it is to survive, will have to fit itself to the customer’s problems, instead of trying to make the customer use the Java solution.

 Charlie Martin has a long history in Silicon Valley as a respected coder and developer. He started his career with punch cards which, by all measure, makes him a veteren and expert.