Ed Burnette over at ZDNet likes to spend a lot of time writing about Eclipse versus NetBeans. He rarely gets into the technical merits of either piece of software, but he definitely seems to favor Eclipse. I have never used either one of these pieces of software, to be frankly honest. I tried to download Eclipse a few weeks ago, partially based upon Mr. Burnette's high ratings of it (he and I disagree on many things, but I respect and trust his opinion), but their website is bad to the point that I had no clue what files I actually wanted to download. What I just do not "get" though, is why it really matters.
I know, I know, it really does matter. But it should not.
If both NetBeans and Eclipse are creating "100% Pure Java" then both of them will be creating code that could be used in the other one. Both of them should be generating code that does not rely on a particular application server or VM to be installed. Was this, or was this not the "code portability" promise behind Java? To be honest, Java as a language offers very little if the code is not portable. Java code is supposed to be portable, but in reality it is not. Sun has a bad habit of breaking backwards compatibility between Java releases. It is bad enough that Java code needs to be targeted at a particular version of a VM from a particular vendor from running on a particular application server on a particular OS.
My last major experience with writing Java involved having to resolve differences between Tomcat/Jakarta and iPlanet. Bleh. If Java was just a slow (and it is slow) system with a miserable syntax (I love writing ten lines of code to take the place of just one line of code) I could accept it. After all, I do spend part of each day writing VB.Net and VBA code, and I can accept those languages, despite their myriad of flaws. But it is a broken system. The idea that if a user clicks on the "update your Java now!" icon, my application can/will break is horrible. The idea that if I prefer one IDE and another IDE cannot use or run my code is even worse.
The Java crowd just does not understand this. They are so busy fragmenting and fracturing the language that Microsoft is going to run right around them. If Microsoft (or Mono) can get .Net running properly on non-Microsoft OS's (admittedly quite a trick, considering how one of .Net's principles is to make the Windows API usable and expose as much of it as possible in a consistent fashion), then Java has no reason to exist. Java and .Net are both system resource hogs and slow, although my experience has been that .Net is a bit less of a pig. .Net has the advantage of letting you write in whatever language you want, provided there is a .Net compiler for it. And .Net is much better about framework versions and backwards compatibility than Java is. At that point, Microsoft will just have to convince people that they are not evil and that going with .Net will not enslave them to Redmond forever.
Personally, I do not want to see this happen. Microsoft is not a great company when it gains an overwhelming market share in a category. Microsoft is an awesome company when is has competition. .Net is a great example of this: I think .Net kicks Java with a set of spiked golf cleats "where it counts" on just about everything. I still do not think that .Net is great, but I would demand a raise if I had to spend any measurable amount of time writing Java code. But Microsoft needs the competition from Java to keep them honest. .Net would not have happened if not for Java, most likely. And the pressure from Java keeps Microsoft driving hard for improvements. As much as I dislike Java as a language, I love what it does for the IT ecosystem and economy. And I have little loyalty. If Java can show itself to be a superior system, I would not object to using it. Furthermore, I have a strong suspicion that I will be using Java on a regular basis in the near future to work with Cognos ReportNet. So it really is in my best interests to see Java be the best that it can be. To have two major IDEs producing incompatible code is not how to do that.
Justin James is the Lead Architect for Conigent.