Eclipse 3.0 adapter issues

Last modified: February 16, 2004

This document outlines proposed changes in the 3.0 timeframe to the IAdapterManager infrastructure. Related bug reports contain much of the rationale and discussion:

Current limitations

Proposed solution

Add the following three new methods to IAdapterManager:

public boolean hasAdapter(Object adaptable, String adapterTypeName);
public Object getAdapter(Object adaptable, String adapterTypeName);
public Object[] getAdapters(Object adaptable, String adapterTypeName);

getAdapter returns the first non-null adapter found as it does today (transitive search of superclasses and then super-interfaces). getAdapters returns all adapters for all superclasses and interfaces of the supplied object. Only factories belonging to loaded plug-ins will be consulted by the getAdapter* methods. hasAdapter consults both loaded and unloaded factories.

A new "adapters" extension in the runtime plug-in will specify the name of the factory class, removing the need for plug-ins to explicitly register their adapters on startup (they would be lazily registered on the first lookup on that factory after the plug-in is loaded):

<extension point="org.eclipse.core.runtime.adapters">
      <adapter class="org.eclipse.core.resources.IFile">
      <adapter class="org.eclipse.ui.views.IPropertySource">
      <adapter class="org.eclipse.ui.model.IWorkbenchAdapter">

This extension point specifies a factory that adapts IJavaElement to IFile, IPropertySource, etc. Of course, for backwards compatibility we will continue to support adapters registered manually that do no have associated markup.