Jump to: navigation, search

Difference between revisions of "FAQ Why do the names of some interfaces end with the digit 2?"

 
m
 
Line 1: Line 1:
Owing to evolution in the use of Eclipse, some interfaces had to be
+
Owing to evolution in the use of Eclipse, some interfaces had to be extended with additional functionality. However, because of the dynamic nature of Eclipse, with many products relying on existing plug-ins, changing the signature of an interface requires that all the downstream plug-ins  be not only recompiled but also fixed to implement the new methods required by the interface change.
extended with additional functionality. However, because of the  
+
dynamic nature of Eclipse, with many products relying on existing  
+
plug-ins, changing the signature of an interface requires that all the
+
downstream plug-ins  be not only recompiled but also fixed to  
+
implement the new methods required by the interface change.
+
  
This evolutionary side effect posed a big dilemma: cause all plug-ins
+
This evolutionary side effect posed a big dilemma: cause all plug-ins to break and require intrusive enhancements from customers or introduce a totally new interface containing only the new functionality? Eclipse has chosen the second option. When you press Ctrl+Shift+T to locate a type and enter '''<tt>I*2</tt>''', you will be shown a list of 20 such interfaces.
to break and require intrusive enhancements from customers or introduce
+
a totally new interface containing only the new functionality? Eclipse
+
has chosen the second option. When you press Ctrl+Shift+T to locate  
+
a type and enter '''<tt>I*2</tt>''', you will be shown a
+
list of 20 such interfaces.
+
  
 +
Note that additional overhead can occur. For instance, in class <tt>org.eclipse.ui.internal.PluginAction</tt>, special code needs to verify that the target implements the interface:
  
Note that additional overhead can occur. For instance,
 
in class <tt>org.eclipse.ui.internal.PluginAction</tt>, special code
 
needs to verify that the target implements
 
the interface:
 
 
<pre>
 
<pre>
 
   public void runWithEvent(Event event) {
 
   public void runWithEvent(Event event) {
Line 35: Line 22:
 
</pre>
 
</pre>
  
The code gets messy owing to an early decision to name the  
+
The code gets messy owing to an early decision to name the interface differently. Although interfaces were added to Java to separate <i>types</i> from their <i>implementations</i>, in the case of a successfully adopted platform such as Eclipse, they are not resilient to evolution. Changing them breaks too much existing code. If subclassing is used, the contract can easily be enhanced with a default implementation in the base class. The subclasses would not have to be changed or even recompiled.
interface differently. Although interfaces were added to Java to separate <i>types</i>
+
from their <i>implementations</i>, in the case of a successfully  
+
adopted platform such as Eclipse, they are not resilient to evolution.
+
Changing them breaks too much existing code. If subclassing is
+
used, the contract can easily be enhanced with a default implementation
+
in the base class. The subclasses would not have to be changed or even  
+
recompiled.
+
  
 
<hr><font size=-2>This FAQ was originally published in [http://www.eclipsefaq.org Official Eclipse 3.0 FAQs]. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the [http://www.eclipse.org/legal/epl-v10.html Eclipse Public License v1.0].</font>
 
<hr><font size=-2>This FAQ was originally published in [http://www.eclipsefaq.org Official Eclipse 3.0 FAQs]. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the [http://www.eclipse.org/legal/epl-v10.html Eclipse Public License v1.0].</font>

Latest revision as of 19:54, 29 May 2006

Owing to evolution in the use of Eclipse, some interfaces had to be extended with additional functionality. However, because of the dynamic nature of Eclipse, with many products relying on existing plug-ins, changing the signature of an interface requires that all the downstream plug-ins be not only recompiled but also fixed to implement the new methods required by the interface change.

This evolutionary side effect posed a big dilemma: cause all plug-ins to break and require intrusive enhancements from customers or introduce a totally new interface containing only the new functionality? Eclipse has chosen the second option. When you press Ctrl+Shift+T to locate a type and enter I*2, you will be shown a list of 20 such interfaces.

Note that additional overhead can occur. For instance, in class org.eclipse.ui.internal.PluginAction, special code needs to verify that the target implements the interface:

   public void runWithEvent(Event event) {
      ...
      if (delegate instanceof IActionDelegate2) {
         ((IActionDelegate2)delegate).runWithEvent(this, event);
         return;
      }
      // Keep for backward compatibility with R2.0
      if (delegate instanceof IActionDelegateWithEvent) {
         ((IActionDelegateWithEvent) delegate).
            runWithEvent(this, event);
         return;
      }
      ...
   }

The code gets messy owing to an early decision to name the interface differently. Although interfaces were added to Java to separate types from their implementations, in the case of a successfully adopted platform such as Eclipse, they are not resilient to evolution. Changing them breaks too much existing code. If subclassing is used, the contract can easily be enhanced with a default implementation in the base class. The subclasses would not have to be changed or even recompiled.


This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.