August 9, 2008

Eclipse on Solaris 10 x86

The project I work on started, several years ago. In its initial stages or design goals were platform independence, robustness, and reasonably speedy. To try to achieve a balance of all these the Java platform was decided as our best option. After the project got rolling another package was envisioned to use the framework we had developed and allowed us to continue development beyond the original goals. With this new project came the need for GUI’s, which is where I come in, my primary roll on this project is as a GUI developer. Developing for Java at the time gave us two prominent frameworks for our UI. The first option was Sun’s Java Swing which has great cross platform support, an impressive feature list, had lots of development action. Swing had a few downfalls, at the time it was too unresponsive, lacked the native platform look and feel, and a bit cumbersome. While these issues have greatly improved, at the time this meant Swing struck out (yes the terrible pun was intended) so we decided on SWT which is a native GUI framework. A native framework means it executes code built specifically for that platform, calling the OS functions for doing much of the graphics work. Code that is compiled for an individual platform has several advantages most importantly being fast it also the same look and feel as other applications built for that system.

Working with SWT and the Eclipse RCP (Rich Client Platform) has generally been a pleasant experience. It however is nowhere near perfect, there are extra dependencies, lack of features, and a larger learning curve, when the platform has a problem it manages to make you feel like it is laughing in your face or poking you in a wound repeatedly. The way the platform was structured was basically least common denominator; the set of features is the subset of what all the platforms support. Well, this is how they describe it, sometimes a feature just does not work on a platform or it works unexpectedly. One such example is the combo box, there are options for Simple and Drop Down, in Windows these are two different things in Linux they are the same. So you say “It fails gracefully and uses what it can.”, this is not the case with printing, on every platform printing is fairly straight forward you set up your printer dialog, user selects a printer, you give the printer what needs to be printed and you are done. Printing on Solaris x86 isn’t quite the same, it just does not work

My biggest issue with SWT is its lack of builds for Solaris. When Eclipse 3.2 was released there was an Early Access release for Solaris 10 x86, after that it disappeared. Eclipse has taken the stance that it is Sun’s job to build and release the binaries for their machines, and sun is not doing it. This sounds like the Mac Java 6 issue (it has been beaten with a stick but I will hit on it and update this link when I do), where one side makes it sound like it’s the other person’s problem. I do not see things this way if it is your product and it has a problem in the production line, make it YOUR product’s problem and fix it as if it were your problem. Travelocity had this issue where hotels were losing reservations that had been passed on to them, it is clearly the hotels problem however Travelocity took it upon themselves to hire a company to call hotels and check that hotels had the reservations before people arrived. (Origional NY Times Article 37 Signals Post) If Sun is not willing to help make the product successful (and who can blame them, SWT, and its parent IBM is a competitor to them) make it the Eclipse Foundations Problem by some Sun boxes and build your product on them, do not leave it up to people like even if they are willing to pick up the slack who knows what is missed here and there and what problems there are. While I commend them for getting Eclipse built for Solaris x86 and Sparc it is not their job.

Java was built on the ideal that write once run anywhere and SWT is not living up to that ideal. Eclipse needs to step up to the plate, they need to complete their product and make it truly cross platform. Kudos to Travelocity for going the extra mile and until the Eclipse Project learns to follow in their shoes they are doing a disservice to the Java community and programming in general.