Tim Anderson’s ITWriting

In May 2009 the open source Eclipse project surveyed its users. Visitors to the Eclipse site were asked to complete a survey, and 1365 did so. That’s out of around 1 million visitors, which shows how much we all hate surveys. Anyway, this report [pdf] was the result. A similar survey [pdf] was carried out in 2007, potentially making a valuable comparison, though the earlier survey has different questions making direct comparisons difficult in most cases, which is a shame. I especially missed the detail on which Eclipse projects are used most which is well covered in the 2007 report.

Here is what I found interesting. First, there’s a shift towards Linux and Apple Mac in the desktops developers use for Eclipse. In 2007 it was 73.8% Windows, 20% Linux and 3.5% Mac. In 2009 it is 64% Windows, 26.9% Linux and 6.9% Mac.

This is echoed in deployment platforms too (client and server). In 2007 it was 46.5% Windows, 36.6% Linux, 1% Mac; today it is 40.5% Windows, 42.7% Linux, 3% Mac.

Those surveyed were asked what other IDEs they used. I noticed that Microsoft Visual Studio and NetBeans feature fairly strongly; I also noticed that Embarcadero’s JBuilder is hardly a blip on the chart – intriguing, given how popular this used to be in the pre-Eclipse era.

The most popular code management tool is Subversion (57.5%) followed by CVS (20%). For build tools, Ant (33.4%) and Maven (18%).

Here’s an intriguing one: I often hear that Java is only successful on the server. That presumption is not supported by this survey. 23.4% said that desktop client apps are the primary type of software they are developing, compared to 30.2% server, and 24.7% web or RIA apps.

The preferred app server is Apache Tomcat (34.8%) followed by JBoss (12.7%) and Websphere (6.9%).

The most popular database manager is MySQL (27.7%) followed by Oracle (27.3%). That’s 55% for Sun+Oracle, of course, though bear in mind that many of the MySQL users are likely attracted by its free licence.

Before drawing too many conclusions, bear in mind that it is a small sample self-selected by people willing to take the survey; apparently it was also featured by a German technology site which resulted in a larger response from German visitors.

Although it suggests a declining use of Windows – which is especially plausible given the trend towards web applications – it does not prove it beyond the Eclipse community.

And next time – how about using the same questions, which would make it possible to identify trends?

I’ve also written about Eclipse here: The Eclipse Conundrum: can it grow without hurting its contributors?

Evans Data has published its 2009 Software Development Platforms survey, to which around 1200 developers contributed, scoring their chosen development tools in eighteen different categories.

The tools covered are Eclipse, Embarcadero’s Delphi, IBM’s Rational Suite, IntelliJ, Microsoft’s Visual Studio, NetBeans, Oracle JDeveloper and Sun Studio.

I was sorry not to see more products covered. Flex Builder Flash Builder, Zend Studio, Aptana and JBuilder would all have been interesting, for example. Each developer only scored the product they actually use (a good thing), so the sample is not as big as it first appears.

I’m also mistrustful of the survey results, particularly when you look at it in detail. For example, one of the categories is “Support for frameworks”.  Visual Studio came top, while Eclipse was last. But hang on: in Visual Studio (for example) are we talking MFC, or .NET Framework? The development experience for each is totally different. And were developers primarily judging on the framework tools, or the framework itself? It is hard to attach much meaning to the scores in this category.

Another flaw: the versions of the products is not specified. That means a weakness may have been fixed in a later version, but the survey does not tell you.

A third flaw: some tools are weak in several categories, dragging down their overall score, but that does not matter to developers who do not use them for that purpose. It is hard to compare like with like.

Still, while I’m wary of the survey overall, I though it brought out some interesting points. One is that developers were asked what features matter most to them. So:

The three things developers care about most (highest priority first):

1. Basic tools (editor/compiler/debugger)

2. Documentation

3. Tool integration

The things developers care about least (lowest priority first):

1. Support for remote development

2. Support for parallel programming (sorry Intel!)

3. App Modeling tools

What about the winners and losers in the survey? I almost forgot. IBM’s Rational Suite came top, followed by Microsoft’s Visual Studio. Eclipse came last, though it still got a decent score, well below its rival NetBeans.

The low ranking for Eclipse (which is nevertheless wildly popular) deserves some comment, particularly as the top tool, IBM Rational Suite, is built on Eclipse. I spoke to Eclipse executive director Mike Milinkovich while researching this Register piece recently. One of the points we discussed was the tension (if there is one, which he disputes) between tools vendors sharing resources to build the best possible platform, and holding resources back to retain commercial differentiation. I’ll write this up in more detail shortly; but it shows why certain areas in Eclipse may not receive the attention they deserve – localization was a specific example.

Another problem with Eclipse is that it is all a bit messy, confusing and hard to manage, particularly in a team where you want every member to have an identical setup. It is still worth it though, for the riches it provides for free.

Sun’s Simon Phipps stirred things up last weekend when he called Google’s actions wanton and irresponsible. Its crime: delivering a cut-down Java library for use on its App Engine platform, “flaunting the rules” which forbid creating sub-sets of the core classes.

It does sound as if Google is not talking to Sun as much as it might. Still, let’s note that Google has good reason to omit certain classes or methods. App Engine is a distributed, shared environment; this mean that some things make no sense – for example: writing to a local file – and other things may be unacceptable, such as grabbing a large slice of CPU time for an extended period.

Salesforce.com addressed this same issue by inventing a new language, called Apex. It’s Java-like, but not Java. The company therefore avoided accusations of creating an incompatible Java, and conveniently ensured that Apex code would run only on Force.com, at least until someone attempts to clone it.

Google’s approach was to use Java, but leave a few things out. This FAQ gives an overview; and the article Will it play in App Engine lists common frameworks and libraries with notes on whether they work. Given that languages like JRuby, Groovy and Rhino work fine, it’s clear that core App Engine Java is not too badly damaged. The big omissions are JDBC (because you are meant to use the App Engine datastore, which is not relational), and Enterprisey things like JMS, EJB and JNDI. Google is nudging, or shoving, developers towards RESTful APIs along with its built-in services.

Will you be able to escape App Engine if you have a change of heart after deployment? I’d guess that porting the code will not be all that hard. Perhaps the biggest lock-in is with identity; you could roll your own I guess, but Google intends you to use Google accounts and supplies a Java API. Microsoft is ahead of Google here since it does support federated identity, if you can get your head round it: you can authenticate users in the Microsoft cloud against your own directory using Geneva. The best Google can offer is Directory Sync; though even that is some protection from identity lock-in.

Java support on App Engine is actually a vote of confidence in Java; if what is good for Java is good for Sun, then Sun is a winner here. That said, just where is the benefit for Sun if companies host Java applications, built with Eclipse, on Google’s platform? Not much that I can see.

I ran into a strange and surprising PHP error today. I’m working on a little PHP application which has a login page. The login script calls session_start() to start or resume a PHP session. It was working OK so I decided to decorate the page a little (I was working in Eclipse). I like to try a variety of tools, so I ran up Microsoft’s Expression Web, added an image, then re-ran the script to see how it looked.

The answer was not good, because I now had an error:

Warning: session_start(): Cannot send session cookie – headers already sent

I puzzled over this for some time. The error was in line 0 of my login page. I couldn’t see anything that was different from before, except the static image that meant nothing to PHP.

Eventually I worked it out. Eclipse (running on Windows) created the PHP files using ANSI. On saving, Expression Web silently changed them to UTF-8. That in itself was no bad thing – it’s usually a better choice – though I reckon it should ask. The bigger problem was that Expression also added a BOM (byte order mark) to the beginning of the file. This is actually optional for UTF-8, and most non-Windows editors do not add it. It happens to flummox PHP, which interprets them who-knows-how and sends some output to the browser, preventing session_start from working.

This is particularly painful to debug since most editors do not display the BOM; they simply use it to confirm the character set in use. So you can have file A which works, and file B which does not, and they are character-by-character identical.

One way to see and remove the BOM is to open it with Edit.com, which does not understand it at all:

I guess both Expression and PHP could do better here. The bit that puzzles me is that I can’t be the first to run into this. Doesn’t Microsoft know that its UTF-8 BOM breaks PHP files, at least on the two versions I tried (XAMPP on Windows and PHP 5.2.1 on Linux)? I can’t even see a preference in Expression that would prevent it being written. And if you remove it, and then re-edit in Expression, it carefully writes it back. Unlike Adobe’s Dreamweaver, which leaves well alone.

PS if you want to know all about BOMs, see here.

Update: See comments – apparently this was fixed in Expression Web 2.0. Tina Clarke discusses the problem here.

News from the Adobe MAX conference this week in San Francisco: Ensemble has developed an add-in for Visual Studio for Flex development, code-name Tofino. It’s currently in beta and available for download. Flex is Adobe’s developer-focused SDK for Flash applications.

I installed it this morning, and so far it does not impress. There is zero documentation (just a few links to the standard Flex docs on Adobe’s site), and it lacks even MXML Intellisense, let alone a visual designer. When you go to project properties, there is nothing to configure. The toolbox is also empty. On the plus side, it successfully invoked the Flex compiler to build the project, and managed to open it as a static file in Internet Explorer when I clicked Debug. I’d prefer an option to use Visual Studio’s built-in web server for debugging. There must be more to it than this; then again it is advertised as a beta which is meant to mean well advanced (ha ha). I suggest sticking firmly with Flex Builder for the time being.

Adobe has largely ignored .NET in its Flex and AIR technology, though it does support SOAP. I am not sure whether this is caused by aversion to Microsoft, or an assumption that Microsoft developers will use Microsoft technologies like Silverlight or Windows Forms, or a bit of both. Integration with Visual Studio and server-side .NET could be significant for Flex adoption, though it would be better if Adobe itself were doing the add-in.

You can see the same thing happening on Microsoft’s side, with a half-hearted Silverlight project for Eclipse (which only works on Windows), or the well-regarded Teamprise which integrates Eclipse with Visual Studio Team System. In both cases Microsoft keeps itself at arms length, which does not have the same impact as in-house support.

There are always concerns about the quality of third-party applications. I am sure Adobe itself would not have put such an inadequate preview up for download, as Ensemble has done for Tofino.

It’s a shame that the Eclipse ALF (Application Lifecycle Framework) project has closed:

… given the level of community participation, the appropriate course for ALF is to close down the project. Unfortunately, our recent efforts did not identify potential contributors willing to justify keeping the project active.

says project lead Brian Carroll. The project aimed to enable interoperability between ALM (Application Lifecycle Management) tools from different vendors. Here’s the problem statement from the project page:

Application development today is achieved through the use of numerous tools from software vendors, open source communities and some are even home grown. Getting these tools to work together is an integration problem that has never been solved. Each vendor and open source project creates their own API standards and many hours of effort are required to create even the most straightforward of integrations.

The problem is real, so why the lack of participation? Of the major ALM vendors, only Serena gave it serious backing. The project could not succeed without either IBM, or a solid alliance of IBM’s competitors.

My interpretation: those ALM vendors will have considered whether it was really in their interests to help customers integrate their tools with those from rivals. Good for customers, yes, but vendors want to keep you hooked on their product suites. “Buy more from us, it integrates with what you have already” is a great sales point. Since only the participation of those vendors could make ALF work, the project was doomed.

It is another manifestation of what Salesforce.com CEO Marc Benioff calls “an aspect of our industry”.

Everyone loves standards, right?

I’ve been doing a little PHP work and enjoying it; I like PHP 5.x much better than earlier versions. My PHP development setup is based on Eclipse and the PHP Developer Tools project, or PDT, and one thing I noticed when I set this up is that it is awkward to use PDT with Eclipse 3.4, or Ganymede. I ran into problems again when I updated my Ganymede Eclipse to the latest releases, this time on Windows as it happens. PDT stopped working, and I had to download a newer “integration build” of PDT as well as an update to the Eclipse Dynamic Languages Toolkit (DLTK), using a manual download and import process instead of the built-in Eclipse online update. I also had to remove the Ruby Development Tools as these relied on an earlier version of the DLTK; there might be a way round this but my priority was to get PDT working.

I’m getting this pain because I want to use PDT 2.0 and Eclipse3.4, instead of the older PDT 1.0.3 which has an all-in-one download based on Eclipse 3.3. “All-in-one” means that you download a bundle which includes both Eclipse and PDT, and treat it as a separate standalone IDE. The question though: why wasn’t the PDT properly integrated with Ganymede, which brings together multiple Eclipse projects with the promise that they will all work together?

I looked in the Eclipse PDT newsgroup and found some discussion on the subject. Apparently the PDT team felt it was just too difficult to manage the dependencies. More depressing is that apparently the team feels the same way about Galileo, the follow-up to Ganymede expected in June 2009. It means that the PDT stays outside the mainstream of Eclipse projects, reducing its visibility.

Conspiracy theorists might surmise that major PDT contributors like Zend, which has its own commercial IDE called Zend Studio which uses both Eclipse and PDT, might enjoy keeping the free version low-profile. That (or some other reason) might also explain why Zend Studio uses a 1.x version of PDT along with Eclipse 3.4, which is not meant to work. It turns out that Zend Studio uses PDT 1.0.5, whereas the latest public download (unless you go directly to the source) is 1.0.3. If 1.05 works fine with Eclipse 3.4, why isn’t the public all-in-one based on this combination?

I like the PDT, and my patched together Ganymede + PDT 2.x works very well. Debugging seems more stable since I updated it. Personally I’d like to see PDT get more prominence within the Eclipse community, and for it to be packaged as part of Galileo rather than being left on the sidelines.

This provoked a wry smile, from a Reg Dev article on the forthcoming Eclipse 4:

Underpinning all this, though, is an attempt to escape the “baroque” 3.x codebase for something that’s simple, clean and modular. That means eliminating repetition in code and interdependencies found in the monolithic 3.x.

“It’s getting to the point where it’s difficult to reach in and fix a bug without impacting lots of other things,” one e4 committer told EclipseCon.

Now, Eclipse is a child of the refactoring era. It is built using an MVC (Model-View-Controller), component-based, plug-in architecture. Design patterns guru Erich Gamma worked on Eclipse and on its Java Development Tools.

If Eclipse is now a ball of spaghetti, what went wrong? Though its possible the problems are being over-stated in an effort to justify version 4.

Technorati tags: eclipse, erich gamma, mvc, java, refactoring

Erich Gamma spoke at Qcon London on the subject of “How Eclipse changed my views on software development.” Or did he? This was a somewhat schizophrenic talk; in part an articulation of general development principles, and in part a description of how Eclipse is developed. Gamma spelt out the Eclipse philosophy, the starting point being that everything is a a plug-in; that APIs matter a lot and its better to get a small API right rather than get it wrong and have to support it for ever.

He then talked about iteration, a key tenet of agile development. He showed a great slide which charted the progress of some projects, from “all the time in the world” at the beginning, to “say goodbye to your loved ones” at the end, followed by total exhaustion after the thing is shipped. Iterative development with continuous builds and sign-offs every 6 weeks is less stressful and more productive.

It’s a great point, but does this work in every instance? What if you have a game to ship for the Christmas market?

He also talked about the benefits of open source development: transparency between developers and customers, critical mass of community activity, frequent feedback, and so on. Nothing new here; but perhaps this simply demonstrates the extent to which the merits of the open source model have become accepted.

Gamma then focused more sharply on Eclipse. He says there is a major new release every year, and they don’t want to ship in the summer or near Christmas, so they ship in June.

He described how the Eclipse project manages its large international team. It comes down to components: developers are divided into teams on specific sites, and each team manages one or more components, and has its own process for planning, building and testing. A weekly integration build prevents incompatibilities between components from getting out of control.

Towards the end of his session, Gamma gives us a tour of Jazz, IBM’s open source but commercial project for collaborative software development. Interesting, but I’m not sure that this product pitch belonged in a talk that was billed as something more general.

Overall: good insight into how Eclipse comes together, but not too exciting. I don’t envy these guys who face heightened expectations because of significant contributions they have delivered in the past. Nobody can change the world daily.

Today I’m at QCon in London. I enjoyed this conference last year, when among other things I got the scoop on Microsoft’s Volta (then LINQ 2). First up this year is Erich Gamma of Design Patterns and JUnit fame, who will be talking about how Eclipse has influenced his view of software development (others would talk about how Gamma has influenced Eclipse). I’m also intrigued by what Google’s Gregor Hohpe is going to say about “The Cloud as the new middleware platform.” It’s going to be an interesting contrast to Microsoft’s Mix08 conference last week. Be sure I’ll be reporting back here; or if you’re here too, by all means get in touch.