One, lesser known strike against Eclipse
Yesterday, as a part of our ongoing coverage of JavaOne, I opined that this year's annual Java lovefest could turn out to be the last stand for NetBeans. As I described in that blog, NetBeans is an integrated development environment (one that embodies the write once run anywhere religion of Java) that's currently losing in an important popularity war against its rival IDE Eclipse. To some, Eclipse is Java's anti-Christ. Not only doesn't it enforce the write once run anywhere promise of Java, it practically encourages developers to build operating system specific applications.
There are already some interesting responses to that blog. quietLee wrote "My guess is [that Sun] thought to include OS specific hooks into the JVM was probably viewed as burn at the stake heresy." However, there is one legitimate, pro-NetBeans point that I like -- one that was raised in a conversation yesterday (after I posted that blog). It has to do with the slippery slope issue. The question is, once you step outside the write once run anywhere sanctuary -- even ever so slightly -- could the situation spiral out of control from there to the point that you really are no better off than writing dedicated applications? If things get messy on the deployment side of the equation, the answer could be yes.
As I said in my blog, developers may be mature enough to decide for themselves whether they're willing to bear the cost of maintaining platform specific versions of their applications, but there also could be a slight cost on the deployment/end-user side as well. Deployment of an Eclipse-developed application with OS dependencies also requires a significant amount of special care to make sure the JREs on the end-user systems will run them. Pages 25 thru 27 of an excellent Eclipse tutorial that I found do a good job of explaining the steps that developers may have to take to guarantee that end-users' systems will be able to run their Eclipse-developed applications. That this sort of prep work must take place means that Eclipse's interference with the write once run anywhere promise isn't strictly a developer-side issue.
It's already one thing to, over the years, have different versions of Sun's JRE to worry about. Particularly in upgrade and backwards compatibility situations (Sun has worked hard to minimize such problems). But once you throw the equivalent of a second runtime into the equation, many more of the write-once, run-anywhere bets, even within a single platform like Windows, could be off.
I'm not saying the problems aren't insurmountable. But I am saying that with the rise complexity comes an even greater difficulty in preserving once of Java's most endearing attributes. To some extent, one capability of the Eclipse IDE acknowledges the potential complexities. That's the one where everything including in the JRE can be wrapped up into one executable that, for all intents and purposes, is a self-contained Java environment. By distributing applications that way, developers are virtually guaranteed that of having no JRE-related dependency issues.
On the downside, having separate executables like that gets you much closer to the point where you're not much better off with Java than you would be with another language. Even worse, with this "architecture," end-users could easily end up running what amounts to multiple side-by-side JREs, completely defeating the benefit of having a virtual machine in the first place.
If there's a company that can help manage that problem for Eclipse developers, that company, by the way, is Sun. For example, within the JCP could be a JSR that really deals with the sticky issues and the right and wrong ways of managing dependencies on separate runtimes. Or, even better, there could be separate JSRs for the specific runtimes (eg: the SWT DLL for Windows). Heresy, I know. I'm not suggesting that philosophically Sun should swallow this bitter bitter pill. But, at some point, it may have no choice, in which case Sun would be better off helping everybody to manage the situation than constantly politicking against it.
As a side note, there was a day when Sun executives would literally blow a gasket if you mentioned Eclipse. Today, the tone is remarkably different. Sun will remind you of the risks of using Eclipse, but does so in a far less vitriolic way. Instead, Sun execs give Eclipse credit and say that they're in friendly coopetition with it and that Eclipse is what motivates them to make NetBeans better. So, in some ways, the relationship between Sun and Eclipse is far less chilly than it once was. Now, it's just a question of how much warmer that relationship will get.