Welcome Tony McCrary as a new eclipse.platform.ui Committer

I would like to welcome Tony McCrary as platform.ui committer.

Tony is the amazing guy behind the new Eclipse icons which look way better on a dark background. He has drawn these svg icons and created a Maven renderer to convert them into png files. I have not counted these icons recently, but the last time I looked he created more than 1500 icons. And Tony stayed in for several years, even though he got little thanks from the projects he contributed the icons to. Certain projects which received hundreds of icons complained about errors in 1-2 icons, instead of saying thank you.

Thanks Tony, for having such a thick skin.

Tony is also a kick-ass developer and maintain his closed source SWT port based on Open GL. Scary stuff if you ask me.

Welcome Tony!

Posted in Eclipse, Lars Vogel | 1 Comment

Welcome Jonas Helming as a new eclipse.platform.ui Committer

I would like to welcome Jonas Helming as platform.ui committer.

Jonas was the driving force behind the migration of the e4 tools to platform.ui and uses his awesome Eclipse modeling and programming skills to improve the e4 tools and the platform. Jonas is also helping actively with incoming Gerrit reviews.

Welcome Jonas!

Posted in Eclipse, Lars Vogel | Tagged | Leave a comment

Extracting Git statistics from Eclipse Platform.UI in August

I found the nice Git repo for the gitdm tool to do Git commit statistics. In addition the mr tool allows to extract logs from multiple repositories.

Combining both let me extract the Git statics of platform UI relatively easy. Here is the command for last August:

mr log -p -M --after="2015-8-1" --before="2015-9-1" | ../gitdm/gitdm -b ../gitdm/

Processed 68 csets from 16 developers
15 employers found
A total of 8722 lines added, 10823 removed (delta -2101)

Developers with the most changesets
Lars Vogel 25 (36.8%)
Simon Scholz 6 (8.8%)
Brian de Alwis 6 (8.8%)
Dirk Fauth 5 (7.4%)
Markus Keller 4 (5.9%)
Stefan Xenos 4 (5.9%)
Matthias Becker 3 (4.4%)
Alexander Kurtakov 3 (4.4%)
Dani Megert 3 (4.4%)
Patrik Suzzi 2 (2.9%)
Sopot Cela 2 (2.9%)
Dariusz Stefanowicz 1 (1.5%)
Christian Radspieler 1 (1.5%)
Christian Georgi 1 (1.5%)
Daniel Haftstein 1 (1.5%)
Jonas Helming 1 (1.5%)

Developers with the most changed lines
Lars Vogel 4295 (34.9%)
Stefan Xenos 3266 (26.6%)
Markus Keller 1662 (13.5%)
Dirk Fauth 1107 (9.0%)
Simon Scholz 714 (5.8%)
Brian de Alwis 439 (3.6%)
Jonas Helming 389 (3.2%)
Alexander Kurtakov 228 (1.9%)
Matthias Becker 139 (1.1%)
Patrik Suzzi 37 (0.3%)
Sopot Cela 8 (0.1%)
Christian Georgi 6 (0.0%)
Dani Megert 5 (0.0%)
Daniel Haftstein 2 (0.0%)
Dariusz Stefanowicz 1 (0.0%)
Christian Radspieler 1 (0.0%)

Developers with the most lines removed
Lars Vogel 2382 (22.0%)
Dirk Fauth 352 (3.3%)
Simon Scholz 236 (2.2%)
Markus Keller 159 (1.5%)
Alexander Kurtakov 80 (0.7%)
Daniel Haftstein 1 (0.0%)

I like these statistics, as they are much more detailed compared to Eclipse Platform UI.

Posted in Eclipse, Lars Vogel | 2 Comments

Eclipse Activator startup sins – Tracing the startup time

Inspired by the Eclipse start optimisation by Alex Blewitt post, I traced my environment and reworked our Eclipse Tracing tutorial section to enable others to do the same.

On my machine starting the Eclipse IDE (with only the SDK, XML editor and Git installed) takes 4317 ms. Looking at the “bad” guys it looks like Eclipse could start approx. 18 % faster if PDE and JDT would not activating themself. If opened Bug for JDT core and Bug for PDE.

If case you experience long startup time in your setup, I recommend to turn on the tracing option and if you see a slow starting component, to open a bug report or code correction for it. In most cases removing the activator (and moving its logic to another place which is lazy initialized) should speed up the start process.

293 org.eclipse.pde.ui_3.8.300.v20150911-1533
259 org.eclipse.pde.core_3.10.200.v20150911-1533
199 org.eclipse.jdt.core_3.12.0.v20150913-1717
132 org.eclipse.ui.trace_1.0.300.v20150911-1533
127 org.eclipse.core.runtime_3.12.0.v20150912-0621
96 org.eclipse.ltk.core.refactoring_3.7.0.v20150811-0952
88 org.eclipse.core.resources_3.11.0.v20150909-2051
68 org.eclipse.ui.workbench_3.107.100.v20150915-1646
53 org.eclipse.equinox.simpleconfigurator_1.1.100.v20150907-2149
52 org.eclipse.jdt.ui_3.12.0.v20150914-0905
46 org.eclipse.core.jobs_3.8.0.v20150911-1658
44 org.eclipse.osgi_3.10.200.v20150831-0856
41 org.eclipse.equinox.console_1.1.100.v20141023-1406
36 org.eclipse.e4.ui.model.workbench_1.1.100.v20150813-1519
34 org.eclipse.equinox.p2.ui.sdk.scheduler_1.2.100.v20150907-2149
34 org.eclipse.emf.common_2.11.0.v20150805-0624
31 org.eclipse.update.configurator_3.3.300.v20140518-1928
27 org.eclipse.jdt.launching_3.8.0.v20150819-1826
24 org.eclipse.equinox.registry_3.6.100.v20150715-1528
24 org.eclipse.equinox.ds_1.4.300.v20150423-1356
24 org.eclipse.debug.ui_3.11.100.v20150911-0904
22 org.eclipse.equinox.app_1.3.400.v20150715-1528
20 org.eclipse.core.net_1.2.300.v20141118-1725
19 org.eclipse.equinox.preferences_3.6.0.v20150809-1729
16 org.apache.felix.gogo.runtime_0.10.0.v201209301036
14 org.eclipse.emf.ecore_2.12.0.v20150805-0624
12 org.eclipse.equinox.p2.reconciler.dropins_1.1.300.v20150907-2149
12 org.eclipse.debug.core_3.10.0.v20150911-0751
10 org.eclipse.team.core_3.7.100.v20150203-1452
7 org.eclipse.equinox.common_3.8.0.v20150911-2106
7 org.apache.felix.gogo.shell_0.10.0.v201212101605
5 org.eclipse.equinox.util_1.0.500.v20130404-1337
5 org.eclipse.equinox.p2.engine_2.4.0.v20150907-2149
5 org.eclipse.equinox.p2.core_2.4.0.v20150527-1706
5 org.eclipse.e4.ui.workbench_1.3.0.v20150821-1750
5 org.apache.felix.gogo.command_0.10.0.v201209301215
2 org.eclipse.ui.ide_3.12.0.v20150915-2041
2 org.eclipse.ui_3.107.0.v20150914-1638
2 org.eclipse.ltk.ui.refactoring_3.8.0.v20150713-1605
1 org.eclipse.ui.workbench.texteditor_3.9.200.v20150901-0449
1 org.eclipse.ui.views.log_1.0.600.v20150911-1533
1 org.eclipse.ui.monitoring_1.0.0.v20150512-1436
1 org.eclipse.ui.externaltools_3.3.0.v20150903-1021
1 org.eclipse.ui.editors_3.9.100.v20150901-0449
1 org.eclipse.pde.launching_3.6.400.v20150911-1533
1 org.eclipse.jdt.core.manipulation_1.7.0.v20150713-1605
1 org.eclipse.help_3.6.0.v20130326-1254
1 org.eclipse.equinox.security_1.2.200.v20150715-1528
1 org.eclipse.equinox.p2.metadata_2.3.0.v20150907-2149
1 org.eclipse.equinox.p2.garbagecollector_1.0.200.v20150907-2149
1 org.eclipse.equinox.p2.directorywatcher_1.1.100.v20150423-1455
1 org.eclipse.emf.ecore.xmi_2.12.0.v20150805-0624
1 org.eclipse.e4.ui.workbench.swt_0.13.0.v20150915-1214
1 org.eclipse.e4.ui.workbench.renderers.swt_0.13.0.v20150908-1041
1 org.eclipse.e4.ui.css.swt_0.12.0.v20150824-1436
1 org.eclipse.e4.core.services_2.0.0.v20150827-1906
1 org.eclipse.core.filesystem_1.6.0.v20150824-0358
1 org.eclipse.core.filebuffers_3.5.500.v20140723-1040
1 org.eclipse.core.databinding.observable_1.6.0.v20150731-2248

Posted in Eclipse, Lars Vogel | 3 Comments

Finding the correct Eclipse update site for the Eclipse development build

If you are using the latest Eclipse development build and looking for the correct update site, you can check the following Eclipse Project Update Sites wiki.

Since a little while Eclipse Platform also offers stable links for its update sites which are also listed on this wiki, see Bug.

Posted in Eclipse, Lars Vogel | Leave a comment

Eclipse Neon (Eclipse 4.6) will require a Java 8 runtime

I’m personally happy that the next Eclipse release will require Java 1.8 to run. See official email to the cross mailing list for the public announcement of this.

Several Eclipse projects like m2e and Jetty have already moved to Java 8. This moves allows us in the Eclipse platform to use the improved Java 8 API to modernize and optimize our code base and will hopefully make the Eclipse project even more interesting for potential Eclipse contributors.

After all, who wants to work in his unpaid time with an outdated Java version?

Posted in Eclipse, Lars Vogel | 5 Comments

Contributing the the Eclipse platform UI project in 4 simple steps

Some people claim it is relatively hard to contribute code to an Eclipse platform project (without Oomph). But even without additional tooling is actually very easy to setup the necessary configuration to contribute to Eclipse platform UI.

Here are the necessary steps:

Create and configure an Eclipse user
Clone the Eclipse platform UI repo
Configure your Eclipse workspace
Make a change and publish it

If I put these instructions on A4 paper, they take 5 pages, including lots of screenshots.

Based on our experience during Eclipse Hamburg Hackathons, this setup usually takes less then 10 minutes for an unexperienced users, plus the time you need to clone the Git repo.

This setup used to be more complex in the past but we constantly work on making it simpler. Also a big thanks to the Eclipse Git tooling project which makes the configuration as seamless as possible.

Posted in Eclipse, Lars Vogel | Leave a comment

Honored to join the Eclipse Architecture Council

I recently been elected to join the Eclipse Architecture Council. The Eclipse Architecture Council serves the community by identifying and tackling any issues that hinder Eclipse’s continued technological success and innovation, widespread adoption, and future growth.

Looking forward to help here.

Posted in Eclipse, Lars Vogel | Comments Off on Honored to join the Eclipse Architecture Council

Generic Eclipse 3.x views, editors and handlers with DI – by René Brandstetter

In this blog entry I will show you three independent features provided by Eclipse and OSGi which can work together to create views, editors or handlers via the Eclipse ExtensionRegistry but still use the dependency mechanism of Eclipse 4.

Supersede the ExtensionRegistry creation process of an object (an almost forgotten hidden feature)

The Eclipse ExtensionRegistry allows you as an extension provider to not only contribute your custom implementation but to also be part of the “creation & initialization” process. So whenever an ExtensionPoint needs to create an instance of a specific class (e.g.: <view name="View" class="com.example.legacy3x.View" id="com.example.legacy3x.view"/>) it uses the method IConfigurationElement#createExecutableExtension(String attributeName). This method is responsible for creating an instance of the class via the bundle which provides the extension and has the following workflow:

  1. Retrieve the class name from the extension
  2. Create an instance of the class
  3. If the instance implements IExecutableExtension, call its setInitializationData() method with the initialization data from the provided extension (see next paragraph for details on how this is done)
  4. Now check if the instance implements IExecutableExtensionFactory:
    • If so, return the value object retrieved from its create() method
    • If it doesn’t implement this interface, it just returns the already created instance from step no. 2

With these two interfaces you have the following possibilities:

  • neither implement IExecutableExtension nor IExecutableExtensionFactory – a new instance of the named class is returned (this is more or less the most used scenario)
  • only implement IExecutableExtension – an instance of the named class is created and its setInitializationData() method is called (can be seen as an @PostConstruct)
  • only implement IExecutableExtensionFactory – an instance of the mentioned IExecutableExtensionFactory is created but the object created via IExecutableExtensionFactory#create() is returned and not the IExecutableExtensionFactory instance (as the name already implies that it is the Factory-Pattern)
  • both, IExecutableExtension and IExecutableExtensionFactory, are implemented – which creates an instance of the mentioned IExecutableExtensionFactory, configures it via IExecutableExtension#setInitializationData() and afterwards returns the object created via IExecutableExtensionFactory#create() (can be seen as a configurable factory)

Now that we know how the creation process can be influenced lets take a look at how we can specify the initialization data.

IExecutableExtension defines the method “void setInitializationData(IConfigurationElement config, String propertyName, Object data) throws CoreException;” which gets:

  • config – the contributed extension on which the IConfigurationElement#createExecutableExtension(String attributeName) was called
  • propertyName – the name of the attribute which causes the create (=attributeName of the method IConfigurationElement#createExecutableExtension(String attributeName))
  • data – the additional initialization data you are able to configure

The additional configured initialization data is an object and can have 2 different types depending on how the initialization data is specified.

  • data instanceof String: the initialization data was directly specified in the attribute by separating the class name and the initialization data with a colon (e.g.: class="com.example.legacy3x.View:hereYouCanSpecifyAllInitializationDataAsAString"; data would be "hereYouCanSpecifyAllInitializationDataAsAString")
  • data instanceof Map: the initialization data was defined as key/value pairs in a separate tag named exactly the same as the attribute name (e.g.:
    <view name="View"
      <class class="com.example.legacy3x.View">
        <parameter name="key 1" value="value 1" />
        <parameter name="key 2" value="value 2" />

    ). For the transfer of the attribute name to the tag name there is no UI and you have to do this in the XML source directly. Just remove the attribute, create a tag named like the attribute (in our example this is “class“), and provide an attribute named “class” on it which holds the full qualified name of the real class. All code<parameter> sub-tags of your tag will become the key/value pairs of the provided Map.


Get an appropriate IEclipseContext

In the Eclipse ExtensionRegistry or in a legacy 3.x Eclipse which uses the “org.eclipse.e4.tools.compat” bundle you probably won’t have an E4-ApplicationModel object to retrieve an IEclipseContext from it. So how can you retrieve it in these situations?

Keep in mind that the IEclipseContext is organized in a hierarchical structure which reflects more or less the structure of the UI.


This also represents more or less the structure of an Eclipse 3.x application.


A closer look at the IWorkbench* – classes above shows that all of them extend the IServiceLocator interface and so we have the possibility to call the IServiceLocator#getService(Class) method on them. The good news about this method is that it will return the IEclipseContext instance associated with the IWorkbench*-object whenever you invoke it with IEclipseContext.class as the argument. This means retrieving the IEclipseContext of the currently active window is done by the following method call:


or retrieving it from the application it would require:


Load classes from specific bundles

In OSGi it’s a bad habit to load classes yourself but sometimes (hopefully in really rare cases) it happens that you want to provide a functionality which has to load a specific class from another bundle that your code isn’t aware of (means it doesn’t know it and so can’t define an Import-Package entry in the MANIFEST.MF). But as Eclipse 4.x shows there must be a way of doing this. To load a class from a bundle only known at runtime your code has to know the following:

  1. the symbolic name of the bundle which holds the class
  2. the full qualified name of the class to load
  3. this would be nice to have but is sadly always ignored because of easier handling: the version or version range of the bundle which holds the class

How can this information be put into a String format? The best and easiest way is to put it in an URI which has a standardized format and this is how it’s done in e4 with the “bundleclass://“-references. For example “bundleclass://com.example.legacy3x.view/com.example.legacy3x.View“, the host-part of the URI would be the bundle symbolic name (=com.example.legacy3x.view) and the full qualified name of the class is held in the first path element (=com.example.legacy3x.View).

Now that we know how to present this information we can ask the OSGi environment to give us the required bundle and with the help of this bundle we can then load the class. To retrieve the bundle form a pure OSGi environment you have 3 possibilities depending on the OSGi version you’re using:

  1. OSGi Version < r4v43 where PackageAdmin isn’t deprecated: retrieve the PackageAdmin service from the OSGi service registry and call org.osgi.service.packageadmin.PackageAdmin.getBundles(String symbolicName, String versionRange)
  2. OSGi Version > r4v43 and < r6 or if you want to be OSGi version independent: use a BundleTracker implementation similar to the one in org.eclipse.e4.ui.internal.workbench.BundleFinder
  3. OSGi Version >= r6: here a new method exists FrameworkWiring#findProviders(Requirement) which can be used to query the requirement/capabilities framework of OSGi

In the following example, I will show you only the latest way of retrieving a bundle from OSGi via FrameworkWiring#findProviders(Requirement), because the other 2 options are self-explanatory.

// ... unimportant imports and null checks omitted for simplicity ...
import org.osgi.framework.Constants;
import org.osgi.framework.namespace.IdentityNamespace;
import org.osgi.framework.wiring.BundleCapability;
import org.osgi.framework.wiring.FrameworkWiring;
import org.osgi.resource.Namespace;
import org.osgi.resource.Requirement;
import org.osgi.resource.Resource;
// ... other imports ...
static <T> Class<T> loadClass(final String bundleName, String className) throws ClassNotFoundException {
      // retrieve the FrameworkWiring: according to the OSGi specification only the system bundle can be adapted to this
      FrameworkWiring frameworkWiring = context.getBundle(Constants.SYSTEM_BUNDLE_ID).adapt(FrameworkWiring.class);
      // build FrameworkWiring search criteria to find a specific bundle with a given name
      Requirement requirement = new Requirement() {
            public Resource getResource() {
              return null// requirement is synthesized hence null
            public String getNamespace() {
              return IdentityNamespace.IDENTITY_NAMESPACE;
            public Map<String, String> getDirectives() {
              return Collections.<String, String> singletonMap(Namespace.REQUIREMENT_FILTER_DIRECTIVE, "(" + IdentityNamespace.IDENTITY_NAMESPACE + "=" + bundleName + ")");
            public Map<String, Object> getAttributes() {
              return Collections.<String, Object>emptyMap();
      Collection<BundleCapability> capabilities = frameworkWiring.findProviders(requirement);  // query the OSGi environment for a bundle with the given symbolic name
      // we didn't specify a version for simplicity so we take the bundle with the highest version
      Bundle bundle = null;
      for( BundleCapability capability : capabilities ){
        Bundle b = capability.getRevision().getBundle();
        if( bundle == null || b.getVersion().compareTo(bundle.getVersion()) > 0 ){
          bundle = b;
      // in case the bundle exists, the bundle with the given symbolic name and the highest version is held in the "bundle" variable
      return (Class<T>)bundle.loadClass(className);

The for-loop over the retrieved capabilities only exists because in the example bundle versions are not taken into account. If you enrich your URI with a version (e.g.: bundleclass://com.example.legacy3x.view/com.example.legacy3x.View?v=1.0.0) you could enrich the filter provided in the directives variable with this information too. For this the filter should look like: "(&(" + IdentityNamespace.IDENTITY_NAMESPACE + "=" + bundleName + ")(" + IdentityNamespace.CAPABILITY_VERSION_ATTRIBUTE + "=" + bundleVersion + "))"

Hint: If you stick to Eclipse as the OSGi environment and use the org.eclipse.core.runtime bundle, you could also use the static methods getBundle(String symbolicName) or getBundles(String symbolicName, String version) of org.eclipse.core.runtime.Platform.

Plumbing everything together for a generic DIViewPart

Now that we know how to

  • supersede the ExtensionRegistry class creation mechanism,
  • retrieve an IEclipseContext from different Workbench elements and
  • load a class from another “unknown” bundle

we can use this information to extend the DIViewPart, DIEditorPart and DIHandler classes of the org.eclipse.e4.tools.compat bundle to be more generic than they are now.

For this you have to create a simple bundle which uses the above mentioned hints to:

  • provide a configurable IExecutableExtensionFactory
    • Example: public class DIFactoryForE3Elements implements IExecutableExtension, IExecutableExtensionFactory{ … }
    • Hint: The package of this factory should also be exported so it can be used in other bundles.
  • in its setInitializationData() method retrieve the required information to load the POJO class
    • Example: the data object could be a bundleclass://-URI
      URI bundleClass = new URI((String)data);
      String bundleName = bundleClass.getHost();
      String className = bundleClass.getPath();
  • in its create() method instantiate, depending on the used extension point (handler, view or editor), the appropriate DI*-class of the org.eclipse.e4.tools.compat bundle
    • Example: return new DIHandler<>(pojoClass);
    • Hint: The DI*-classes internally use the shown techniques to retrieve the appropriate IEclipseContext.

After you’ve created this bundle, you can use the created IExecutableExtensionFactory in all bundles which want to provide an “e4-like-POJO-based” view, editor or handler. To do so, you just have to:

  • write a POJO class with the appropriate e4-annotations (@Inject, @PostConstruct, …)
  • import the package which holds your IExecutableExtensionFactory implementation
  • create the appropriate extension entry and use your IExecutableExtensionFactory
    • Example:
      <extension point="org.eclipse.ui.views">
        <view allowMultiple="true"
           name="DI enabled View"

Final Words

If my explanations are a little bit confusing or if you just want to see it in action, take a look at the following GitHub links:


Many thanks to:

Lars Vogel for once again motivating me to write this blog entry


Tom Schindl, the mastermind behind the “how to make the DI*-classes generic “ idea, for allowing me to present it here.

And as usual, sorry for being too chatty and for all the typos and errors: comment on them or keep them ;-).

Posted in Eclipse, Lars Vogel | Tagged , , , , , | Comments Off on Generic Eclipse 3.x views, editors and handlers with DI – by René Brandstetter

Where are the vogella example projects at Github?

On a regular basis I get the question where people can find the example code of our tutorials. There are on Github but Github is big, so we created this vogella Source code page to make it easier to find the correct repository.

Lets the Pull Request be coming. :-)

Posted in Android, Eclipse, vogella, Web | Comments Off on Where are the vogella example projects at Github?