The importance of a clear description for bug 8009

For the nth time bug 8009 "Split File Editor" is discussed - n being rather large... This never-ending story is one of my favorite pass times when it comes to following Eclipse bugs... I really only have one wish: we need some new and fresh comments.

Well... lately, there have been some development in the comments, as already described by Holger Voormann, a bounty has now been started. In my book, the people behind the bounty now only need three things: a clear description, sufficient funds and a convinced committer. Will that happen? I think not.

In order to ask somebody to create a patch, the bounty givers/providers (?) must agree on a clear description of the problem and the wanted solution. Looking quickly through the 146 (!!) comments, I have not found a clear description of the wanted solution - actually I have found many different vague descriptions -, so one must wonder: does the current bounty givers have a common consensus for the wanted solution? If that is not the case, I can only guess that some of the people are going to be rather disappointed when they see a solution...

Most of the committers of the platform seems to agree, that the any implementation of this bug is going to be non-trivial. Thus, one must expect that the bounty for the bug must be relatively large - unless somebody goes the for the bounty just for the fame. But it is not enough to create a patch for the bug: as the patch is going to be relatively large, all sorts of committer rules are going to be in effect. Remember that somebody will have to maintain the patch afterwards. I.e. one of the existing committers for the platform must accept the provided patch as his/hers own and maintain it ever after. (Admitted, here I take it for granted that the bounty givers are not going to collect enough funds to pay for the continued maintenance of the solution... not an unreasonable assumption, I think).

I make my living by developing or help developing Eclipse RCP applications. So as a consumer of the Eclipse sources, I really, really don't want anything new in the platform unless all of the current committers can vouch for the solution. The platform has to be rock solid, otherwise we cannot base mission critical application on top of the sources. (Yes, I know that this basically means the development of the platform is almost none as the current code base is so old and complicated, but... that is exactly only of the aims of the e4 project, right?)

So... summa-sumarum: 1) you need a clear description of the problem, 2) you need funds and 3) you need to convince an existing committer that your solution is sound and good...

I can see 2) happen, I think 1) is going to be hard and 3) is going to be nearly impossible!

Dependency Injection in e4 Revised

EclipseCon is the perfect occasion when you want to discuss the way things are done in the various projects of Eclipse. Not only will almost everybody that matters in the projects be present at the conference, but there are usually also plenty of opportunities to get the right people together to discuss stuff.

In this case, I asked for a BoF on the use of Dependency Injection in e4 based on a previous blog entry on the subject titled "Dependency Injection in e4 - just why do we want to do that?". 9 people showed up and we had a pretty good discussion on the use of DI in e4 and how the usability could be improved.

The results can be found in a number of bug reports:

• Bug 300099 - How developers are expected to discover injected values?
In comment 7 Paul Webster sums up the discussions quite nicely.
• Bug 307061 - Use annotations for invoke
• Bug 302824 - Add support to get easy access to workbench services without DI

All in all, I have to say, I fell a lot better about dependency injection now than before the BoF. With these changes, we will suddenly have most of the usual tooling in e4 as we know it in 3.x....

Dependency Injection in e4 - just why do we want to do that?

Lately, I have been giving a number of presentations of Eclipse e4. The focus has been on the changes that we will see when we program for e4 rather than 3.x.

With all the presentations, there have been a very lively discussion on the pros and cons of the new technologies in e4, but one subject in particular have been discussed: the use of Dependency Injection (DI) and what it will mean for productivity, testing and the tooling in Eclipse we all have grown so used to.

The following examples are taken from the excellent e4 contact manager by Kai Tödter that shows off some of the interesting features of e4 including theming and DI. The manager is very e4'ish and use the e4 features as these are probably meant to be used - with other words, I don't fault Kai for the examples or the problems I find in the examples.

At first glance the use of DI seems to give some very understandable code and it has the potential to do away with some of the listener code that we see in many places in 3.x code.

E.g. to follow the current selection in a view - here just expecting a single selected object - you would do something like the following in 3.x (forget about removing the listener again...):

public class DetailsView extends ViewPart {
  @Override
  public void createPartControl(Composite parent) {
    // ...

    final ISelectionService ss = getSite().getWorkbenchWindow().getSelectionService();
    ss.addPostSelectionListener(myListener);
    myListener.selectionChanged(null, ss.getSelection());
  }

  protected void setSelection(Contact contact) {
    // ... do something with the selection
  }

  private final ISelectionListener myListener = new ISelectionListener() {
    @Override
    public void selectionChanged(IWorkbenchPart part, ISelection selection) {
      if (!(selection instanceof IStructuredSelection)) {
        setSelection(null);
        return;
      }

      final IStructuredSelection ss = (IStructuredSelection) selection;
      if (ss.isEmpty() || !(ss.getFirstElement() instanceof Contact)) {
        setSelection(null);
        return;
      }
      setSelection((Contact) ss.getFirstElement());
    }
  };

  // ...
}

whereas, you will just do something like this in e4:

public class DetailsView {
  @Inject
  public void setSelection(@Optional @Named(IServiceConstants.SELECTION) Contact contact) {
    // ... do something with the selection
    
  }

  // ...
}

So far, so good. A lot less code compared with the 3.x version and the intension is quite clear once you know the injection is persistent, so changes in the context is automatically propagated to the view.

The main difference between the two versions lies in the way that you find and access services: in 3.x you basically have a Java method chain - here getSite().getWorkbenchWindow().getSelectionService() - where the e4 version uses a magic class or string - here @Optional @Named(IServiceConstants.SELECTION). The general Java tooling helps us access the services in 3.x, but what type of tooling will help us in e4? And how will we get warned about accidental changed in the e4 string?

A much more problematic example - as far as I am concerned - can be found in the SaveHandler of the contact manager. This handler is used to save the current contact in the details view by delegating the save functionality to the doSave method of the view (Again, I have cut away some irrelevant stuff):

public class SaveHandler {
  public void execute(IEclipseContext context, @Optional IStylingEngine engine,
      @Named(IServiceConstants.ACTIVE_SHELL) Shell shell,
      @Named(IServiceConstants.ACTIVE_PART) final MContribution contribution) throws InvocationTargetException,
      InterruptedException {
    final IEclipseContext pmContext = EclipseContextFactory.create(context, null);

    final ProgressMonitorDialog dialog = new ProgressMonitorDialog(shell);
    dialog.open();

    dialog.run(true, true, new IRunnableWithProgress() {
      public void run(IProgressMonitor monitor) throws InvocationTargetException, InterruptedException {
        pmContext.set(IProgressMonitor.class.getName(), monitor);
        Object clientObject = contribution.getObject();
        ContextInjectionFactory.invoke(clientObject, "doSave", pmContext, null);
      }
    });
    // ...
  }
}

Basically the handler creates a new context for the operation, opens a progress dialog, installs the progress monitor in the context, and then delegates to the doSave method with the new context.

The problem is found in the inner run methods: the name of the method of the view that is used to do the save operation itself is hard-coded as a string. How is this ever going to work with the Java tooling? How can we get quick assists or refactoring to work here? And how will we maintain this?

There are also some other problems with regards to testability. E.g. if a new doSave is ever created in the view, this will not provoke either a compile-time or a run-time error, but instead just execute both methods.

In the 3.x version, I would let the views that supports the doSave method implement a common Java interface - e.g. IDoSaveable and then test for this in the handler. An example of how this can be done is shown below:

The interface:

public interface IDoSaveable {
  void doSave(IProgressMonitor monitor);
}

The view:

public class DetailsView extends ViewPart implements IDoSaveable {
  @Override
  public void createPartControl(Composite parent) {
    // ...
  }

  @Override
  public void doSave(IProgressMonitor monitor) {
    // ... do save
  }
}

The handler - note that this version uses adaption, but you could use instanceof instead:

public class SaveHandler extends AbstractHandler {
  @Override
  public Object execute(ExecutionEvent event) throws ExecutionException {
    final IWorkbenchPart part = HandlerUtil.getActivePartChecked(event);
    final IDoSaveable saveablePart = (IDoSaveable) Platform.getAdapterManager().getAdapter(part, IDoSaveable.class);
    if (saveablePart != null) {
      final Shell shell = HandlerUtil.getActiveShellChecked(event);
      final ProgressMonitorDialog dialog = new ProgressMonitorDialog(shell);
      dialog.open();

      dialog.run(true, true, new IRunnableWithProgress() {
        public void run(IProgressMonitor monitor) throws InvocationTargetException, InterruptedException {
          saveablePart.doSave(monitor);
        }
      });
    }
    return null;
  }
}

Personally I see many advantages with this version:

• It is actually more readable, as it has very little magic - aprt from the use of the adaption
• It is easy to find all the views that supports the save operation.
• Everything is based on the Java tooling and we have a no magic constants of any sorts
• Refactoring works!
• The activeWhen expression for the handler can simply test whether the activePart adapts to IDoSaveaeble.

What do you think? Is the new magic DI code worth the lost functionality in the Java tooling? Can we invent some new tooling to make up for the lost functionality? 

Javagruppen - the Java user group in Denmark - yearly conference

Javagruppen - the Java user group in Denmark - have had very interesting two-day conference at Hindsgavl Slot on Fyn.

On the first day, I first talked about Eclipse e4 and what you should expect compared with the current 3.x versions. The presentation was well received and there was a very lively discussion about the pros and cons of the different changes that are made in e4. I almost didn't have the time for the look at the code... You can find the slides here.

I then heard Heiko Seeberger talk about Scale and Lift. Scala is cool - very cool - for an old Lisp developer like me. If only I could find the time to integrate this with PDE, then it would be extremely cool. Heiko? Lift? I don't know... I'm not into web design so to me there are just too much magic involved in this...

Then Agata Przybyszewska talked about RSpec and Cucumber for UI and functional testing. I'm not sure I understood all, but then I have never been looking into Ruby or RSpec.

Next day, Jeppe Cramon first talked about how they have generated code from models in a number of projects using TigetMDSD. Very smart and definitely something that scales way better than JET from EMF.

Last I heard Tommy Dejbjerg Pedersen talk about Google Android & Wave. Rather interesting - now I see a reason to get involved in Wave. And Tommy gave me not reasons to regret my

I look forward to next year. If just it wasn't cold outside...

Eclipse Democamp in Copenhagen - Done

Last Thursday we had our edition of the Eclipse Democamp in Copenhagen. With 70+ participants it can only be considered a big success - given the COP15 conference going on right now in Copenhagen, it is not always easy to get around in Copenhagen these days.

We were very lucky that IBM had both room and food to spare for the event - thanks for that.

You can find the slides from the demo camp on eclipse.dk as I get them from the presenters.

I started the camp with a presentation of the ideas behind e4 with focus on the differences you will see as a developer in the future. We will be talking about this a lot more in the future.

Jesper Steen Møller talked about the state-of-the-art of the XPath2, XML Catalog and XSLT tooling in the WTP project. Among other things, Jesper showed a very cool debug session of XSLT.

Bent Agervold Jensen - from ReportSoft - showed some very pretty graphics based on BIRT. I was rather impressed. I will have to look at BIRT again in some near future. Bent showed two real-life examples from the web based om some work they had done for customers - quite impressive.

Mikkel Heisterberg - from Intravision - showed how Lotus Notes in an extension of Eclipse and illustrated how your "plain" Eclipse plug-ins can be used in Lotus Notes with a little extra work. He rightly stated that many of the things we will see in e4, already is present in Lotus Expeditor, but with e4 we will hopefully get something everybody will use...

Jakob Lyng Petersen - from Maconomy - showed some of the work they have done with a commercial application based on Eclipse RCP. Among the more interesting things - for me at least - was their good looking presentation API and the way they have implemented searching just about everywhere. I bet that some of the new e4 technologies would have helped them a loot in their implementation...

Ekkart Kindler - from DTU - showed how the modeling framework in Eclipse can be used together with Petri nets.

Steen Brahe - from Danske Bank - talked about how he has used GMF in his bank. He first outlined the different models that makes up the GMF framework and then showed how they had enhanced their UML editor via a new model that described some of the constraints they have in the domain models. Not that I understood it all, but it was quite obvious that they can save a lot of work in their UML modeling this way.

Jan Schoubo - from Oracle - talked about the LEJLN platform - Linux-Eclipse-Java-LEGO NXT - for absolute beginners. This was by far the most fun presentation where Jan showed how you can program LEGO NXT via Eclipse with a impressive demo where he got a LEGO to to find the colors of small LEGO bricks and showed these on the attached computer.

The next eclipse.dk event will be our general assembly in January.

A dream for future NLS support in the RCP framework

One of the bigger jobs we are involved in right now, is for a Nordic bank with branches in all the Nordic countries. As the application we make must be deployed in all of these countries, we will have to translate all the relevant text from labels, buttons, view titles, perspectives, menus, etc, etc.

We haven't experienced serious problems with the translations themselves... But, then again, this is an area, where we could dream of some better support from the RCP framework. Unfortunately, the support we are looking for, does not seem to be possible in the current framework.

Basically, we want the business side of the bank - who set the original requirements for the application - to provide the translations for the different languages, as they should know better than the individual developers... This in itself is not a problem and can be accomplished via some of the tools from the babel project along with fragments...

But we would also like to allow the business side to make changes in the translations in a very easy way in the running application: when they see a text they don't like, we want them to press a key-combination (ALT-CTRL is used in an older Swing based application) and then click on the item they want to change. This will then drop them into a special editor where the translations for all the supported languages are shown and can be changed. When they have made the proper change, the differences are stored back into a database, from which new fragments are generated automatically...

In order to implement anything like this, we first of all need the NLS key for the text of the item in question as well as the resource name with the translations.

But, currently, all the translations in the registry - e.g for commands and views - are resolved when the plugin.xml files are read into the RCP application... After that no trace can be found of the original NLS keys and thus it is impossible to implement anything like the above.

I have spent some time look at the code that handles the translations and I cannot find a very easy solution without making changes to too many things in the framework. Changes are needed

• in the registry reader
• in IContributionItem code for commands (for menu and toolbar items)
  
• in the current Presentation API implementations (for view names)

plus some new easy to use support for labels, buttons, sections and the like...

So, this is a wish for e4, I guess...