Gitiles
Code Review Sign In
git.eclipse.org / objectteams / org.eclipse.objectteams / 7b320d8eff74e6c18354650e3325b44dc4e57f0a / . / plugins / org.eclipse.objectteams.otdt.ui.help / guide / news / new_in_0.7.1.html
blob: b96821e1b44620d5945e7130db9eac696e327472 [file] [log] [blame]
Stephan Herrmann7b320d82011-06-13 21:31:37 +0000[diff] [blame^]1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
2<html>
3<head>
4 <link rel=stylesheet type="text/css" href="../css/style.css">
5 <link rel=stylesheet type="text/css" href="../css/nn.css">
6 <title>OTDT 0.7.1 (Incubation) - New and Noteworthy</title>
7</head>
8<body>
9<h1>OTDT 0.7.1 (Incubation) - New and Noteworthy</h1>
10<div class="navigation"><i>Changes since the 0.7.0 Release</i></div>
11<div class="navigation">On this page:
12<!--a href="#metrics">&bull; Metrics Plug-in</a-->
13<!--a href="#configuration">&bull; Configuration</a-->
14<a href="#views">&bull; Views/Dialogs</a>
15<a href="#assist">&bull; Content Assist</a>
16<a href="#refactor">&bull; Refactoring</a>
17<!--a href="#formatting">&bull; Formatting</a-->
18<a href="#debug">&bull; Run/Debug</a>
19<a href="#language">&bull; Language</a>
20<a href="#api">&bull; API</a>
21<a href="#compiler">&bull; Compiler</a>
22<a href="#otre">&bull; Runtime</a>
23<!--a href="#otequinox">&bull; OT/Equinox</a-->
24</div>
25<table cellpadding="10" cellspacing="0" width="100%">
26 <colgroup>
27 <col width="20%">
28 <col width="80%">
29 </colgroup>
30 <tbody>
31<!--
32 <tr><td colspan="2" id="NAME"><h2>HEADING</h2></td></tr>
33 <tr>
34 <td><p align="right"><b>DESC</b><br>
35 <span class="since">since&nbsp;0.7.1</span><br>
36 <a class="buglink" title="TITLE" href="https://bugs.eclipse.org/308029">308029</a></p></td>
37 <td><p>
38
39 </p>
40 <p><img alt="TEXT" src="../images/screenshots/NN07/.png"></p>
41 <p></p>
42 </td>
43 </tr>
44 <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">MyTeam</font> {
45}</pre></div></div>
46-->
47 <tr><td colspan="2" id="views"><h2>Views & Dialogs</h2></td></tr>
48 <tr>
49 <td><p align="right"><b>Traditional Hierarchy View</b><br>
50 <span class="since">since&nbsp;0.7.1</span><br>
51 <a class="buglink" title="[hierarchy] revive and adjust traditional type hierarchy for OT/J " href="https://bugs.eclipse.org/322898">322898</a></p></td>
52 <td><p>
53 The "traditional" hierarchy view is a mode of the Type Hierarchy View,
54 where starting from a given focus type both the tree of subclasses and the chain of superclass
55 is rendered in a single view. Due to the fact that roles may have multiple superclasses this
56 mode was disabled in the OTDT.
57 </p>
58 <p>
59 A new adaptation of the internal <code>TypeHierarchy</code> classes allows us to
60 linearize the set of superclasses wrt the focus class, i.e., superclasses are shown
61 in the order as seen from the focus class, which prioritizes implicit inheritance
62 over explicit inheritance.
63 </p>
64 <p>E.g., consider the following code:
65 <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> EcoSystem {
66 <code class="keyword">protected class</code> Project { }
67 <code class="keyword">protected class</code> IDEProject <code class="keyword">extends</code> Project { }
68}
69<code class="keyword">public team class</code> Eclipse <code class="keyword">extends</code> EcoSystem {
70 @Override
71 <code class="keyword">protected class</code> Project { }
72 @Override
73 <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 { }
74 <code class="keyword">protected class</code> CDT <code class="keyword">extends</code> IDEProject { }
75 <code class="keyword">protected class</code> JDT <code class="keyword">extends</code> IDEProject { }
76 <code class="keyword">protected class</code> OTDT <code class="keyword">extends</code> IDEProject { }
77}</pre></div></div></p>
78 <p>
79 which yields the following rendering:
80 </p>
81 <p><img alt="TEXT" src="../images/screenshots/NN07/othierarchy.png"></p>
82 <p></p>
83 </td>
84 </tr>
85 <tr><td colspan="2" id="assist"><h2>Content assist</h2></td></tr>
86 <tr>
87 <td><p align="right"><b>Adjust callin return</b><br>
88 <span class="since">since&nbsp;0.7.1</span><br>
89 <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>
90 <td><p>
91 Previously, when creating a callin method using completion, the role method designator would be created with
92 the exact same return type as the bound base method. However, for before and especially after callin bindings
93 this was misleading, because any value returned by the role method would be simply ignored.
94 </p>
95 <p>
96 In order to avoid confusing the user, method binding completion now works with the following changes:
97 <ul><li>Completion generally offers the option to replace the role method return type with <code class="keyword">void</code>:</li></ul>
98 </p>
99 <p><img alt="Return type options" src="../images/screenshots/NN07/CreateMethodBinding1.png"></p>
100 <p>
101 <ul><li>Still, the binding kind <code class="keyword">&lt;- after</code> can be selected without
102 selecting <code>void</code> as the return type:</li></ul>
103 </p>
104 <p><img alt="Selecting after" src="../images/screenshots/NN07/CreateMethodBinding2.png"></p>
105 <p>
106 <ul><li>However, when the binding kind is confirmed by hitting enter, the return type is
107 automatically adjusted to <code>void</code>:</li></ul>
108 </p>
109 <p><img alt="Created method binding" src="../images/screenshots/NN07/CreateMethodBinding3.png"></p>
110 </td>
111 </tr>
112
113 <tr><td colspan="2" id="refactor"><h2>Refactoring</h2></td></tr>
114 <tr>
115 <td><p align="right"><b>Change Signature Refacoring</b><br>
116 <span class="since">since&nbsp;0.7.1</span><br>
117 <a class="buglink" title="[refactoring] adapt &quot;change signature&quot; refactoring" href="https://bugs.eclipse.org/311879">311879</a></p></td>
118 <td><p>
119 The Change Signature refactoring has been adapted to work for OT/J sources, too.
120 Now, if the signature of a method is refactored that is referenced from a callout or callin method binding,
121 the binding is adjusted accordingly. The refactoring tries to absorb all changes within the binding,
122 like adding a parameter mapping to absorb a re-ordering of arguments.
123 If a change needs to be propagated through the binding (i.e., it cannot be fully absorbed)
124 the refactoring will inform the user by issuing a warning.
125 </p>
126 <p>
127 Here is a preview of a refactoring, where the signature of <code>bm</code> has been changed by
128 (a) adding an argument <code>String str</code> and (b) moving argument <code>i</code> to the end:
129 </p>
130 <p><a href="../images/screenshots/NN07/ChangeSignature2.png"><img alt="Change Signature preview" src="../images/screenshots/NN07/ChangeSignature2.png" width=800"></a></p>
131 <p></p>
132 </td>
133 </tr>
134 <tr><td colspan="2" id="debug"><h2>Run / Debug</h2></td></tr>
135 <tr>
136 <td><p align="right"><b>Stack frame beautifying</b><br>
137 <span class="since">since&nbsp;0.7.1</span><br>
138 <a class="buglink" title="[debug] private role method bridge is interpreted as callin wrapper" href="https://bugs.eclipse.org/318993">318993</a></p></td>
139 <td><p>
140 The Debug View now knows about more kinds of synthetic methods generated by the OT/J compiler.
141 All these methods are beautified by replacing the internal name with a human readable explanation
142 and de-emphasizing these stack frames using a lighter color.
143 </p>
144 <p><img alt="Beautified stack frames" src="../images/screenshots/NN07/MoreDebugColoring.png"></p>
145 <p>The shaded stackframes in the above screenshot signify (from top to bottom):
146 <ul>
147 <li>Access to a private base method applying decapsulation</li>
148 <li>Invocation of a synthetic method for initializing the fields of a role</li>
149 <li>Indirect invocation of a role's constructor (late binding of the role class)</li>
150 </ul>
151 </p>
152 </td>
153 </tr>
154 <tr><td colspan="2" id="api"><h2>API</h2></td></tr>
155 <tr>
156 <td><p align="right"><b>isActive() is now final</b><br>
157 <span class="since">since&nbsp;0.7.1</span><br>
158 <a class="buglink" title="[otre] overriding Team.isActive() may cause deadlock" href="https://bugs.eclipse.org/324537">324537</a></p></td>
159 <td><p>
160 Previously, methods <code>Team.isActive()</code> and <code>Team.isActive(Thread)</code> could be overridden in sub-teams,
161 but if an overriding version did not return immediately it could cause a deadlock,
162 because the infrastructure invokes these methods from synchronized blocks.
163 </p>
164 <p>In order to avoid this risk of deadlocks, both methods have been changed to <code class="keyword">final</code>.
165 </p>
166 </td>
167 </tr> <tr><td colspan="2" id="language"><h2>Language</h2></td></tr>
168 <tr>
169 <td><p align="right"><b>Internal State Pattern</b><br>
170 <span class="since">since&nbsp;0.7.1</span><br>
171 <a class="buglink" title="[otjld] [compiler] Support the &quot;Internal Role&quot; pattern" href="https://bugs.eclipse.org/318815">318815</a></p></td>
172 <td><p>
173 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>
174 disallowed to bind a role to its enclosing team. This rule was found to be overly cautious and prohibitive.
175 By essentially removing this restriction (except for a few corner cases), the following pattern is
176 now possible:
177 <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">MyTeam</font> {
178 <code class="keyword">public void</code> service() { ... }
179 <code class="keyword">enum</code> Mode {NORMAL, MAINTENANCE, BOOT_IN_PROGRESS};
180 Mode mode;
181 <code class="keyword">protected class</code> MaintenanceMode <code class="keyword">playedBy</code> <font color="blue">MyTeam</font>
182 <code class="keyword">base when</code> (MyTeam.this.mode == Mode.MAINTENANCE) {
183 mainenanceNotice <code class="keyword"><- replace</code> service;
184 ...
185 }
186 <code class="keyword">protected class</code> BootingMode <code class="keyword">playedBy</code> <font color="blue">MyTeam</font>
187 <code class="keyword">base when</code> (MyTeam.this.mode == Mode.BOOT_IN_PROGRESS) { ... }
188}</pre></div></div>
189 The point is here that both roles adapt their enclosing team <code style="color:blue;">MyTeam</code> - thus providing a very well
190 localized implementation for different states/modes of the team.
191 </p>
192 <p>Note, that the above code will cause the compiler to signal a warning: "Base class MyTeam is an enclosing type of MaintenanceMode ...",
193 which can be silenced by <code>@SuppressWarnings("baseclasscycle")</code>
194 </p>
195 <p>See also the <a href="http://wiki.eclipse.org/index.php?title=OTPattern/InnerState">Internal State Pattern</a> in the wiki.</p>
196 </td>
197 </tr>
198 <tr><td colspan="2" id="compiler"><h2>Compiler</h2></td></tr>
199 <tr>
200 <td><p align="right"><b>playedBy Interface</b><br>
201 <span class="since">since&nbsp;0.7.1</span><br>
202 <a class="buglink" title="[compiler][otre] support for role-binding to interfaces" href="https://bugs.eclipse.org/321440">321440</a></p></td>
203 <td><p>
204 The OTJLD never said that the type after <code class="keyword">playedBy</code> definitely must be a class,
205 but contained a note mentioning a compiler limitation in this regard.
206 This limitation has been weakened so that now a role can also be bound to an interface.
207 Only, in such situations the role cannot declare callin method bindings (callout is not a problem).
208 It is of course possible to define sub-roles that are bound to classes implementing the base interface
209 such that those sub-roles can declare callin bindings, too.
210 </p>
211 </td>
212 </tr>
213
214 <tr><td colspan="2" id="otre"><h2>Object Teams Runtime Environment</h2></td></tr>
215 <tr>
216 <td><p align="right"><b>Packaged as a bundle</b><br>
217 <span class="since">since&nbsp;0.7.1</span><br>
218 <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>
219 <td><p>
220 Packaging and deployment of the OTRE has changed from a plain Jar to a regular OSGi bundle called <code>org.eclipse.objectteams.runtime</code>.
221 Yet, this bundle Jar can still be used outside any OSGi context.
222 While this simplifies several build and deploy issues, the change should be mostly transparent for users.
223 Only when compiling/running OT/J applications outside Eclipse script will need adjusting to refer
224 to the bundle Jar instead of the old <code>otre.jar</code>.
225 </p>
226 </td>
227 </tr>
228
229</table>
230</body>