Sunday, January 21, 2007

Eclipse on Mac

Today I read a blog post claiming that Eclipse has little, if any, following among Mac users.

That claim took me by surprise. So as a litmus test, I did a bugzilla query to see how many bugs were reported on Mac and I got 3550 bug reports. Not too bad.

Where is the data that backs up or refutes this claim?

It would be interesting if the webmaster could provide Mac download statistics and/or if the marketing wing of the Eclipse Foundation could provide one of them pie charts showing Eclipse's mind share on Mac.


Gerd Castan said...

Well, I don't know solid data. Eclipse on Mac is a common combination for the developers I know.
+1 for Eclipse.

The other thing is the "native look and feel" claim of SWT. Swing renders NATIVE widgets on Macs since Java 1.3 (that's Apple's implementation of Swing). SWT on the other hand is native, but has several cases where it looks wrong or ugly or Windows-like. Swing is also very fast on Macs.
+1 for Swing

The reason to use Eclipse on Macs is the rock solid IDE (which is also true for Netbeans) and the great frameworks and plugins that use SWT. Not SWT itself.
+1 for Eclipse


Anonymous said...

Actually, that's not what the blog post says. It says that "I'm sure it doesn't hurt that the NetBeans team has a significant portion of Mac users, and the Eclipse team has none (or so close to none that I can't tell the difference)."

In short, the majority of the Eclipse commiters are not Mac users. There's a minority; in fact, realistically the only Mac guys that there are are the SWT team. VE has even asked for help testing on Macs, since they don't have any.

The main problem is that Eclipse on the Mac is not a proper Mac application. It's a Windows application that has been ported to the Mac. There's very little, if any, attempt to make it a more professional Mac application, and that (in turn) is mostly because the PDE build team is looking at spewing out an executable based purely on what a Windows install might look like.

See, for example, bug 57349. This is a trivial repackaging issue that met serious resistance "because that's not the way it works on Windows" despite the fact that Mac developers have explicitly said that this is a bad thing. There are even blog posts, a repackaged Maclipse and even an essay on how to convert an RCP into a decent Mac Application to work around the fact that the build/platform/releng team just do not care about the Mac platform.

It's not even been until Eclipse 3.3 (with the new JNI launcher) has been a properly dockable application, which all Mac users will take for granted. (A Windows-y example might be that you can't put it into the QuickStart bar at the bottom.)

And let's face it -- it's not just Macs. The Eclipse install for Linux is horribly borked in relation to where files are expected on a Linux platform, which is why distributions like RedHat go out of their way to repackage the applications to meet the standard conventions (e.g. putting writable stuff in /var, putting shared stuff in /usr).

All of the deployment of Eclipse plugins is fundamentally windows-based, and other platforms have been a port of those. Writing stuff into an application folder (whether that be Mac or Linux) is fundamentally the antithesis of a decent application; that's something that only makes sense in the Windows world (and it's arguable it shouldn't even do it there, but prefer to use the Documents and Settings instead).

This is purely about what makes a Mac application a Mac application, and the fact that none of the responsible teams inside the pde/build/releng use anything other than Windows. If they did use Macs, they'd appreciate that a Mac app should only consist of an at the top-level and nothing else; and that no writing whatsoever should occur in the .app folder subdirectories. This is not the case at the moment for either the Eclipse SDK nor any Eclipse RCP based application on the Mac.

Ian Skerrett said...

I agree with Alex that the blog post seems to refer to Eclipse committers, not necessarily users. Although I am not sure how this person would know what development platform Eclipse committers are using?

Regardless, I guess I am the marketing wing of the Eclipse Foundation that you are referring to. :-) Our 2006 download numbers indicate that about 3% of SDK downloads are for Mac. Here is a link to a presentation by Mike Milinkovich for our members meeting. The actual download stat is on page 22.

Kim Moir said...

Downloads by os are available in the latest eclipse membership meeting slides
See slide 22 of

Windows 86%
Linux 11%
Mac 3%
Others >1%


There are more Mac users on the platform team than just the SWT team. There are several UI committers that use a mac as their main developer environment. Would having more mac users on the team make give the mac bugs more visibility - absolutely.

That being said, the reality is that we have to focus on problems that impact the majority of our users. We welcome patches from people in the community who can provide functionality for a less-visible platform. For instance, we have teams that provide builds for solaris-gtk-x86 or linux-gtk-ia64 because they are interested in making them available.

The linux files are just in tarball format and this is our intention. Why? It is the role of the linux distributions to massage the linux drops to meet their needs. We are not in the business of packaging drops to meet everyone's needs. The commercial vendors that build on top of eclipse provide that service and are able to profit from it. This is one of the goals of the eclipse ecosystem - to allow commercial vendors to profit from building on top of the open source projects. Without it, we wouldn't have companies paying committers :-)

Your statement that the pde build/releng team don't care about Macs is a bit disingenuous. We do care. The reality is that we have too many bugs to solve given all of our responsiblities. That's one of the realities of open source - too many bugs to solve - not enough time. The role of the committers is to assess the bugs they do have and focus on the ones that provide the most value.

Anonymous said...

Ian; it's clear that the packaged output isn't standard Mac applications. To put it another way; if you installed an application onto Windows, and it demanded that config was installed in c:/etc and the programs in c:/usr, then you would feel that the application is going out of its way to go against the flow of normal Windows applications in preference of a Linux/Unix type structure.

The same thing is just as true, and just as horrible, in the current Mac bundling. Unfortunately, there's no support to get it fixed in the platform, because the releng/platform/build teams keep bouncing it between each other as 'not my problem'.

I don't think the blog entry is supposed to say that no Eclipse committers use Macs; but those that are responsible for the final bundling of the Macs certainly don't. Indeed, Andre Weinand (who has done a lot of the SWT work on Mac OS, as you'll be able to see in the commit comments) supported the position of proper packaging right from the beginning of that bug. And it's also clear from e.g. Pascal's comments that the releng team don't have the support to be able to test this kind of packaging.


Steve said...

>SWT on the other hand is native,
>but has several cases where it
>looks wrong or ugly or Windows-

Gerd, those are exactly the places where the Eclipse designers decided that they were not going to use the native platform widget. This can't be described as a problem in SWT.


Anonymous said...

All Eclipse committers can get download numbers from the Eclipse Committer tools (click the live download stats link).

Daniel Spiewak said...

Actually, Steve, having used Eclipse (as well as other SWT based apps) on Mac, I can tell you that the most annoying bits are the supposedly native controls. SWT feels archaic on mac primarily due to the fact that it uses Carbon rather than Cocoa. While the difference might be indistinguishable to the casual user, avid Mac developers who stare at Cocoa-based apps 16 hrs a day notice the small things pretty quickly (like the SWT Button widget size and font on Tiger, which drives me up the wall).

IMHO, to break this opinion, SWT would have to be reimplemented in Cocoa. Yes, I know why it wasn't in the first place, but I think that thos reasons are no longer valid enough to keep SWT off of Cocoa.

Denis Roy said...

> It would be interesting if the webmaster could provide Mac download statistics and/or

"teach a man to fish"

Even better than providing the stats is providing you the tools to get your own stats. Committership has its privileges! Log into Committer Tools (https://dev/ and use the Live Download Stats tool. Put this in the file box, and select "All" for the dates


Anonymous said...

For those who aren't committers...or can't fish...there were over 6 million download requests of production versions of the Eclipse SDK in 2006. As noted above 3% of those were on the Mac.

So the Mac downloads were somewhere between 180,000 and 200,000.

I'm not sure how many Java Mac developers there are in total, but that seems to be a pretty healthy number of downloads to me.

Anonymous said...

In addition to all the things that make Eclipse on a Mac not like a Mac app once it is installed - installing it is hit and miss in the first place. Me, I took the time because I had a reason to want to get Eclipse running on the Mac. If I hadn't already had my heart set on it I would have run away when the installation bonked.

Anonymous said...

Mike, the issue is *not* that there are no developers on the Mac. It's that there's no *committers* on the Mac that are responsible for bundling the apps, and that they're not listening to the 3% of Mac users who are telling them that it's wrong.

Saad Mahamood said...

I don't generally use Eclipse on Mac that much, instead prefering Intelli J IDEA. However, I do agree with the other sediments that have been raised about the lack of nativeness on the mac platform. The packaging of the application is just wrong. Intelli J IDEA comes as one nice .app, which you can drag 'n drop to your Applications folder. Whilst Eclipse comes in format that is particularly appealing. The second that annoys me about eclipse is the top icon toolbar, which is decidedly looks nothing like icon toolbars that are present in Mac applications. Instead of high resolution icons, we instead get a tack windows 16 x 16 size pixel sized icons. I admit in this area Intelli J IDEA doesn't succeed either. However, it would nice if cross platform apps treated each platform equally and made very sure to look like a first class citizen on each supported platform.

Steve said...


Arachaic seems a bit harsh. The finder is a carbon application. Anyhow, did you enter a bug report for the font size issue?


Andrew Overholt said...

I'd like to point out that download stats from don't include users who use the packaged version of the Eclipse SDK that are included with the various Linux distributions.

Ken Gilmer said...

I love my Mac. Of course Eclipes too, but Carbon makes me want to use Linux/GTK. I work in Eclipse every day. I've seriously considered switching to Linux from OS X because of how bad Eclipse/Carbon is. Tree controls are terrible, buttons are bad, and don't even get me started on contextual menus. There are Bugzillas about why SWT has to use Carbon over Coca. Fine, but that doesn't mean that Carbon still sucks.

On the other hand, 3.2 is so much better than 3.0 was. Work is being done...I'm optimistic, but I don't think most of the issues are Eclipse, but rather Carbon.

Steve said...


To be precise, what exactly is wrong with the tree control, buttons and menus? Nothing will ever be done without specifics.


Ken Gilmer said...

Steve, your question deservers a response. This is something that's been on my mind for awhile. Let me get something together and I'll get back to you.

Ken Gilmer said...

Steve, here is my rant:

Anonymous said...

Eclipse is awesome. Erich Gamma is awesome. Eclipse's UI on Mac OS X is not.

Someday when I have enough experience, I will contribute to this part of Eclipse.