Java Detour

After the Eclipse Board and Council meetings I headed down to San Diego to meet with the Executive Committees of the Java Community Process. I was there to have a conversation on what Eclipse is and what we do. On the way to SFO, we drove by this coffee shop, which I thought was pretty fitting given all of the conversations last week about the road Java is on.

Personally, I disagreed with the basic argument in the article: that Java is taking a backseat to other languages and platforms. John Loiacono got it exactly right in his counterpoint in the article. It may be fun to write about the next shiny toy in the high tech universe, but the reality is that the vast majority of business applications and commercial systems need to be built on stable, proven technology. I am now getting old enough to have been through several hype cycles. In fact, I’ve now been through enough that I think they’re pretty damn annoying. But they are the engine that feeds the software industry machine, so I think we’re stuck with them.

I tried to make a point along this line when I compared Java to COBOL in my JCP talk, but apparently didn’t explain myself very well. What I don’t understand is why people think comparing Java to COBOL is a negative statement. I sure didn’t mean it as one. COBOL powered the business of the planet for an entire generation. It lasted for decades after its demise was predicted. This is not a comparison on a technological basis. It is a comparison of mainstream adoption, perceived stability, robustness and scalability.

For 20+ years if you were going to write a business application and you were thinking of writing it in a language other than COBOL, the onus was on you to explain why. That is pretty close to where I see Java today.

At Eclipse we use Java for most development, but we are not focused solely on Java. Two great examples: Zend recently joined to build PHP tools, and Eclipse’s C/C++ tools are widely adopted in the Linux and embedded markets. You can find Eclipse plug-ins for almost every language out there.

Is Java seeing some stiff competition for the hearts and minds of developers? Absolutely. As pointed out in the BusinessWeek article, PHP’s adoption is growing in leaps and bounds. And it is increasingly moving up the stack to become a more scalable and mature enterprise solution. It does not make sense to try to use Java for everything, but to carefully think through what is the best tool for each project. But that is not the same thing as saying that the end is nigh for Java. Personally, I believe that PHP and LAMP have been taking a far larger bite out of the Microsoft franchise than Java’s.

Can Java be improved? Absolutely, and that’s the conversation we had at the JCP. In my personal view, there is way too much “P” and too little “C” in the JCP. At its core, the Java community is a developer community. And in my view, communities such as Eclipse and Apache do a far better job of empowering the developers than the JCP in its current incantation. Java needs to figure out a way to harness the energy in the Java developer community, rather than contain it.

I think that most of the innovation in Java is happening outside of the JCP process. Which is a good thing, as innovation needs to precede standardization. But the missing link in the process is that the JCP then needs to learn how to attract the great new things being created in Java and bring them in (when appropriate) for standardization. Instead what appears to sometimes happen is JSRs are created to compete with ideas already implemented in the broader Java community. A bad idea, IMHO.

I typically do not respond to anonymous questiosn. If you really want an answer, I would expect a name as a common courtesy.However, in this case there were two obvious examples which I discussed when I met the JCP. They are JSR198 and JSR277. JSR198 is aimed at implementing a plug-in model for IDEs, but neither Eclipse or IntelliJ are interested in moving. Seems dead on arrival IMHO.JSR277 is basically repeating the work already done by OSGi which in turn has aleady been adopted by JSR232 in the JME space. If 277 goes a route which conflicts with OSGi, I don’t think it will be a happy story.