Eclipse is worse than any commercial IDE (in an ideal world)...

At his keynote at EclipseCon 2007, Robert Lefkowitz made the following provocative statement: "Eclipse is probably worse than any commercial IDE!". Why? Because it's free! In an ideal (capitalistic!?) world you don't pay for anything that you can get for free. Any tool that is worse than a free tool would just run out of business (if both tools would cover the same market). Well, and we have seen quite some commercial IDEs die, since eclipse is available.

One implication of this observation is, that when eclipse increases it's quality, competing commercial products have to increase their quality to survive. But wait! Instead of improving the quality of your commercial product, you could just prevent eclipse from become better. I know, this is very provocative. Fortunately, making (and saving) money is not the only force in our world. And fortunately, the way eclipse is organized, this will not happen:

Although, most of the work on eclipse is sponsored by companies that sell products based on eclipse, the work is done by individual committers. And the human factor is very important. Everybody can see what committers do. It's not anonymous hackers that do the work, because unlike wikipedia, anonymous users cannot change eclipse. Eclipse is a social community with a focus on individual responsible committers. This is very important for the survival of eclipse. That's why new committers have to be voted into protects after they have shown credibility. That's why new projects must have committers from multiple companies. Eclipse committers are humans with emotions. Nobody wants to be accused of being destructive.

It is an honor to be an eclipse committer.

My favorite 3.3 feature: Quick Access

I just looked into Eclipse 3.3 - New and Noteworthy. Lots of cool new things! My favourite is Quick Access. This essentially allows you to type commands instead searching the command in the menus. If you have customized your perspective, to get rid of annoying tool-bar buttons, you still have access to commands that are not visible in any menu or tool-bar!

I have bound Quick Access to ESC-X (like in emacs) and it feels a bit like the emacs minibuffer.... Very cool!

BTW: I wish eclipse would allow links into the "News and Noteworthy" pages (see bug 194993), that's why I created my own copy of "News and Noteworthy"...

I don't like XML! But what are the alternatives?

I think XML is one of the worst formats for data. It is extremely ambiguous. There are so many ways to put a simple data structure into XML. For example:

<book 
    title="The Return of the King"
    author="J.R.R. Tolkien"/>

or

<book>
  <title>The Return of the King</title>
  <author>J.R.R. Tolkien</author>
</book>

And in the second case, can there be more than one author? And more titles?

XML is not self describing. Look at the XML below. It is very ambiguous (if you don't use one of the many schema descriptions (DTD, XML-Schema, XMI, DSD, ...)).

<data
 x="null"
 y="true"
 z="42">
 <a>NULL<a/>
 <a>false<a/>
 <b>TRUE<b/>
</data>

What is a String? What is Boolean? What is a number? Is x a list? You simply can't infer it from the XML. When you want to write the data, which fields are written as tags which are written as attributes?

There is also a huge problem with IDs and references. From a plain XML file there's no way to figure out what an id of an object is and what references are. A good example are plugin.xml files. They are full of IDs and references but it is so hard to know which string refers which other XML element. Control-click does not work. Why? Because references are difficult to resolve!

Are there any good alternatives?

JSON is much simpler, self-describing, less verbose and much better suited for data storage and exchange. But it has no notion of IDs and references. And it does not name object (record) types (it has only lists, maps, strings, numbers and boolean).

What else is out there? I want something like JSON + an ID/Reference model + named Records...

Customize Perspective is annoyingly inflexible...

I just read Kims post about removing removing the default visibility of the menu and toolbar Working Set items. It triggered once again one thing that annoys me from time to time, the inflexibility of the Customize Perspective dialog:


You can either enable both, Menubar and Toolbar items or nothing. That is very annoying, because it breaks the principle that the toolbar items are optional. Unless the provider of the actionSet defines two action sets, one for the toolbar and one for the menubar, you have the choice between all or nothing.... But providing two action sets would duplicate the number of item on the command tab, which is already overloaded.

I think it is not the responsibility of the plugin writer to decide which items the user wants to see in the toolbar! (See bug 182714)

Surprises in eclipse 3.3: double click instead of single click

Since some time, the 3.3 patch editor (Team->Apply patch...) does not work for me anymore. Well, I was using patched milestones (we had some enhancements for the patch editor in our product). So, I was not surprised that it did not 100% work. What went wrong? If I select a file to patch, nothing is shown in the compare area below:

Since the problem remained even with an unpatched 3.3m7, I filed bug 186481 and after some discussions, it turned out that I have to double click instead of single click to select the patch. That was not obvious to me! In 3.2 a single click was enough! After double clicking the patch it looks like this:

Now I see exactly what I expected! But why double click? Well, because calculating the diff is expensive and doing that by simply selecting a file may not be a good idea... Another reason is that there's now a context menu on the items in the "Patch Contents" pane and you don't want to do the expensive calculation of the diff just to get to the context menu. Therefore, the paradigm changed from master-detail to open semantics.

But this is not without drawbacks! First of all, I'm sure I'm not the only one stumbling over this problem. Actually the semantics has changed in other compare related views too. If you set Preferences...->General->Single Click, you get the old master-detail behaviour.

Second drawback, is that the selection and what you see easily may get out of sync. Look at this screenshot:

What happened? I have selected (not double clicked) the plugin.properties file but the difference of a java file is shown. The bad thing is there is no indication which java files is shown here! Unfortunately it's too late in the game to change this (see bug 186481 for further details)...

Take-home message: Report bugs early enough....

No real support for dynamic extensions (aka dynamic plugin.xml)

Eclipse allows (theoretically) to add extensions dynamically (see "Leave Eclipse plug-in headaches behind" or "Contributing items to a toolbar dynamically"). Unfortunately, there's no way a normal plugin can do this without using internal classes :-(. Here's the proposed hack how to do it:

  IExtensionRegistry reg = RegistryFactory.getRegistry();
  // ExtensionRegistry is internal!!!!
  Object key = ((ExtensionRegistry) reg).getTemporaryUserToken();
  Bundle bundle = Activator.getDefault().getBundle();
  IContributor contributor = ContributorFactoryOSGi.createContributor(bundle);
  try {
   //  I have the content of my dynamic plugin in a file 
   // called dynamicplugin.xml
   InputStream is = FileLocator.openStream(bundle,new Path("dynamicplugin.xml"), false);
   reg.addContribution(is, contributor, false, null, null, key);
  } catch (IOException e) {
  }

Unfortunately ExtensionRegistry is an internal class and getTemporaryUserToken() is not exposed in any official way. Bug 112954 asks for a way to get to getTemporaryUserToken(). The solution is to use null as the key (token). Well, almost. In order to make this work, the system property eclipse.registry.nulltoken has to be set to true (Bug 112954 comment 25). But a normal plugin cannot set a system property before OSGi starts....

This effectively means: there is no way a normal well behaving plugin can provide a dynamic extension. Therefore I filed bug 174967 to fix that problem....

java.net.URL.equals and hashCode make (blocking) Internet connections....

Sometimes simple calls have unexpected side effects. I wanted to update some plugins, but the update manager was hanging my UI. Looking at the stack trace reveals:

at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source)
at java.net.InetAddress.getAddressFromNameService(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at java.net.URLStreamHandler.getHostAddress(Unknown Source)
- locked <0x15ce1280> (a sun.net.www.protocol.http.Handler)
at java.net.URLStreamHandler.hashCode(Unknown Source)
at java.net.URL.hashCode(Unknown Source)
- locked <0x1a3100d0> (a java.net.URL)


Hmm, I must say that it is very dangerous that java.net.URL.hashCode (and URL.equals) makes an Internet connection. java.net.URL has the worst equals/hasCode implementation I have ever seen: equality depends on the state of the Internet. Well in the javadoc of URL.equals it says: "Since hosts comparison requires name resolution, this operation is a blocking operation.", but who reads the documentation of equals? There is a general contract around equals. Joshua Bloch writes in Effective Java: "Don't write an equals that relies on unreliable resources" (Chapter 3, page 34). Hey Sun, as far as I know, the Internet is not reliable ;-)

Do not put java.net.URL into collections unless you can live with the fact that comparing makes calls to the Internet. Use java.net.URI instead.

URL is an aggressive beast that can slow down and hang your application by making unexpected network traffic.....


I wonder if other people find this behaviour as shocking as I do....

Tip: debug (and patch at runtime) an installed eclipse

Today I had a problem that occurred only in my installed eclipse but not in my runtime workbench.

How to start eclipse so you can attach a debugger?

You have to add the following to the vmargs: -vmargs -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009
The 9009 is used later to attach to eclipse.

How attach to eclipse?

• create a new Debug->Remote Java Application.
  
• Set the port to to 9009 (or whatever you use as the address argument in your eclipse launch)
  
• On the Sources tab add the projects that you want to debug..
  

How to "patch" the running eclipse?

Just modify the code. Actually, I discovered this by accident. My problem was an obvious bug (missing check for null), so I fixed in during the debug session. And the usual eclipse "magic" fixed the bug in my running eclipse. It's the hot code replacement that normally happens. I (falsely) though that would only work when I start a runtime eclipse from within eclipse. But it works in any case.

Now I can fix my running eclipse while I'm normally working. The only downside is, that the two eclipse must use two different workspaces. Too bad.

Here's a flash demo video that shows how to do this step by step.

Help! How to manage multiple (RCP) applications in one installation?

Maybe someone reading my blog can help me. I posted essentially the message below to the equinox newsgroup and the platform newsgroup with zero response. Maybe RCP in the headline will help getting someone to read my post ;-)....

How to restrict the plugins visible to an application?

We have several applications (some of them are headless) that run from within the same eclipse installation. The problem is, that all plugins are visible from the applications. This cause problems, if extensions are used that load plugins that cannot run in the context of the headless application.

To illustrate the problem I use a simple example. A headless application that uses the org.eclipse.core.variables plugin to expand a variable. The org.eclipse.core.variables is UI free and therefore no problem. But some plugins that contribute to the variables plugin are not headless. To illustrate this, I use the ${selected_text} variable that is defined in the org.eclipse.debug.ui plugin. This causes the application to fail.

  public class MyApplicationWithVariables implements IPlatformRunnable {
    public Object run(Object arg) throws Exception {
      IStringVariableManager vm=VariablesPlugin.getDefault().getStringVariableManager();
      String message=vm.performStringSubstitution("Hello ${selected_text}!");
      System.out.println(message);
      return EXIT_OK;
    }
  }

   <extension
         id="HelloWorldWithVariables"
         name="Minimal Headless with variables"
         point="org.eclipse.core.runtime.applications">
      <application>
         <run class="gr.scharf.minimal.headless.MyApplicationWithVariables"/>
      </application>
   </extension>

Is there a way to restrict the plugins visible or loadable to an application?
Or is the only way to have a copy of the installation containing only the "good" plugins?

Michael

How the eclipse update manager could look like...

One of the features I don't like about eclipse is the update manager. A few weeks ago, I looked at different alternatives of eclipse update managers. Today Chris Aniszczyk blogged about the FireFox update manager. Interestingly, a few days ago, I created a small flash video on the FireFox update manager, because I think that shows what a user expects from a simple to use update manager.

One of the central paradigms of eclipse the idea of plugins. However from a user perspective, managing plugins is a nightmare. The eclipse update manager is way too complicated, too slow, not robust enough.

Few weeks ago I bought Eric Evans book "Domain Driven Design". I'll blog about it separately. One of the central ideas is what he calls "ubiquitous language" (e.g. read chapter one). The basic idea is to come up with a language to describe the problem domain, in our case the installation and update of plugins. The language is not only used in conversations but also represented by a formal model. The formal model is implemented in code. You can start reasoning and discuss about the model.

If I look at the eclipse update manager, the model used is a very technical model that is totally implementation centric. It is not a model a user of the update manager can simply understand. I think this is the root of the problem. We have to come up with an update manager domain model that represents the problems and tasks a user of eclipse faces and not a model that is focused on the implementation. The current implementation could be used to implement the user model, but in it self it seem not the right abstraction for users.

The FireFox update manager has an easy to understand domain model that is shown in the UI. There are extensions. An extension has an icon, a description and a set of preferences (yes the preferences of each extensions is available directly from the "Extensions" dialog. In eclipse there's no way to find out what an extension contributes to eclipse. See my blog entry "When seamless integration becomes a nightmare..."). Anyway, hit a simple button to check for updates. It's done in seconds (not minutes like eclipse). Once downloaded, you can update the plugins you want to update.

If you don't like an extension you can select an extension and "Uninstall" it. Something that is not possible with the eclipse update manager. Eclipse is a grow only system -- no way to remove features. Like windows in the old days. Once you have installed a feature there's no way to get rid of it. Only, if you regularly do backups (like I do), you can revert a previous version of eclipse by reverting a backup. But eclipse itself is grow only (*). If you have installed a few features you don't like and you cannot get rid of, you will start thinking twice if you want to install a new plugin. That's very bad for the eclipse ecosystem.

Eclipse must solve the update manager problem soon and provide a simple to use and understandable update manager that solves the problems of eclipse users.

Domain Driven Design could help come up with a update manager domain model that is relevant for eclipse users...

Michael

(*) You could also use separate extension locations for each feature you install and simply delete the location if you want to uninstall the extension. But that's a hack. The update manager (UI) does not even support dropping of extensions. I tried that for a while, but it requires a lot of discipline.