Rich Unger's Blog

July 2005 Archives

I prefer my JARs sunny-side up

So, I'm sitting at my laptop, building netbeans... oh, wait ... OK, so I'm sitting ... oh, sorry, hold on... so, ... oh crap, not again.

Another scrambled jar.

This has to be the most rediculous, hoop-jumping compromise ever developed between a legal department and an engineering team. I really hope someone from Sun Legal will comment on this blog post, because I'd really like some public discussion with them on this subject.

For those of you who don't build netbeans source code, and are therefore in blissful ignorance of what I'm talking about, let me fill you in. The netbeans source code makes use of a number of third-party libraries. Any that are not licensed with the SPL are "scrambled" in the netbeans CVS tree, and during the build process, it gets unscrambled, but only after a popup window forces you to click through the license.

Mind you, I'm not just talking about proprietary libraries. You have to click through the Apache license every time you do a clean build of netbeans. In fact, there's very little here that is not OSI approved, aside from the javac bridge, which basically amounts to agreeing to the same license you agreed to already when downloading the jdk.

This stinks for a number of reasons:

1. It's annoying to me and everyone else who builds the netbeans source tree. Chances are, anyone building the tree has enough awareness of what's in the product that we shouldn't have to go through all this every time we do a fresh build.

2. No other OSS project out there feels the need to put these kinds of click-throughs when merely linking to OSS libraries with other licenses.

3. It's bad for the perception of netbeans as being open. This causes real damage to netbeans as a product, and is therefore counterproductive for Sun.

4. It causes all kinds of issues with automated scripts that prevent people from working with the netbeans tree (e.g. Gentoo, or anyone wanting to do headless builds).

This looks like a "cover-your-ass" maneuver left over from an earlier time when Sun had less of an understanding of how to work with OSS. Remember, NetBeans was one of Sun's first forays into OSS. Haven't other Sun projects come up with more refined CYA methodoligies by now?

Please, would a Sun lawyer like to comment? Let's get rid of the "scrambled jar" dinosaur!

Eclipse vs. NetBeans *yawn*

OK, I got your attention. Now, can we just forget this horse-race and go back to getting some actual work done?

No?

Oh, fine. So, JavaOne just ended, and everyone's talking about the buzz around these 2 products. There's enough hype around here to stuff a turkey.

I saw an interesting post on ZDNet after JavaOne. It was yet another log on the Eclipse vs. NetBeans fire. The content essentially boiled down to, "they're both technically good, but Eclipse is going to win."

It struck me as not very well thought out, and I'll tell you why.

(To be fair, he later backed off a bit in his tone, if not his conclusions.)

In the original post, one thing that struck me as a particularly bad assumption was, "...as in many tug-o-wars, someone is going to end up with mud in their face..."

Why? You have 2 IDEs competing vigorously for market share, and the result has been astounding. The quality of both programs is amazing. They each have their relative strengths. What is this drive among pundits to try and declare a winner here? I think there's an alternative motive here. This is what pundits do. They evaluate the market, and lend their "expertise" to the reader by declaring a winner.

But he's putting the cart before the horse. The reason so many big industry players went with Eclipse for their plugins is because more developers already used it as their IDE. They're addressing the developer market, and let's face it, Eclipse was a better IDE last year. Naturally their market share was much higher. From looking at the relative attendance of NetBeans and Eclipse talks at JavaOne, I'd have to say that Eclipse still does have more users, but not by nearly as wide a margin.

It's just not so clear-cut anymore.

On the J2EE side, NetBeans has better support for html, jsp, xml, xslt, and deploying/debugging within tomcat. The new project system, designed around ant, is very appealing to a lot of developers I know because their IDE uses the same configuration as their nightly build scripts. On the client side, Matisse (the new GUI builder) is light years ahead of anything Eclipse has to offer. The J2ME support in NetBeans has been getting an awful lot of attention. Finally, coming down the pike is the JFluid profiler. An IDE that makes profiling as easy as debugging is going to win a lot of converts.

Developer mindshare is a fickle thing. Honestly, I believe the 2 will be leapfrogging each other for at least a few years to come. And that's a great thing. That's much better for us average joe developers than having one "winner". Let 'em slug it out!

Finally, to address the platform/framework argument. Yes, there are more people building Eclipse plugins than NetBeans plugins. I think this is for 2 reasons:

1. There have been more Eclipse users, but I've addressed why I think this is evening out
2. There's more functionality out of the box in NetBeans

So, for now perhaps there are more Eclipse-based desktop apps than Netbeans-based ones. However, I think that, by far, the biggest share of desktop java apps has to go to the "no framework" or "homegrown framework" crowd. And, as both the Eclipse and NetBeans platforms mature, and become more compelling for use as the foundation of non-IDE desktop java apps, which one will be more popular? Well, Eclipse will have the headstart of having a few more community members already having written plugins. However, NetBeans has the huge advantage of being swing-based. I'm guessing there's a lot more Swing developers than SWT developers out there.

And if you want to talk about relative buzz, let's consider the companies that are choosing up sides here. BEA, IBM, Sun, etc. These are companies selling app servers (well, except Borland, but I have no earthly idea how they think they're going to survive as a set of not-so-much-value-add for Eclipse). App servers based on EJB technology. Why am I mentioning this? Because the most highly attended JavaOne talk I saw was Rod Johnson's Spring talk, which was busting the seams at the Yerba Buena Theater. This is the guy who wrote "J2EE Development without EJBs". So, let's be honest here. In a world where the tools and the server side frameworks are all free, the app server companies are chasing, not leading, the adoption curve.

(BTW, message to Sun and IBM: the first IDE to treat Spring, Hibernate, and other open source frameworks as first class citizens is going to get a major boost. It may not be welcome news to the companies trying to sell everyone on complicated clustering and transaction architectures, but this is what developers want, and you're just not going to convince them otherwise. Yes, yes, I know that if they'd only wait until EJB3, they'd get the architecture they want, but meanwhile the open source frameworks have built up a huge following and lots of useful APIs. Can EJB3 make any javabean JMX managable? No? Spring can. But, I digress...)

The real market for a client platform is not companies who make app servers and want to give away plugins to IDEs. The real market is companies (and individuals) who want to write client applications that are not IDEs.

Anyone talking about a "winner" when there's still only enough such apps on each platform to count on one hand is blowing smoke.

Most productive night drinking ever

When we got a little too drunk for that, we started in on the source code to my FeedReader. We hacked around until we figured out a way to embed a JDIC browser in a TopComponent.

That was cause enough for the celebratory drinks to migrate from beer to whiskey. After that, a bunch of other folks from the netbeans team showed up. Once I got a complete rundown of Czech history over the last century, I said a fond farewell and caught the caltrain home.

Now it's bedtime.

This work is licensed under a Creative Commons License.