Monday, December 24, 2012

Practices for Eclipse 4 Programming Model

For "Eclipse 4 programming model"[1], I mean the way of how to program with the Eclipse 4.x platform, not the "Eclipse 4 application model"[2] itself, although they definitely have some close relations.

There are several tutorials[3] for the Eclipse 4 techologies. Here, I share some of practices in my last weekend theme plugin project[4] for making your projects more happy in Eclipse 4 platform. They may not be the best practices although I hope them are. So it is welcome to add criticisms and suggestions here:)

The biggest advantages of Eclipse 4 programming model, IMHO, is that:
  • Dependency injection has been introduced;
We have had the Guice[5] from crazy Bob[6] for a long time. We found it is bettter to be adopted for container/framework-provided behaviors. This has been widely used in Java EE 6+ world. And now it comes to Eclipse planet!
  • Many services have been extracted and become standard;
This is a absolute overhaul for Eclipse platform. This makes the consuming to Eclipse platform become much simple and relaxed.

Let me summarize somethings for you:

1. Consume the services by dependency injection way as possible.

For a self-explained instance,
Loading ....
Here, I get the IEclipsePreferences service.

Another way is to use the programatic API call. As you known, the service is verbose to use it correctly. The DI way makes your life easier!
Note, there are some caveats described here[9]. If you have problems in DI, please report it to Eclipse[10] and this helps Eclipse 4 to faster growth.

2. Consume plaform services as possible.

There are many very important services have been abstracted as the services of platform.
Loading ....
In this sinppet, Eclipse will provide four services for us. For example, the event service is powerful for general use. It, in fact, provides a mechanism for hooking/intercepting into the whole platform.
Loading ....
Here, I observe the theme change event for hooking editor-scoped preferences customization.

More detailed services could be seen in [7] and [8].
In my experiences with the event service, there is a bug for @EventTopic injection now, which, I found, has been discussed here[12]. That is, if you work under the Eclipse IDE environment, then the @EventTopic annotated method parameter will be injected with an org.eclipse.equinox.console.command.adapter.CommandProviderAdapter object. My workaround, shown above, is to use the event handler explicitly. But seemly you can use @Optional annotation with combination of @Inject as metioned in that discussion[12], although it is an e4 specific annontation and the semantics of it is not for the workaround obviously. However, finally, I prefer @EventTopic way in that reason shown in the following #3.

3. Injection to your objects in a full managed way is simple.

The truth here is, Eclipse 4 DI does not come into your world automatically. Then, how to link the Eclipse world with your business?
One workable way is to use IEclipseContext to bind you model. IEclipseContext is hierarchical. There are several kinds of IEclipseContext. Do not mess you up with the hierarchy! You can consult one Jonas's tutorial [11] for getting more basic infos. If you construct an RCP, then you may like to use this way.
For IDE managed enirvoment, like an Eclipse plugin, I recommend you to use the model processor extension as your entry point to the Eclipse 4 DI world.
Loading ....

You can extend the extension point org.eclipse.e4.workbench.model to enable it, like this:
Loading ....
It extension point is for the application model, in fact, as the document. But I think, it is simple and nice to use it with you business objects before we have a general DI hooking point if you want to forget the programatic injection.
Do not assume that a platform UI side services or objects could be injected and used here. For instance, you can not inject the IThemeEngine service in the model processor(IThemeEngine service is prepared after the processing of model). I guess it is intentional. There are still two ways for  this:
  • use the EventHandler to watch the UI side topic exactly.
  • use application model to bridge to your UI related POJOs. You can inject kinds of services here. This is just the way the e4 bundles selfs do their works.

4. Eclipse 4 Tooling is your friend.

It is not easy to consume the Eclipse 4 technologies now. There is a tooling project[13] come to help you: it includes the CSS Spy, CSS editor, application model editor and live editor.
For example, there are two ways to contribute/extend the application model:
  • one is to change the model pragramatically(this is my favorite way).
  • another is to use e4xmi model file. For this way, an application model editor is expected to have. Lars has provide the step-by-step guide[16].
The emf live editor is a little out-of-date in the weekend. I think it will be fixed soon. If you meet error log shows that one shell can not be found and injected. You can pull the source from[13] and annonated IServiceConstants.ACTIVE_SELECTION) to it. This is an intentional change documented in the[9].

As my evaluation to the Eclipse 4.3 nightly, it is good to consume now!
And we have got famous perfermance bugs fixed[14].
And I find the quick fixing for plugins is more intellisense[15].
And GTK3 is out for linux fans' testing(But it has an obvious bug now. So, I suggest you wait one or two milestone to test)[15].

As a plaform, Eclipse 4 has many many advantages to IDEA 12, IMHO. Do not hesitate to migrate to Eclipse 4! Help us to evolve!


1 comment:

nazia shah said...

great and nice sharing jin mingjian about programing model MODELS AND MODEL RELATIONSHIPS have the key role in programing model.
Mobile news