blob: b96821e1b44620d5945e7130db9eac696e327472 [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 0.7.1 (Incubation) - New and Noteworthy</title>
</head>
<body>
<h1>OTDT 0.7.1 (Incubation) - New and Noteworthy</h1>
<div class="navigation"><i>Changes since the 0.7.0 Release</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><p align="right"><b>Traditional Hierarchy View</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[hierarchy] revive and adjust traditional type hierarchy for OT/J " href="https://bugs.eclipse.org/322898">322898</a></p></td>
<td><p>
The "traditional" hierarchy view is a mode of the Type Hierarchy View,
where starting from a given focus type both the tree of subclasses and the chain of superclass
is rendered in a single view. Due to the fact that roles may have multiple superclasses this
mode was disabled in the OTDT.
</p>
<p>
A new adaptation of the internal <code>TypeHierarchy</code> classes allows us to
linearize the set of superclasses wrt the focus class, i.e., superclasses are shown
in the order as seen from the focus class, which prioritizes implicit inheritance
over explicit inheritance.
</p>
<p>E.g., consider the following code:
<div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> EcoSystem {
<code class="keyword">protected class</code> Project { }
<code class="keyword">protected class</code> IDEProject <code class="keyword">extends</code> Project { }
}
<code class="keyword">public team class</code> Eclipse <code class="keyword">extends</code> EcoSystem {
@Override
<code class="keyword">protected class</code> Project { }
@Override
<code class="keyword">protected class</code> <font color="blue">IDEProject</font><em class="comment">/*open Type Hierarchy here*/</em> <code class="keyword">extends</code> Project { }
<code class="keyword">protected class</code> CDT <code class="keyword">extends</code> IDEProject { }
<code class="keyword">protected class</code> JDT <code class="keyword">extends</code> IDEProject { }
<code class="keyword">protected class</code> OTDT <code class="keyword">extends</code> IDEProject { }
}</pre></div></div></p>
<p>
which yields the following rendering:
</p>
<p><img alt="TEXT" src="../images/screenshots/NN07/othierarchy.png"></p>
<p></p>
</td>
</tr>
<tr><td colspan="2" id="assist"><h2>Content assist</h2></td></tr>
<tr>
<td><p align="right"><b>Adjust callin return</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[assist] creating before/after callin using completion should set return type to void" href="https://bugs.eclipse.org/315310">315310</a></p></td>
<td><p>
Previously, when creating a callin method using completion, the role method designator would be created with
the exact same return type as the bound base method. However, for before and especially after callin bindings
this was misleading, because any value returned by the role method would be simply ignored.
</p>
<p>
In order to avoid confusing the user, method binding completion now works with the following changes:
<ul><li>Completion generally offers the option to replace the role method return type with <code class="keyword">void</code>:</li></ul>
</p>
<p><img alt="Return type options" src="../images/screenshots/NN07/CreateMethodBinding1.png"></p>
<p>
<ul><li>Still, the binding kind <code class="keyword">&lt;- after</code> can be selected without
selecting <code>void</code> as the return type:</li></ul>
</p>
<p><img alt="Selecting after" src="../images/screenshots/NN07/CreateMethodBinding2.png"></p>
<p>
<ul><li>However, when the binding kind is confirmed by hitting enter, the return type is
automatically adjusted to <code>void</code>:</li></ul>
</p>
<p><img alt="Created method binding" src="../images/screenshots/NN07/CreateMethodBinding3.png"></p>
</td>
</tr>
<tr><td colspan="2" id="refactor"><h2>Refactoring</h2></td></tr>
<tr>
<td><p align="right"><b>Change Signature Refacoring</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[refactoring] adapt &quot;change signature&quot; refactoring" href="https://bugs.eclipse.org/311879">311879</a></p></td>
<td><p>
The Change Signature refactoring has been adapted to work for OT/J sources, too.
Now, if the signature of a method is refactored that is referenced from a callout or callin method binding,
the binding is adjusted accordingly. The refactoring tries to absorb all changes within the binding,
like adding a parameter mapping to absorb a re-ordering of arguments.
If a change needs to be propagated through the binding (i.e., it cannot be fully absorbed)
the refactoring will inform the user by issuing a warning.
</p>
<p>
Here is a preview of a refactoring, where the signature of <code>bm</code> has been changed by
(a) adding an argument <code>String str</code> and (b) moving argument <code>i</code> to the end:
</p>
<p><a href="../images/screenshots/NN07/ChangeSignature2.png"><img alt="Change Signature preview" src="../images/screenshots/NN07/ChangeSignature2.png" width=800"></a></p>
<p></p>
</td>
</tr>
<tr><td colspan="2" id="debug"><h2>Run / Debug</h2></td></tr>
<tr>
<td><p align="right"><b>Stack frame beautifying</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[debug] private role method bridge is interpreted as callin wrapper" href="https://bugs.eclipse.org/318993">318993</a></p></td>
<td><p>
The Debug View now knows about more kinds of synthetic methods generated by the OT/J compiler.
All these methods are beautified by replacing the internal name with a human readable explanation
and de-emphasizing these stack frames using a lighter color.
</p>
<p><img alt="Beautified stack frames" src="../images/screenshots/NN07/MoreDebugColoring.png"></p>
<p>The shaded stackframes in the above screenshot signify (from top to bottom):
<ul>
<li>Access to a private base method applying decapsulation</li>
<li>Invocation of a synthetic method for initializing the fields of a role</li>
<li>Indirect invocation of a role's constructor (late binding of the role class)</li>
</ul>
</p>
</td>
</tr>
<tr><td colspan="2" id="api"><h2>API</h2></td></tr>
<tr>
<td><p align="right"><b>isActive() is now final</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[otre] overriding Team.isActive() may cause deadlock" href="https://bugs.eclipse.org/324537">324537</a></p></td>
<td><p>
Previously, methods <code>Team.isActive()</code> and <code>Team.isActive(Thread)</code> could be overridden in sub-teams,
but if an overriding version did not return immediately it could cause a deadlock,
because the infrastructure invokes these methods from synchronized blocks.
</p>
<p>In order to avoid this risk of deadlocks, both methods have been changed to <code class="keyword">final</code>.
</p>
</td>
</tr> <tr><td colspan="2" id="language"><h2>Language</h2></td></tr>
<tr>
<td><p align="right"><b>Internal State Pattern</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[otjld] [compiler] Support the &quot;Internal Role&quot; pattern" href="https://bugs.eclipse.org/318815">318815</a></p></td>
<td><p>
Previously, <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s2.html#s2.1.2.b">OTJLD &sect;2.1.2(b)</a>
disallowed to bind a role to its enclosing team. This rule was found to be overly cautious and prohibitive.
By essentially removing this restriction (except for a few corner cases), the following pattern is
now possible:
<div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">MyTeam</font> {
<code class="keyword">public void</code> service() { ... }
<code class="keyword">enum</code> Mode {NORMAL, MAINTENANCE, BOOT_IN_PROGRESS};
Mode mode;
<code class="keyword">protected class</code> MaintenanceMode <code class="keyword">playedBy</code> <font color="blue">MyTeam</font>
<code class="keyword">base when</code> (MyTeam.this.mode == Mode.MAINTENANCE) {
mainenanceNotice <code class="keyword"><- replace</code> service;
...
}
<code class="keyword">protected class</code> BootingMode <code class="keyword">playedBy</code> <font color="blue">MyTeam</font>
<code class="keyword">base when</code> (MyTeam.this.mode == Mode.BOOT_IN_PROGRESS) { ... }
}</pre></div></div>
The point is here that both roles adapt their enclosing team <code style="color:blue;">MyTeam</code> - thus providing a very well
localized implementation for different states/modes of the team.
</p>
<p>Note, that the above code will cause the compiler to signal a warning: "Base class MyTeam is an enclosing type of MaintenanceMode ...",
which can be silenced by <code>@SuppressWarnings("baseclasscycle")</code>
</p>
<p>See also the <a href="http://wiki.eclipse.org/index.php?title=OTPattern/InnerState">Internal State Pattern</a> in the wiki.</p>
</td>
</tr>
<tr><td colspan="2" id="compiler"><h2>Compiler</h2></td></tr>
<tr>
<td><p align="right"><b>playedBy Interface</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[compiler][otre] support for role-binding to interfaces" href="https://bugs.eclipse.org/321440">321440</a></p></td>
<td><p>
The OTJLD never said that the type after <code class="keyword">playedBy</code> definitely must be a class,
but contained a note mentioning a compiler limitation in this regard.
This limitation has been weakened so that now a role can also be bound to an interface.
Only, in such situations the role cannot declare callin method bindings (callout is not a problem).
It is of course possible to define sub-roles that are bound to classes implementing the base interface
such that those sub-roles can declare callin bindings, too.
</p>
</td>
</tr>
<tr><td colspan="2" id="otre"><h2>Object Teams Runtime Environment</h2></td></tr>
<tr>
<td><p align="right"><b>Packaged as a bundle</b><br>
<span class="since">since&nbsp;0.7.1</span><br>
<a class="buglink" title="[pde] Exporting an OT plug-in requires to have org.eclipse.objectteams.runtime in the ws" href="https://bugs.eclipse.org/320191">320191</a></p></td>
<td><p>
Packaging and deployment of the OTRE has changed from a plain Jar to a regular OSGi bundle called <code>org.eclipse.objectteams.runtime</code>.
Yet, this bundle Jar can still be used outside any OSGi context.
While this simplifies several build and deploy issues, the change should be mostly transparent for users.
Only when compiling/running OT/J applications outside Eclipse script will need adjusting to refer
to the bundle Jar instead of the old <code>otre.jar</code>.
</p>
</td>
</tr>
</table>
</body>