blob: deb4251e65c1172a222d5274fc447576b219c1d2 [file] [log] [blame]
<!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 M7</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-->
<a href="#releng">&bull; Release Engineering</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><p align="right"><b>Lifting in call hierarchy</b><br>
<span class="since">since&nbsp;2.1M6</span><br>
<a class="buglink" title="CallHierarchy should consider lifting as role instance creation" href="https://bugs.eclipse.org/301314">301314</a></p></td>
<td><p>Previously, the call hierarchy for a role constructor was incomplete because
roles can be constructed on-demand by lifting.
To visualize this implicit behavior the call hierarchy has been extended to
consider occurrences of lifting as invocations of the role's lifting constructor.
</p>
<p><img alt="Call hierarchy for role construction" src="../images/screenshots/NN21/callHierarchyLifting.png"></p>
<p>Here the call hierarchy was opened for the role type <code>Item</code> to find all paths towards instantiation.
The call hierarchy shows the callin binding <code>earchCredit <- after book</code> because it may
trigger lifting a <code>Segment</code> to its <code>Item</code> role.</p>
</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>Basic 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><p align="right"><b>Base class as method return</b><br>
<span class="since">since&nbsp;2.1M6</span><br>
<a class="buglink" title="[compiler][otjld] consider allowing base imported types as the return type of a team method" href="https://bugs.eclipse.org/370273">370273</a></p></td>
<td><p>Mentioning a base imported class in the body of a team or role is not allowed.
However, a team method may want to return a role which then should be lowered on the way.
Previously, this lowering was not possible, because the base type could not be mentioned (by its simple name).
For the specific situation of team method return types this restriction has been removed.
</p>
<p>
<div class="listbox"><div class="listing"><pre><code class="keyword">import base</code> some.pack.Base; // <span style="color:red">base import restricts usage of "Base"</span>
<code class="keyword">public team class</code> T {
<code class="keyword">protected class</code> R <code class="keyword">playedBy</code> Base { }
<code class="keyword">private </code> R r;
<code class="keyword">public</code> <b style="color:blue">Base</b> getObject() {
<code class="keyword">return this</code>.r; // <span style="color:green">applies lowering</span>
}
}</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><p align="right"><b>Hot code replacement</b><br>
<span class="since">since&nbsp;2.1M7</span><br>
<a class="buglink" title="[debug] support hot code replacement of teams/roles/bases" href="https://bugs.eclipse.org/378176">378176</a><br>
<a class="buglink" title="Support Hot Code Replacement for OT/Equinox" href="https://bugs.eclipse.org/378195">378195</a></p></td>
<td><p>
Previously, when debugging an OT/J or OT/Equinox application,
changes made to the source code of the running application could not be applied on the fly,
because the JVM would detect signature mismatches.
This was caused by the fact that during hot code replacement the Object Teams bytecode transformer was not used.
</p>
<p>
This has been fixed by enabling the Object Teams transformer to re-weave already loaded classes.
Additionally, for OT/Equinox debug launches a new Java agent has been developed
to trigger weaving also for hot code replacement (which is not supported by the underlying adaptor hooks in Equinox).
This agent is automatically added to the Java command line for all OT/Equinox debug launches.
</p>
<p>
As the result it is now possible to directly see the effect of source code changes even in woven
classes without restarting the application. Note, that hot code replacement is limited by the JVM
to changes that do not affect any signatures.
</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>
<tr><td colspan="2" id="releng"><h2>Release Engineering</h2></td></tr>
<tr><td><p align="right"><b>Source bundles</b><br>
<span class="since">since&nbsp;2.1M6</span><br>
<a class="buglink" title="Create source bundles and feature" href="https://bugs.eclipse.org/370650">370650</a></p></td>
<td><p>We now ship an additional (optional) feature, <code>org.eclipse.objectteams.otdt.source.feature</code>
that includes the source code of all Object Teams plug-ins to support browsing into binary plug-ins
on which plug-in projects in the workspace depend.
</p>
</td>
</tr>
</table>
</body>