The Eclipse UML2 project provides models and diagram editors for creating and editing UML models in Eclipse. The problem is that these models are not tied to code in any way, and in particular, if you want to visualize existing Java code in class diagrams, you have no option but to create the class diagram manually.

A former alternative, the Omondo EclipseUML Free Edition is not available for Eclipse 3.4 and other free tools (I have tried a lot) don’t work well, or not at alll, either.

Well, with the exception of the TOPCASED Java2UML Plugin, which is not easy to find and has not been updated for over 2 years now. However, I tried it with Eclipse Ganymede and it still works quite well in the current version as it is able to generate a UML2 model from Java code from which then a class diagram can be initialized and edited.

To install it, simply download the org.topcased.java.reverse_0.2.0.jar plugin and put it into your favourite dropin location (e.g. ${ECLIPSE_HOME}/eclipse/dropins/plugins). Then start Eclipse and make sure that all UML2 components are installed. Right-click on a Java Package in the Package Explorer and you should see the menu item UML from Java just above the Run as/Debug as submenu items. When selected, a wizard opens which lets you specify the target .uml file, which will be generated.

After the generation process you can simply choose Initialze Class Diagram from the .uml file’s context menu to visualize you classes. Note that you have to hide a lot of external classes and other information you don’t need, but doing this is much more efficient than creating the whole diagram by hand.

Following Robin’s comment on my earlier post I found the new API (Extension point description of org.eclipse.ui.menus) which unifies all command contributions to Eclipse menus, views, objects, toolbars etc.

With this example it requires a lot less code to add an action (well, the new API uses commands) which is visible or enabled dynamically based on an object property. However, at the same time, we have to do quite a bit more extension configurations:

Instead of a single declaration of an org.eclipse.ui.popupMenus extension, we need all this:

• A command (which only declares the abstract concept of the semantic behavior):

<extension point="org.eclipse.ui.commands">
  <command
        description="Do something with a model element"
        id="my.command.id"
        name="Do Something">
  </command>
</extension>

• A handler (which implements the behavior – the equivalent to what used to be the ActionDelegate):

<extension point="org.eclipse.ui.handlers">
  <handler
        class="my.contribution.MyCommandHandler"
        commandId="my.command.id">
  </handler>
</extension>

• A contribution (which connects the command to a menu or action bar):

<extension point="org.eclipse.ui.menus">
  <menuContribution locationURI="popup:org.eclipse.ui.popup.any?after=additions">
     <command
           commandId="my.command.id"
           style="push">
        <visibleWhen>
            <with variable="activeMenuSelection">
               <iterate>
                  <instanceof
                     value="my.model.MyObject">
                  </instanceof>
               </iterate>
           </with>
        </visibleWhen>
     </command>
  </menuContribution>
</extension>

Note that the locationURI offers a lot of options – the case above simulates the objectContribution behavior, as the command is added to any popup menu and the visibility is determined by the selected objects’ types.

Instead of behaving like an objectContribution, we can simply change the locationURI to menu:<view-or-menu-id> or to toolbar:<view-or-toolbar-id> in order to contribute the command to a view’s menu or toolbar, respectively. Naturally, in these cases, we don’t need the visibleWhen constraint.

The command handler implemtation is a lot simpler than the action delegate handler, as the abstract class org.eclipse.core.commands.AbstractHandler does all the extra work (listener implementation etc.) for us.

The only method, we have to implement ourselves is execute():

package my.contribution;

import org.eclipse.core.commands.AbstractHandler;
import org.eclipse.core.commands.ExecutionEvent;
import org.eclipse.core.commands.ExecutionException;
import org.eclipse.jface.viewers.IStructuredSelection;
import org.eclipse.ui.handlers.HandlerUtil;

public class MyCommandHandler extends AbstractHandler {

	@Override
	public Object execute(ExecutionEvent event) throws ExecutionException {

		IStructuredSelection selection = (IStructuredSelection) HandlerUtil.getCurrentSelectionChecked(event);
		MyObject object = (MyObject) selection.getFirstElement();

		// do something with MyObject
	}

}

Again, until here, we only implemented a command which is enabled always. Now, if we want to enable the command only, if the selected model element fulfills a certain constraint, in the old API we needed an adapter.

In the new API, the adapter is made implicit using the concept of a PropertyTester. A PropertyTester can be used to add custom testable properties to arbitrary classes. For our example, the declaration and looks like this:

<extension point="org.eclipse.core.expressions.propertyTesters">
      <propertyTester
            class="my.package.MyObjectPropertyTester"
            id="my.proptester.id"
            namespace="my.property.namespace"
            properties="type"
            type="my.model.MyObject">
      </propertyTester>
</extension>

and the implementation is as follows:

package de.feuh.st.requipse.project;

import org.eclipse.core.expressions.PropertyTester;

public class ArtifactPropertyTester extends PropertyTester {

	@Override
	public boolean test(Object receiver, String property, Object[] args,
			Object expectedValue) {

		MyObject obj = (MyObject)receiver;
		if(property.equals("type")) {
			return expectedValue.equals(obj.getType());
		}
		else {
			return false;
		}
	}
}

This way, we have defined a property called type in the namespace my.property.namespace which applies to objects which are instance of my.model.MyObject. The implementation then compares the value of the object’s getType() method to a given expected value and returns the result.

As a final step, we have to use the PropertyTester in our handler declaration. We enhance the handler as follows:

<extension point="org.eclipse.ui.handlers">
  <handler
        class="my.contribution.MyCommandHandler"
        commandId="my.command.id">
     <enabledWhen>
        <with variable="selection">
           <iterate
                 ifEmpty="false"
                 operator="and">
              <test
                    property="my.property.namespace.type"
                    value="FOO">
              </test>
           </iterate>
        </with>
     </enabledWhen>
  </handler>
</extension>

This enables the command only if all of the selected objects return “FOO” for getType().

Further Reading:

• Eclipse Platform Guide for Workbench Commands
• Blog Entry describing the migration from the old to the new API
• Using Commands and Menu Contributions (Slides from EclipseCon 2008)

This is just a short notice for an EMF code generator feature which is mostly unknown and not really documented (well, it will be in the EMF 2nd Edition book, but this won’t be out until December or later).

To add a custom body (replacing the usual throw new UnsupportedOperationException body generated by default), follow this step-by-step howto.

One of the first Hello World examples when dealing with contributions to Eclipse extension points is adding an objectContribution or a viewerContribution to a popup menu. However, if one wants to add a more flexible contribution which is hided or disabled in certain circumstances, documentation gets rare.

This article describes how to implement these advanced featues by example. Let’s assume we have an EMF model of objects MyObject which implement a property called type. EMF can generate item and label providers for tree editors. Let’s assume we have implemented such an editor and we want to contribute an action which is only visible for a particular type value.

Update: This article uses the old API of contributing actions to views’ and objects’ popup menus. There is a new API which is described in another post.

As a first step we implement the corresponding ActionDelegate and register it as an object contribution: This

<extension point="org.eclipse.ui.popupMenus">
   <objectContribution
            adaptable="false"
            id="my.contribution.id"
            objectClass="my.model.MyObject">
         <action
               class="my.contribution.MyActionDelegate"
               enablesFor="1"
               id="my.contribution.action.id"
               label="Do something only with type FOO"
               menubarPath="additions">
         </action>
  </objectContribution>
</extension>

This way, however, the contribution is visible and enabled always. We want to hide (or disable) it, if selectedObject.getType() is not equal to "FOO". The popupMenus extension point lets us specify visibility and enablement constraints and we can use the objectState element to query the object’s state. However, this is not as simple as it sounds, because objectState can only query objects which implement the IActionFilter interface and since MyObject is a EMF generated class, we cannot simply implement the interface.

But what we can do, is adapt. So we write an adapter and its factory:

public class MyObjectToActionFilterAdapter implements IActionFilter {

	private static final Object MYOBJECT_TYPE = "objectType";

	private static ArtifactToActionFilterAdapter INSTANCE = new ArtifactToActionFilterAdapter();

	private ArtifactToActionFilterAdapter() {}

	@Override
	public boolean testAttribute(Object target, String name, String value) {
		if (target instanceof MyObject) {
			MyObject obj = (MyObject) target;

			if(MYOBJECT_TYPE.equals(name)) {
				return value.equals(obj.getType());
			}
		}

		return false;
	}

	public static ArtifactToActionFilterAdapter getInstance() {
		return INSTANCE;
	}
}

public class MyActionFilterAdapterFactory implements IAdapterFactory {

	@SuppressWarnings("unchecked")
	@Override
	public Object getAdapter(Object adaptableObject, Class adapterType) {
		if(adapterType == IActionFilter.class)
			return MyObjectToActionFilterAdapter.getInstance();
		return null;
	}

	@SuppressWarnings("unchecked")
	@Override
	public Class[] getAdapterList() {
		return new Class[] {IActionFilter.class};
	}
}

Note that the adapter can be implemented as a singleton because the testAttribute implementation is called with the object to be tested.

Now we have to register our adapter factory using:

<extension point="org.eclipse.core.runtime.adapters">
      <factory
            adaptableType="my.model.MyObject"
            class="my.contribution.MyActionFilterAdapterFactory">
         <adapter
               type="org.eclipse.ui.IActionFilter">
         </adapter>
      </factory>
</extension>

and after that we are ready to declare our constraints:

<extension point="org.eclipse.ui.popupMenus">
   <objectContribution
            adaptable="false"
            id="my.contribution.id"
            objectClass="my.model.MyObject">
         <action
               class="my.contribution.MyActionDelegate"
               enablesFor="1"
               id="my.contribution.action.id"
               label="Do something only with type FOO"
               menubarPath="additions">
         </action>
         <visibility>
               <objectState
                     name="objectType"
                     value="FOO">
               </objectState>
         </visibility>
  </objectContribution>
</extension>

This causes the action to appear only if the property type of MyObject has the value FOO.

Instead of hiding the action, we can also disable it using the element <enablement> istead of <visibility>. In this case, however, the <enablement> constraint has to be a child of the <action> element instead of a sibling.

Say, you want to implement a quick and flexible automation enhancement to one of your eclipse RCP plugins – for example, because you are writing some sort of business application in which you always have to create a few standard structures manually in order to play with it and test it.

Here’s how you can do it the groovy way:

• create a new plugin project that depends on all plug-ins you want the automation script to be able to access.
• download groovy-all-x.y.z.jar from the Groovy homepage and put it into your plug-in’s runtime classpath.
• create an objectContribution like this:

      <objectContribution
            adaptable="false"
            id="myproject.groovyRunner"
            nameFilter="*.groovy"
            objectClass="org.eclipse.core.resources.IFile">
         <action
               class="myproject.automate.RunGroovyAction"
               enablesFor="1"
               id="myproject.groovyRunnerAction"
               label="Execute as Automation Script"
               menubarPath="additions">
         </action>
      </objectContribution>

• implement the action like this

package myproject.automate;

import java.io.PrintWriter;
import java.io.StringWriter;

import groovy.lang.GroovyClassLoader;

import org.codehaus.groovy.control.ErrorCollector;
import org.codehaus.groovy.control.MultipleCompilationErrorsException;
import org.codehaus.groovy.control.messages.Message;
import org.eclipse.core.resources.IFile;
import org.eclipse.core.runtime.Assert;
import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.Status;
import org.eclipse.jface.action.IAction;
import org.eclipse.jface.dialogs.ErrorDialog;
import org.eclipse.jface.viewers.ISelection;
import org.eclipse.jface.viewers.IStructuredSelection;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.ui.IObjectActionDelegate;
import org.eclipse.ui.IWorkbenchPart;

import myproject.MyPlugin;

public class RunGroovyAction implements IObjectActionDelegate {

	/** store the parent shell */
	private Shell shell = null;

	/** store the selected file */
	private IFile file;

	@Override
	public void setActivePart(IAction action, IWorkbenchPart targetPart) {
		shell = targetPart.getSite().getShell();
	}

	@Override
	public void selectionChanged(IAction action, ISelection selection) {
		file = (IFile) ((IStructuredSelection)selection).getFirstElement();
	}

	@Override
	public void run(IAction action) {
		Assert.isNotNull(shell);
		Assert.isNotNull(file);

		try {
			/* initialize the GroovyClassLoader with the Eclipse class loader */
			GroovyClassLoader loader = new GroovyClassLoader(getClass().getClassLoader());

			/* parse the groovy file */
			Class<?> parsed = loader.parseClass(file.getContents());

			/* cast it to runnable (or whatever you like to implement */
			Class<? extends Runnable> clazz = parsed.asSubclass(Runnable.class);

			/* instantiate and rum */
			Runnable r = clazz.newInstance();
			r.run();
		}
		catch(MultipleCompilationErrorsException e) {
			/* report compilation errors in an error dialog */

			StringWriter messages = new StringWriter();
			PrintWriter printWriter = new PrintWriter(messages);

			ErrorCollector ec = e.getErrorCollector();
			if(ec.hasErrors()) {
				for(Object o : ec.getErrors()) {
					((Message) o).write(printWriter);
					printWriter.append('\n');
				}
			}

			Status status = new Status(IStatus.ERROR, MyPlugin.PLUGIN_ID,
					messages.toString(), e);

			ErrorDialog.openError(shell, "Compilation errors", messages.toString(), status);
		} catch(Exception e) {
			/* report all other errors here */

			Status status = new Status(IStatus.ERROR, MyPlugin.PLUGIN_ID,
					"Execution error", e.getCause() == null ? e : e
							.getCause());

			ErrorDialog.openError(shell, "Error", "Execution error", status);
		}
	}
}

Now you can run your Eclipse application, create a .groovy class (implementing Runnable in the case above) in a file and run it from within your runtime workspace.

Happy scripting …

I manage all of my references in a single big BibTeX database (BTW, I do this using JabRef – a really nice Java tool to manage BibTeX files). Now if I am writing a paper, I first use the big file just because it is easy and I have everything in one place.

But when the paper is finished, I want to throw away all unused references, to optimize the bibtex file and to edit all of the references used in one place (like abbreviating booktitles, because my paper is too long …). So how to extract all entries needed and throwing away the rest?

To do this, I found this perl script from Michael Zhang which does exactly what I need. Thanks Mike! Nice work!

I like Eclipse. It is a really useful tool. It does a lot of magic behind the scenes and after a bit of getting familiar with its API you are able to write quite powerful plug-ins.

The bad thing is, that if something bad happens deep inside that magical box, it is quite challenging to analyze and understand what exactly is going on.

My problem had to do with such a case. I am using the Eclipse Modeling Framework (EMF) and my plan is to persist my models using the CDO-Teneo-Hibernate-MySQL bridge. CDO and Teneo are a bit experimental, but they are well supported in the eclipse.technology.emft Newsgroup.

The database persistence uses an approach of mapping arbitrary EMF models to database tables automatically including the dynamic creation of proxies. But as you might guess, all of this requires two sets of plug-ins (CDO and Teneo) as well as the hibernate library (which has further dependencies, e.g. the CGLib to dynamically create proxies) and the database driver library.

So, last week I ran into massive class loading problems, because the different plugins in the CDO and Teneo projects make use of the Hibernate libraries and manage access to them through a rather heterogeneous collection of exporting and importing packages and making use of the Eclipse-BuddyPolicy tag. Using this tag, for example, a user-contributed plugin can contribute the database driver class to the classpath of an existing plug-in.

However, one of the problems was caused by the fact, that the CGLib Java Bytecode generator was going to build a proxy for a class defined in another bundle (let’s say A) but at the same time also needed to incorporate the HibernateProxy interface (which was in the hibernate library in bundle B). And there is no dependency between A and B, because hibernate is a strategy add-on to CDO. Consequently, the class generation went awfully wrong because CGLib would take the classloader associated with its input class (so classloader of bundle A) which of course did not find the HibernateProxy interface from bundle B.

Back then I did not know all that. I only got an exception with a stack trace like this:

net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException-->null
   at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237)
   at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
   at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
   at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:127)
   at org.hibernate.proxy.pojo.cglib.CGLIBProxyFactory.postInstantiate(CGLIBProxyFactory.java:43)
   at org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:162)
   at org.hibernate.tuple.entity.AbstractEntityTuplizer.(AbstractEntityTuplizer.java:135)
   at org.hibernate.tuple.entity.PojoEntityTuplizer.(PojoEntityTuplizer.java:55)
   at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.(EntityEntityModeToTuplizerMapping.java:56)
   at org.hibernate.tuple.entity.EntityMetamodel.(EntityMetamodel.java:302)
   at org.hibernate.persister.entity.AbstractEntityPersister.(AbstractEntityPersister.java:434)
   at org.hibernate.persister.entity.JoinedSubclassEntityPersister.(JoinedSubclassEntityPersister.java:91)
   at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:58)
   at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:226)
   at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1300)
   at org.eclipse.emf.cdo.server.internal.hibernate.HibernatePackageHandler.getSessionFactory(HibernatePackageHandler.java:273)
   ... some more
Caused by: java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at net.sf.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:384)
   at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:219)
   ... 74 more
Caused by: java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
   at java.lang.ClassLoader.defineClass1(Native Method)
   at java.lang.ClassLoader.defineClass(Unknown Source)
   ... 80 more
Caused by: java.lang.ClassNotFoundException: org.hibernate.proxy.HibernateProxy
   at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:481)
   at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)
   at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)
   at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClassInternal(Unknown Source)
   ... 82 more

What …? I thought. CDO calls Hibernate calls CGLib and CGLib can not locate a Hibernate class? So I went digging through the internet tried to understand class loading in Eclipse I found a good article and this Eclipsepedia Entry which provide some insight.

However, this did not really help. If you are stuck somewhere with a ClassNotFoundException, because you don’t know, which class loader was being used to load the class (and failed), you have a problem. Both setting an exception breakpoint and stepping through the execution using the debugger is a bad idea, because there are so many class loads – and also many failing class loads – in Eclipse, that both methods are cumbersome.

A better way to gain information is enabling tracing and activating the class loader trace in org.eclipse.osgi:

This leads to output like this:

BundleClassLoader[org.eclipse.emf.teneo_0.8.0.qualifier].loadClass(org.eclipse.emf.teneo.annotations.pannotation.DiscriminatorValue)
BundleLoader[org.eclipse.emf.teneo_0.8.0.qualifier].loadBundleClass(org.eclipse.emf.teneo.annotations.pannotation.DiscriminatorValue)
BundleLoader[org.eclipse.emf.teneo.annotations_0.8.0.qualifier].findLocalClass(org.eclipse.emf.teneo.annotations.pannotation.DiscriminatorValue)
BundleLoader[org.eclipse.emf.teneo.annotations_0.8.0.qualifier] found local class org.eclipse.emf.teneo.annotations.pannotation.DiscriminatorValue

So you can see in which bundle (in sqare brackets) the classloader looks for your class. This helped me find out, what was going on (described above). To solve my problem, I had to patch the two of the CDO manifests to make the classloader find the additional classes.

One way or another, all that classpath magic is hard to see through, when it comes to dynamic code generation and third party libraries in eclipse.

As a final note: I came over another article (in German), which does not directly address my issues, but could be helpful when you have several plug-ins which have to load different classes from different bundles.

EasyMock is a really useful tool for unit testing. If you want to test a class which is usually contained in a web of collaboration with other classes, you can easily simulate the other classes’ behaviour using a rather simple and powerful mocking mechanism.

And in order to save typing time, you can use this template to create your mock with one keystroke:

${staticImport:importStatic('org.easymock.EasyMock.*')}
${testType:newName} ${cursor} ${mock:newName} = createMock("${mock}", ${testType}.class);

And, as usual, you can directly import the template using this XML.

So you are writing Eclipse Plugin code and have to catch exceptions? Ok, but what to do with them?

e.printStackTrace() is not very nice. And in order to report it to the user or to log it in the plugin’s log, you have to create an instance of Status first.

Here is a template you can use in your exception hander to save typing time:

Status ${status:newName(org.eclipse.core.runtime.Status)} = new Status(
	IStatus.ERROR, ${plugin:link(Activator)}.PLUGIN_ID,
	"Error while ${cause:link(evaluating)}",
	${exception_variable_name}.getCause() == null ? ${exception_variable_name} : ${exception_variable_name}.getCause());

${plugin}.getDefault().getLog().log(${status});
ErrorDialog.openError(getShell(), "Error", "Error while ${cause}", ${status});

Again, you can use this XML to import the template directly.

In this blog I’ll collect some nice Eclipse Java code templates which I use.

I did not find any site collecting those, so there is no place I know of, where one can commit his favourite templates. So here we go:

Adding a trace boolean in order to switch on or off tracing of a plugin:

This inserts a static boolean which can be used to turn tracing on or off using the Tracing tab in the launch configuration dialog. In order to use this, you also have to create a file called .options in your project root. In this file add the line <project name>/<type name>/debug=false.

And here comes the template. Use it at class level:

	private static boolean trace = false;

	static {
		String value = Platform
				.getDebugOption("${enclosing_project}/${enclosing_type}/debug");
		if (value != null && value.equalsIgnoreCase("true")) {
			trace = true;
		}
	}

Quickly insert a method trace:

If the trace infrastructure is set up, a method call can be logged very quickly using

if(trace) {
	System.out.println("${enclosing_type}.${enclosing_method}()");
}

at the beginning of the method.

Generic trace output:

In the middle of a method, use this:

if(trace) {
    System.out.println("  ${cursor}");
}

In order to import these templates, go to the Eclipse preferences dialog, navigate to Java > Editor > Templates and import this XML.