Blogs

RedMonk

Skip to content

On Eclipse, Java and Rich Client Platforms

Given the attention I’ve been giving to network/services based approaches lately (1, 2, 3, 4, 5, 6, 7, and there are still more) it may come as a bit of a surprise that I track rich client happenings as well. I do believe that network applications and rich clients are headed in opposite directions in terms of adoption and growth, and that network applications will continue to erode the installed base of rich clients (as they have in email and CRM, for example), but at least for the forseeable future there will be tasks that require a little more client side horsepower.

Enter Eclipse. One of the areas where we’ve been watching the project most closely is in their progress towards becoming more than just a shell for development plugins with their rich client efforts. We’ve thought this was a big deal for a while now, but it still seems to get – strangely – very little attention.

The more I think about it, however, the more I agree with something I posited a while ago: Eclipse will be competing with Java. On the face of it, this is a rather absurd notion given the fact that Eclipse is in fact based on Java, and while it supports other languages, it is still far and away most closely aligned with Sun’s creation. When I asked the Eclipse folks whether they’d heard this mentioned as a concern before, they said that I was the first and only person to raise it. So maybe I’m just being silly.

Consider, however, the rich client landscape as it exists for enterprise developers today. The traditional approach was simply to design natively for Windows, eschewing cross-platform support because there were no other platforms – on the desktop – that needed to be supported (yes, I’m oversimplifying). While that hasn’t changed all that much (at least stateside), IT departments are at least looking to keep their options open these days, meaning that cross-platform is very often back in as a requirement. So in addition to the dominant native Win32 or .NET development paradigm we have language/platforms like Java and, perhaps, Mono/Python.

So those are a few of the players. There are others that could be included, but that’s besides the point. All of them, I think, face a clear and unambiguous threat to their desktop significance. It’s clear from where I sit that these would be rich client players and their respective platforms are going to be increasingly squeezed by the network services like Salesforce.com – at least in terms of enterprise applications. Yes, the software-as-a-service contenders lack a credible, mainstream solution for the intermittent connectivity problem, but as the US finally catches up to the rest of the planet in wireless connectivity I expect many of those issues to decline. And no, they’re not suitable for every task, but who would have thought 5 years ago that they’d be able to capably handle CRM?

What we have then is a few players fighting over what I would characterize as a shrinking pool of enterprise rich client developers and ISVs. Eclipse and its rich client ambitions are yet another mouth to feed in a hungry household. In that respect, Eclipse – should its rich client project take off – could negatively impact all of the above players. Interestingly, Eclipse could – despite its close ties to the language – hurt Java’s desktop ambitions the most by poaching developers to its platform, as opposed to straight up Java. It’s like the baseball MVP voting every year; having two candidates from the same team, as the Sox consistently do in Manny Ramirez and David Ortiz, ends up making both players non-factors in the vote.

Of course, you could look at it the opposite way, and say that an Eclipse takeoff would float all Java boats, and to some extent I agree. I very much doubt, however, that Sun would subscribe to that notion.

So what do you guys think? Am I crazy?

Categories: Trends & Observations.

  • chuck piercey

    There have been numerous attempts to credibly field a cross platform client UI framework over the past 20 years. None have succeeded. The Java camp has competing frameworks, Eclipse using one of those, and any Java solution to the problem suffers from the showstopper drawback that Java Rich Clients can't integrate to Office on Windows without some ugly bridging solution.

    So you have to do both Java and .NET, and that limits your ability to deliver new features.

    I don't know the answer to this problem, but I can tell you that it absolutely impacts the functionality available to the end user.

    Eclipse as a UI framework is a real option for rich client applications (so you are not crazy), but while I tend to think it would float all boats for Java, it will not solve the Windows rich client requirement if you need to integrate tightly to Office. I am very interested in other opinions on this topic. Am I incorrect in making that last statement?

    -c