- selection or objects passed to an adaptable contribution is not adapted but contains the actual 
elements without any transformation. This was somewhat inconsistent in 3.0. If this is the case 
what can clients do to protect against getAdapter() returning null?

- selection must be converted lazilly, and only when an action is invoked. It could be cached so that 
the next action gets access to it?

- deprecate objectClass from org.eclipse.ui.popupMenus? This is essentialy the same as adaptable = true?

- does it make sense to even support adaptable=false?

- duplicate adapter registration is a problem, for example:
  jdt contributes IJavaElement -> IProject, IResource
  pkgfragment adapts to IProject but getAdapter will return an IFolder. For backwards compatibility 
  adapters aren't used to IResource instances, and instead IContributorResourceAdapter is called instead.

- Specific adapter mechanism to qualifier type of adapter needed (popup, taskList...)

- Ensure that object.getAdapter(IResource.class) and object.getAdapter(IContributorResourceAdapter.class) were 
used consistently.

- performance consideration in the ObjectActionContributionManager::getCommonClasses(), performance testing 
of this feature.

- tests

- tried to keep it backwards compatible, but there are no tests available. 

- IResource backwards compatibility mode doesn't work in RCP applications that don't require IDE? 
Must test but it seems that IContributorResourceAdapter is located in IDE.


Bugs Related:
========


Problems:
======

A -> B -a-> C -> D
C -a->E

EmbeddedPkgFragment -> IEmbeddedElement -a-> IJavaPkg -> IJavaElement
IJavaElement -a-> IResource

factory(IEmbeddedElement -> IJavaElement)
factory(IJavaElement -> IResource)

- should getAdapter(EmbeddedPkgFragment, IJavaElement) return true? (need to parse super classes/types or registered 
- should getAdapter(EmbeddedPkgFragment, IResource) return true? (transitive)

Proposed Solution:
============

Given a selection, find the common classes and common adapters.