plugins/org.eclipse.objectteams.otdt.doc/guide/news/new_in_2.1.html - objectteams/org.eclipse.objectteams - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <html>
 <head>
     <link rel=stylesheet type="text/css" href="../css/style.css">
     <link rel=stylesheet type="text/css" href="../css/nn.css">
 	<title>OTDT 2.1 - New and Noteworthy</title>
 </head>
 <body>
 <h1>OTDT 2.1 - New and Noteworthy</h1>
 <div class="navigation"><i>Status: 2.1 M5</i></div>
 <div class="navigation">On this page:
 <!--a href="#metrics">&bull; Metrics Plug-in</a-->
 <!--a href="#configuration">&bull; Configuration</a-->
 <!--a href="#views">&bull; Views/Dialogs</a-->
 <a href="#assist">&bull; Content Assist</a>
 <!--a href="#refactor">&bull; Refactoring</a-->
 <a href="#formatting">&bull; Formatting</a>
 <a href="#debug">&bull; Run/Debug</a>
 <a href="#language">&bull; Language</a>
 <!--a href="#api">&bull; API</a-->
 <a href="#compiler">&bull; Compiler</a>
 <a href="#otre">&bull; Runtime</a>
 <!--a href="#otequinox">&bull; OT/Equinox</a-->
 </div>
 <table cellpadding="10" cellspacing="0" width="100%">
   <colgroup>
   <col width="20%">
   <col width="80%">
   </colgroup>
   <tbody>
 <!--
   <tr><td colspan="2" id="NAME"><h2>HEADING</h2></td></tr>
   <tr>
     <td><p align="right"><b>DESC</b><br>
         <span class="since">since&nbsp;0.7.1</span><br>
         <a class="buglink" title="TITLE" href="https://bugs.eclipse.org/308029">308029</a></p></td>
     <td><p>

     	</p>
     	<p><img alt="TEXT" src="../images/screenshots/NN07/.png"></p>
     	<p></p>
     </td>
   </tr>
   <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">MyTeam</font> {
 }</pre></div></div>
   <tr><td colspan="2" id="views"><h2>Views & Dialogs</h2></td></tr>
 -->
   <tr><td colspan="2" id="assist"><h2>Content assist</h2></td></tr>
   <tr>
     <td><p align="right"><b>Add signatures to method binding</b><br>
         <span class="since">since&nbsp;2.1M2</span><br>
         <a class="buglink" title="[assist] make the add signatures assist smarter vis-a-vis ambiguous method bindings" href="https://bugs.eclipse.org/355274">355274</a></p></td>
     <td><p>The existing quick assist "Add signatures to method binding" has been improved
     		so that it can be used on a a signature-less method binding even if it fails to resolve its base method(s).
      		In case the base class has more than one method of the name mentioned in the method binding,
      		all matching base methods are collected, the best match is inserted into the editor
      		and other matches are offered as alternatives in linked mode.
     	</p>
     	<p>
     		So, if before invoking the assist you have:
     	</p>
     	<p><img alt="Ambiguous base method" src="../images/screenshots/NN21/AmbiguousBaseMethod.png"></p>
     	<p>you may invoke the assist as a quickfix (e.g., from the error hover), producing this change:</p>
     	<p><img alt="Add signatures quick assist" src="../images/screenshots/NN21/AddSignaturesAssist.png"></p>
     	<p>where you may select the suitable base method from a list.</p>
     	<p><strong>Hint:</strong> If a method binding has an incorrect signature you may first remove signatures (using a quick assist)
     	   and then let this new assist insert correct signatures.</p>
     </td>
   </tr>
   <tr>
     <td><p align="right"><b>Implement abstract methods from implicit&nbsp;super&nbsp;role</b><br>
         <span class="since">since&nbsp;2.1M3</span><br>
         <a class="buglink" title="[quickfix] implement abstract methods from tsuper" href="https://bugs.eclipse.org/348574">348574</a></p></td>
     <td><p>The existing quick assist "Add unimplemented methods" has been extended to apply also to those abstract methods
     		that are <b>implicitly inherited</b> from the corresponding role in the super team.
     	</p>
     	<p>
     		The error against the role class now provides the quick fix:
     	</p>
     	<p><img alt="Must implement .. abstract method" src="../images/screenshots/NN21/ImplementFromTSuper.png"></p>
     	<p>Invoking the quick fix (e.g., from the error hover) produces this change:</p>
     	<p><img alt="Result of &quot;Add unimplemented methods&quot; quick fix" src="../images/screenshots/NN21/ImplementFromTSuper1.png"></p>
     </td>
   </tr>
   <tr>
     <td><p align="right"><b>Improved handling of base imports</b><br>
         <span class="since">since&nbsp;2.1M5</span><br>
         <a class="buglink" title="improve handling of base imports" href="https://bugs.eclipse.org/356003">356003</a></p></td>
     <td><p>So-called "base imports" are used in OT/J to distinguish those classes that are imported only as a base class of
     		a role in the current team, disallowing direct use within the implementation of the team and its roles (see <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s2.html#s2.1.2.d">OTJLD &sect;2.1.2(d)</a>).
     		The umbrella bug 356003 lists several individual improvements to make content assist, wizards, and refactoring
     		better aware of the semantic rules of base imports.
     		In all these situations the correct base import or regular imported is now created,
     		and base imports are correctly updated if mandated by a refactoring.
     	</p>
     </td>
   </tr>
   <tr><td colspan="2" id="formatting"><h2>Formatting</h2></td></tr>
   <tr>
     <td><p align="right"><b>Basid code formatting for OT/J</b><br>
         <span class="since">since&nbsp;2.1M5</span><br>
         <a class="buglink" title="Formatter fails silently on big Teams" href="https://bugs.eclipse.org/331731">331731</a></p></td>
     <td><p>In previous versions support for code formatting for OT/J was incomplete, and the occurrence of some
     		constructs like <code class="keyword">precedence</code> made the formatter silently fail.
     		As of 2.1 M5 code formatting for OT/J now generally works for all language constructs.
     		Results may not be optimal for all syntax elements because no special preference options have been introduced
     		for elements like callin / callout. However, users who don't object to the default formatting style
     		can now rely on automatic formatting of roles and teams.
     	</p>
     </td>
   </tr>
 <!--
   <tr><td colspan="2" id="refactor"><h2>Refactoring</h2></td></tr>
 -->
   <tr><td colspan="2" id="language"><h2>Language</h2></td></tr>
   <tr>
     <td><p align="right"><b>Java 7 support</b><br>
         <span class="since">since&nbsp;2.1M1</span><br>
         <a class="buglink" title="Upgrade to Java7" href="https://bugs.eclipse.org/353894">353894</a></p></td>
     <td><p>Starting with 2.1 M1, OT/J has been integrated with Java 7, i.e., the OT/J compiler also supports all
     		<a href="http://www.eclipse.org/jdt/ui/r3_8/Java7news/whats-new-java-7.html">new features introduced in Java 7</a>.
     	</p>
     </td>
   </tr>
   <tr>
     <td><p align="right"><b>@Override for static&nbsp;role&nbsp;methods</b><br>
         <span class="since">since&nbsp;2.1M3</span><br>
         <a class="buglink" title="[compiler] support @Override for static role methods" href="https://bugs.eclipse.org/359894">359894</a></p></td>
     <td><p>Along implicit inheritence a role can override even a static method from its implicit super role.
     		This overriding can now be documented using an <code>@Override</code> annotation,
     		which will cause the compiler to check if the claimed overriding actually happens:
     	</p>
     	<p>
     	<div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> T0 {
    <code class="keyword">protected class</code> R {
        <code class="keyword">static int</code> zork() { return 0;}
    }
 }
 <code class="keyword">public team class</code> T1 <code class="keyword">extends</code> T0 {
    <code class="annotation">@Override</code>
    <code class="keyword">protected class</code> R {
        <code class="annotation">@Override</code> <code class="comment">// OK</code>
        <code class="keyword">static int</code> zork() { return 1;}

        <code class="annotation">@Override</code> <code class="comment">// <b style="color:red;">ERROR</b></code>
        <code class="keyword">static void</code> bar() { }
    }
 }</pre></div></div>
     	</p>
     </td>
   </tr>
   <tr><td colspan="2" id="debug"><h2>Run / Debug</h2></td></tr>
   <tr>
     <td><p align="right"><b>Simplified launching with OT/Equinox</b><br>
         <span class="since">since&nbsp;2.1M4</span><br>
         <a class="buglink" title="[debug] make OT/Equinox launches location independent" href="https://bugs.eclipse.org/366315">366315</a></p></td>
     <td><p>
     		OT/Equinox is implemented using a fragment that acts as a <em>framework extension</em> for Equinox.
     		So far this required that the OT/Equinox bundles be located in the same place were also the <code>org.eclipse.osgi</code>
     		is located.
     		This could make it difficult to debug OT/Equinox itself, because then all mentioned bundles would have to be setup
     		as projects physically stored in the workspace.
     	</p>
     	<p>
     		This restriction has been removed, i.e., the OT/Equinox bundles may be resolved from the workspace while
     		<code>org.eclipse.osgi</code> is resolved from the base platform.
     	</p>
     </td>
   </tr>
 <!--
   <tr><td colspan="2" id="api"><h2>API</h2></td></tr>
 -->
   <tr><td colspan="2" id="compiler"><h2>Compiler</h2></td></tr>
   <tr><td><p align="right"><b>Report multiple callins</b><br>
         <span class="since">since&nbsp;2.1M2</span><br>
         <a class="buglink" title="Produce warning when two roles capture the same method at the same time" href="https://bugs.eclipse.org/314610">314610</a></p></td>
     <td><p>When two independent callin bindings affect the same base method this <em>might</em> give rise to unanticipated behavior.
     		Therefor a new warning is reported to alert the user of this situation:
   		</p>
   		<p><img alt="Multiple callin bindings are affecting method foo()" src="../images/screenshots/NN21/MultipleCallins.png"></p>
   		<p>As mentioned in the warning message, this diagnostic is recomputed only during full builds,
   			because this computation requires a whole system analysis.
   		</p>
   		<p>Use the callin marker in the left ruler to navigate to the potentially conflicting callin bindings for inspection
   			(sorry for the clutter between the callin marker and the warning marker):
   		</p>
   		<p><img alt="OT/J callin bindings navigation" src="../images/screenshots/NN21/GotoCallin.png"></p>
   	</td>
   </tr>

   <tr><td colspan="2" id="otre"><h2>Object Teams Runtime Environment</h2></td></tr>
   <tr>
     <td><p align="right"><b>Memory optimization</b><br>
         <span class="since">since&nbsp;2.1M2</span><br>
         <a class="buglink" title="[otre] class RepositoryAccess is wasting memory" href="https://bugs.eclipse.org/355328">355328</a></p></td>
     <td><p>
 			Memory consumption of the OTRE could be reduced significantly.
 			A given class from BCEL was retaining the full structure for loaded classes, which could be reduced to a much more compact format.
 			Measurements showed a reduction of this data structure to approx. 1% of the original size.
     	</p>
     </td>
   </tr>
   <tr>
     <td><p align="right"><b>Performance optimization</b><br>
         <span class="since">since&nbsp;2.1M2</span><br>
         <a class="buglink" title="[otre] avoid performance penalty due to eager creation of _OT$roleSet" href="https://bugs.eclipse.org/355263">355263</a></p></td>
     <td><p>
 			An internal data structure woven into each base class was initialized eagerly causing a performance penalty.
 			This eager initialization could be removed completely, lazy initialization was already implemented.
 			For situations where lots of base objects were created for which no role was ever created
 			this results in a speedup of up-to 3.5 (from a micro benchmark).
     	</p>
     </td>
   </tr>

 </table>
 </body>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
	<html>
	<head>
	<link rel=stylesheet type="text/css" href="../css/style.css">
	<link rel=stylesheet type="text/css" href="../css/nn.css">
	<title>OTDT 2.1 - New and Noteworthy</title>
	</head>
	<body>
	<h1>OTDT 2.1 - New and Noteworthy</h1>
	<div class="navigation"><i>Status: 2.1 M5</i></div>
	<div class="navigation">On this page:
	<!--a href="#metrics">• Metrics Plug-in</a-->
	<!--a href="#configuration">• Configuration</a-->
	<!--a href="#views">• Views/Dialogs</a-->
	<a href="#assist">• Content Assist</a>
	<!--a href="#refactor">• Refactoring</a-->
	<a href="#formatting">• Formatting</a>
	<a href="#debug">• Run/Debug</a>
	<a href="#language">• Language</a>
	<!--a href="#api">• API</a-->
	<a href="#compiler">• Compiler</a>
	<a href="#otre">• Runtime</a>
	<!--a href="#otequinox">• OT/Equinox</a-->
	</div>
	<table cellpadding="10" cellspacing="0" width="100%">
	<colgroup>
	<col width="20%">
	<col width="80%">
	</colgroup>
	<tbody>
	<!--
	<tr><td colspan="2" id="NAME"><h2>HEADING</h2></td></tr>
	<tr>
	<td><p align="right"><b>DESC</b><br>
	<span class="since">since 0.7.1</span><br>
	<a class="buglink" title="TITLE" href="https://bugs.eclipse.org/308029">308029</a></p></td>
	<td><p>

	</p>
	<p><img alt="TEXT" src="../images/screenshots/NN07/.png"></p>
	<p></p>
	</td>
	</tr>
	<div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">MyTeam</font> {
	}</pre></div></div>
	<tr><td colspan="2" id="views"><h2>Views & Dialogs</h2></td></tr>
	-->
	<tr><td colspan="2" id="assist"><h2>Content assist</h2></td></tr>
	<tr>
	<td><p align="right"><b>Add signatures to method binding</b><br>
	<span class="since">since 2.1M2</span><br>
	<a class="buglink" title="[assist] make the add signatures assist smarter vis-a-vis ambiguous method bindings" href="https://bugs.eclipse.org/355274">355274</a></p></td>
	<td><p>The existing quick assist "Add signatures to method binding" has been improved
	so that it can be used on a a signature-less method binding even if it fails to resolve its base method(s).
	In case the base class has more than one method of the name mentioned in the method binding,
	all matching base methods are collected, the best match is inserted into the editor
	and other matches are offered as alternatives in linked mode.
	</p>
	<p>
	So, if before invoking the assist you have:
	</p>
	<p><img alt="Ambiguous base method" src="../images/screenshots/NN21/AmbiguousBaseMethod.png"></p>
	<p>you may invoke the assist as a quickfix (e.g., from the error hover), producing this change:</p>
	<p><img alt="Add signatures quick assist" src="../images/screenshots/NN21/AddSignaturesAssist.png"></p>
	<p>where you may select the suitable base method from a list.</p>
	<p><strong>Hint:</strong> If a method binding has an incorrect signature you may first remove signatures (using a quick assist)
	and then let this new assist insert correct signatures.</p>
	</td>
	</tr>
	<tr>
	<td><p align="right"><b>Implement abstract methods from implicit super role</b><br>
	<span class="since">since 2.1M3</span><br>
	<a class="buglink" title="[quickfix] implement abstract methods from tsuper" href="https://bugs.eclipse.org/348574">348574</a></p></td>
	<td><p>The existing quick assist "Add unimplemented methods" has been extended to apply also to those abstract methods
	that are <b>implicitly inherited</b> from the corresponding role in the super team.
	</p>
	<p>
	The error against the role class now provides the quick fix:
	</p>
	<p><img alt="Must implement .. abstract method" src="../images/screenshots/NN21/ImplementFromTSuper.png"></p>
	<p>Invoking the quick fix (e.g., from the error hover) produces this change:</p>
	<p><img alt="Result of "Add unimplemented methods" quick fix" src="../images/screenshots/NN21/ImplementFromTSuper1.png"></p>
	</td>
	</tr>
	<tr>
	<td><p align="right"><b>Improved handling of base imports</b><br>
	<span class="since">since 2.1M5</span><br>
	<a class="buglink" title="improve handling of base imports" href="https://bugs.eclipse.org/356003">356003</a></p></td>
	<td><p>So-called "base imports" are used in OT/J to distinguish those classes that are imported only as a base class of
	a role in the current team, disallowing direct use within the implementation of the team and its roles (see <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s2.html#s2.1.2.d">OTJLD §2.1.2(d)</a>).
	The umbrella bug 356003 lists several individual improvements to make content assist, wizards, and refactoring
	better aware of the semantic rules of base imports.
	In all these situations the correct base import or regular imported is now created,
	and base imports are correctly updated if mandated by a refactoring.
	</p>
	</td>
	</tr>
	<tr><td colspan="2" id="formatting"><h2>Formatting</h2></td></tr>
	<tr>
	<td><p align="right"><b>Basid code formatting for OT/J</b><br>
	<span class="since">since 2.1M5</span><br>
	<a class="buglink" title="Formatter fails silently on big Teams" href="https://bugs.eclipse.org/331731">331731</a></p></td>
	<td><p>In previous versions support for code formatting for OT/J was incomplete, and the occurrence of some
	constructs like <code class="keyword">precedence</code> made the formatter silently fail.
	As of 2.1 M5 code formatting for OT/J now generally works for all language constructs.
	Results may not be optimal for all syntax elements because no special preference options have been introduced
	for elements like callin / callout. However, users who don't object to the default formatting style
	can now rely on automatic formatting of roles and teams.
	</p>
	</td>
	</tr>
	<!--
	<tr><td colspan="2" id="refactor"><h2>Refactoring</h2></td></tr>
	-->
	<tr><td colspan="2" id="language"><h2>Language</h2></td></tr>
	<tr>
	<td><p align="right"><b>Java 7 support</b><br>
	<span class="since">since 2.1M1</span><br>
	<a class="buglink" title="Upgrade to Java7" href="https://bugs.eclipse.org/353894">353894</a></p></td>
	<td><p>Starting with 2.1 M1, OT/J has been integrated with Java 7, i.e., the OT/J compiler also supports all
	<a href="http://www.eclipse.org/jdt/ui/r3_8/Java7news/whats-new-java-7.html">new features introduced in Java 7</a>.
	</p>
	</td>
	</tr>
	<tr>
	<td><p align="right"><b>@Override for static role methods</b><br>
	<span class="since">since 2.1M3</span><br>
	<a class="buglink" title="[compiler] support @Override for static role methods" href="https://bugs.eclipse.org/359894">359894</a></p></td>
	<td><p>Along implicit inheritence a role can override even a static method from its implicit super role.
	This overriding can now be documented using an <code>@Override</code> annotation,
	which will cause the compiler to check if the claimed overriding actually happens:
	</p>
	<p>
	<div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> T0 {
	<code class="keyword">protected class</code> R {
	<code class="keyword">static int</code> zork() { return 0;}
	}
	}
	<code class="keyword">public team class</code> T1 <code class="keyword">extends</code> T0 {
	<code class="annotation">@Override</code>
	<code class="keyword">protected class</code> R {
	<code class="annotation">@Override</code> <code class="comment">// OK</code>
	<code class="keyword">static int</code> zork() { return 1;}

	<code class="annotation">@Override</code> <code class="comment">// <b style="color:red;">ERROR</b></code>
	<code class="keyword">static void</code> bar() { }
	}
	}</pre></div></div>
	</p>
	</td>
	</tr>
	<tr><td colspan="2" id="debug"><h2>Run / Debug</h2></td></tr>
	<tr>
	<td><p align="right"><b>Simplified launching with OT/Equinox</b><br>
	<span class="since">since 2.1M4</span><br>
	<a class="buglink" title="[debug] make OT/Equinox launches location independent" href="https://bugs.eclipse.org/366315">366315</a></p></td>
	<td><p>
	OT/Equinox is implemented using a fragment that acts as a <em>framework extension</em> for Equinox.
	So far this required that the OT/Equinox bundles be located in the same place were also the <code>org.eclipse.osgi</code>
	is located.
	This could make it difficult to debug OT/Equinox itself, because then all mentioned bundles would have to be setup
	as projects physically stored in the workspace.
	</p>
	<p>
	This restriction has been removed, i.e., the OT/Equinox bundles may be resolved from the workspace while
	<code>org.eclipse.osgi</code> is resolved from the base platform.
	</p>
	</td>
	</tr>
	<!--
	<tr><td colspan="2" id="api"><h2>API</h2></td></tr>
	-->
	<tr><td colspan="2" id="compiler"><h2>Compiler</h2></td></tr>
	<tr><td><p align="right"><b>Report multiple callins</b><br>
	<span class="since">since 2.1M2</span><br>
	<a class="buglink" title="Produce warning when two roles capture the same method at the same time" href="https://bugs.eclipse.org/314610">314610</a></p></td>
	<td><p>When two independent callin bindings affect the same base method this <em>might</em> give rise to unanticipated behavior.
	Therefor a new warning is reported to alert the user of this situation:
	</p>
	<p><img alt="Multiple callin bindings are affecting method foo()" src="../images/screenshots/NN21/MultipleCallins.png"></p>
	<p>As mentioned in the warning message, this diagnostic is recomputed only during full builds,
	because this computation requires a whole system analysis.
	</p>
	<p>Use the callin marker in the left ruler to navigate to the potentially conflicting callin bindings for inspection
	(sorry for the clutter between the callin marker and the warning marker):
	</p>
	<p><img alt="OT/J callin bindings navigation" src="../images/screenshots/NN21/GotoCallin.png"></p>
	</td>
	</tr>

	<tr><td colspan="2" id="otre"><h2>Object Teams Runtime Environment</h2></td></tr>
	<tr>
	<td><p align="right"><b>Memory optimization</b><br>
	<span class="since">since 2.1M2</span><br>
	<a class="buglink" title="[otre] class RepositoryAccess is wasting memory" href="https://bugs.eclipse.org/355328">355328</a></p></td>
	<td><p>
	Memory consumption of the OTRE could be reduced significantly.
	A given class from BCEL was retaining the full structure for loaded classes, which could be reduced to a much more compact format.
	Measurements showed a reduction of this data structure to approx. 1% of the original size.
	</p>
	</td>
	</tr>
	<tr>
	<td><p align="right"><b>Performance optimization</b><br>
	<span class="since">since 2.1M2</span><br>
	<a class="buglink" title="[otre] avoid performance penalty due to eager creation of _OT$roleSet" href="https://bugs.eclipse.org/355263">355263</a></p></td>
	<td><p>
	An internal data structure woven into each base class was initialized eagerly causing a performance penalty.
	This eager initialization could be removed completely, lazy initialization was already implemented.
	For situations where lots of base objects were created for which no role was ever created
	this results in a speedup of up-to 3.5 (from a micro benchmark).
	</p>
	</td>
	</tr>

	</table>
	</body>