| <!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 (Incubation) - New and Noteworthy</title> |
| </head> |
| <body> |
| <h1>OTDT 0.7 (Incubation) - New and Noteworthy</h1> |
| <div class="navigation"><i>Changes since the 1.4.0 Release from objectteams.org</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="#formatting">• Formatting</a--> |
| <a href="#debug">• Run/Debug</a> |
| <a href="#language">• Language</a> |
| <a href="#compiler">• Compiler</a> |
| <a href="#api">• API</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="configuration"><h2>Configuration</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Migration of old OT-projects</b><br> |
| <span class="since">since 0.7 M2</span><br> |
| <a class="buglink" title=" Automatically migrate OT-projects to new namespace" href="https://bugs.eclipse.org/308029">308029</a></p></td> |
| <td><p>When opening Object Teams project that have been created by a previous OTDT version (<em>1.x from objectteams.org</em>) |
| some internal data need to be migrated to the new <code>org.eclipse.objectteams</code> prefix, notably: |
| <dl> |
| <dt><b><code>.project</code></b></dt><dd>project nature and builder</dd> |
| <dt><b><code>META-INF/MANIFEST.MF</code></b></dt><dd>dependency on OT/Equinox plug-in</dd> |
| <dt><b><code>plugin.xml</code></b></dt><dd><code>aspectBinding</code> declarations</dd> |
| </dl> |
| Diagnostics have been added to signal these issues as errors: |
| </p> |
| <p><img alt="New project configuration errors" src="../images/screenshots/NN07/ProjectErrors.png"></p> |
| <p>Quick fixes have been implemented for performing the necessary changes, like:</p> |
| <p><img alt="Quickfix for migrating to the new namespace" src="../images/screenshots/NN07/ProjectMigration-QuickFix.png"></p> |
| </td> |
| </tr> |
| <tr> |
| <td><p align="right"><b>Use compiler options for plug-in export</b><br> |
| <span class="since">since 0.7 M4</span><br> |
| <a class="buglink" title="[compiler] Interactive export of OT-plugin does not use compiler preferences" href="https://bugs.eclipse.org/316553">316553</a></p></td> |
| <td><p>When interactively exporting an OT plug-in (using the corresponding export wizard) |
| it is now possible to tell the builder to use the OT/J compiler options from the project settings. |
| In order to do so simply include the following directive in your <code>build.properties</code> file: |
| <div class="listbox"><div class="listing">javacProjectSettings=true</div></div> |
| This is a standard PDE setting which now applies to OT-specific compiler options, too. |
| </p> |
| </td> |
| </tr> |
| <tr><td colspan="2" id="views"><h2>Views & Dialogs</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Binding to callout-method via binding editor</b><br> |
| <span class="since">since 0.7 M4</span><br> |
| <a class="buglink" title="[binding-editor] Binding editor does not show base methods which are defined by callout" href="https://bugs.eclipse.org/315520">315520</a></p></td> |
| <td><p>The binding editor now also shows base methods that are defined by a callout binding (relevant in role-of-role situations): |
| </p> |
| <p><img alt="Binding to a callout-defined method" src="../images/screenshots/NN07/BindingEditorBaseCallout.png"></p> |
| <p>Also a new icon for the "New method()" entry was introduced. |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td><p align="right"><b>Create callout-to-field via binding editor</b><br> |
| <span class="since">since 0.7 M4</span><br> |
| <a class="buglink" title="[binding-editor] Creating callout-to-field via binding editor" href="https://bugs.eclipse.org/315465">315465</a></p></td> |
| <td><p>The binding editor now supports the creation of callout-to-field bindings. Simply select (a) "New method()", (b) "->", (c) <em>a base field</em>: |
| </p> |
| <p><img alt="Creating a callout-to-field" src="../images/screenshots/NN07/BindingEditorCalloutToField1.png"></p> |
| <p>As the result you will see two new callout bindings (<code>get</code> and <code>set</code>) to the same <img valign="middle" src="../images/otdt/field_default_obj.gif"/> field. |
| If only a getter or only a setter was intended simply remove the undesired binding. |
| </p> |
| <p><img alt="Created a two callout-to-field bindings" src="../images/screenshots/NN07/BindingEditorCalloutToField2.png"></p> |
| </td> |
| </tr> |
| <tr> |
| <td><p align="right"><b>"Go to Language Definition" without using Problems view</b><br> |
| <span class="since">since 0.7</span><br> |
| <a class="buglink" title=" "Go to Language Definition" should be available along more paths" href="https://bugs.eclipse.org/318071">318071</a></p></td> |
| <td><p>The action <span class="ui">Go to Language Definition</span>, which previously could only be invoked from the <b>Problems</b> view, |
| can now be invoked in two more ways: |
| </p> |
| <p><u>Using the context menu on the problem marker in the editor's left gutter:</u> |
| <img alt="Go to Language Definition from left gutter" src="../images/screenshots/NN07/GoToLangDefGutter.png"></p> |
| <p><u>Using a new button on the problem hover:</u> |
| <img alt="Go to Language Definition from problem hover" src="../images/screenshots/NN07/GoToLangDefHover.png"></p> |
| </td> |
| </tr> |
| <tr><td colspan="2" id="assist"><h2>Content assist</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Create "precedence after"</b><br> |
| <span class="since">since 0.7 M3</span><br> |
| <a class="buglink" title="[dom] [assist] add support for "precedence after" in DOM and quickfix" href="https://bugs.eclipse.org/313804">313804</a></p></td> |
| <td><p>When a quickfix is used for creating a <code class="keyword">precedence</code> declaration that affects <code class="keyword">after</code> callin bindings, |
| the quickfix automatically creates the declaration as <code class="keyword">precedence after</code> |
| (see also the change of <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s4.html#s4.8.a">OTJLD §4.8(a)</a> described <a href="#language">here</a>). |
| </p> |
| <p><img alt="Add "precedence after" quickfix" src="../images/screenshots/NN07/AddPrecedenceAfter-QuickFix.png"></p> |
| </td> |
| </tr> |
| <tr> |
| <td><p align="right"><b>Add/remove signatures of method bindings</b><br> |
| <span class="since">since 0.7 M3</span><br> |
| <a class="buglink" title="[assist] Quick assist for adding/removing signatures in method bindings" href="https://bugs.eclipse.org/310923">310923</a></p></td> |
| </p> |
| </td> |
| <td><p> |
| New quick assists support converting between method bindings with and without signatures. |
| When, e.g., creating a method binding by means of completion, signatures are automatically included. |
| In that case a quick assist can be used to convert that verbose binding into its shorter versions without signatures: |
| </p> |
| <p><img alt="Remove signatures quick assist" src="../images/screenshots/NN07/RemoveSignatures-QuickAssist.png"></p> |
| <p> |
| Conversely, a method binding without signatures can be converted to the long form: |
| </p> |
| <p><img alt="Add signatures quick assist" src="../images/screenshots/NN07/AddSignatures-QuickAssist.png"></p> |
| The quick assist for removing signatures is disabled if argument names are used either in a parameter mapping or a guard predicate. |
| </td> |
| </tr> |
| <tr> |
| <td><p align="right"><b>Proposal to override inherited role</b><br> |
| <span class="since">since 0.7</span><br> |
| <a class="buglink" title="[assist] completion should offer to materialize phantom roles" href="https://bugs.eclipse.org/302827">302827</a></p></td> |
| </p> |
| </td> |
| <td><p> |
| A new kind of completion proposal has been added for overriding a role class inherited from the super team: |
| </p> |
| <p><img alt="Override role completion proposal" src="../images/screenshots/NN07/OverrideRole.png"></p> |
| Invoking this proposal will insert the following code: |
| <div class="listbox"><div class="listing"><pre> <code class="annotation">@Override</code> |
| <code class="keyword">protected class</code> Subscriber { |
| }</pre></div></div> |
| The new role implicitly inherits all properties from the inherited role <code>Bonus.Subscriber</code> (<a class="otjldlink" href="http://www.objectteams.org/def/1.3/s1.html#s1.3.1.c">OTJLD §1.3.1(c)</a>) |
| and may override methods and/or refine <code class="keyword">extends</code> (<a class="otjldlink" href="http://www.objectteams.org/def/1.3/s1.html#s1.3.2.b">OTJLD §1.3.2(b)</a>) |
| and <code class="keyword">playedBy</code> (<a class="otjldlink" href="http://www.objectteams.org/def/1.3/s2.html#s2.1.c">OTJLD §2.1(c)</a>) relationships. |
| </td> |
| </tr> |
| <tr><td colspan="2" id="debug"><h2>Run / Debug</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Fade out JMangler</b><br> |
| <span class="since">since 0.7 M1</span><br> |
| <a class="buglink" title="Remove all traces of JMangler" href="https://bugs.eclipse.org/302976">302976</a></p></td> |
| <td><p>Previous versions of the OTDT featured two alternative strategies for launching OT/J applications: JMangler and JPLIS. |
| During the move to Eclipse.org, the support for JMangler was discontinued because the JPLIS launch mode has long matured |
| and bringing JMangler to Eclipse.org would have caused additional license issues. |
| </p> |
| For users this means that launch configurations have been simplified as the checkbox <span class="ui">Java 5 JPLIS Launching</span> |
| has been removed, leaving only the <span class="ui">Enable OTRE</span> checkbox: |
| <p> |
| <img alt="JRE Tab with OTRE configuration" src="../images/screenshots/NN07/RunJRE-OTRE.png"> |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td><p align="right"><b>Show "_OT$base" field</b><br> |
| <span class="since">since 0.7</span><br> |
| <a class="buglink" title="variables view should not hide _OT$base reference" href="https://bugs.eclipse.org/316907">316907</a></p></td> |
| <td> |
| <p> |
| The <b>Variables</b> view has the option to filter any synthetic variables generated by the OT/J compiler (<span class="ui">Java > Show OT/J internal variables</span>). |
| However, the synthetic <code><b>_OT$base</b></code> field is special, as it holds the essential information |
| to which base instance a given role instance is linked. The <code><b>_OT$base</b></code> field is |
| now shown in the <b>Variables</b> view independent of the current filter setting: |
| </p> |
| <p> |
| <img alt="Variables view showing _OT$base" src="../images/screenshots/NN07/Variables_Base.png"> |
| </p> |
| <p> |
| Also note the similarity to the synthetic field <code><b>this$0</b></code> which refers to the |
| enclosing (team) instance. |
| </p> |
| </td> |
| </tr> |
| <tr><td colspan="2" id="api"><h2>API</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Team serialization</b><br> |
| <span class="since">since 0.7 M1</span><br> |
| <a class="buglink" title="[otre] [compiler] Support basic serialization of teams and roles" href="https://bugs.eclipse.org/304728">304728</a><br> |
| <a class="buglink" title="[otre] Selectively consider activation state during team serialization" href="https://bugs.eclipse.org/304729">304729</a></p></td> |
| <td><p>Teams and roles can now be serialized if they declare to implement <code>java.io.Serializable</code>. |
| By default serialization does not handle any generated fields by which roles, teams and bases are linked (role caches, base-to-role backpointers). |
| Team classes wishing to persist their roles can now do so by implementing a normal pair of <code>writeObject</code> / <code>readObject</code> methods. |
| New API has been added to <code>org.objectteams.Team</code> for initializing a team after restoring from its persisted representation: |
| <dl><dt><b><code>void restore()</code></b></dt> |
| <dd>Serializable teams must invoke this method once from their readObject() method in order to re-initialize internal data structures.</dd> |
| <dt><b><code>void restoreRole(Class<?> clazz, Object role)</code></b></dt> |
| <dd>Serializable teams must invoke this method from their readObject() method for each role that has been retrieved and shall be re-registered for this team.</dd> |
| </dl> |
| </p> |
| <p> |
| Additionally, new API has been added for persisting / restoring the global <b>activation state</b> of a team: |
| <dl><dt><b><code>void writeGlobalActivationState(ObjectOutputStream out) throws IOException</code></b></dt> |
| <dd>If a serializable team wishes to persist its global activation status it must |
| call this method from its <code>writeObject()</code> method and correspondingly call |
| <code>readGlobalActivationState(ObjectInputStream)</code> from its <code>readObject()</code>.</dd> |
| <dt><b><code>void readGlobalActivationState(ObjectInputStream in) throws IOException</code></b></dt> |
| <dd>If a serializable team wishes to persist its global activation status it must |
| call this method from its <code>readObject()</code> method and correspondingly call |
| <code>writeGlobalActivationState(ObjectOutputStream)</code> from its <code>writeObject()</code>. |
| If a team is restored that was globally active when serialized, it will be activated |
| correspondingly during deserialization when this method is called.</dd> |
| </dl> |
| </p> |
| </td></tr> |
| <tr><td colspan="2" id="language"><h2>Language</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Semantics of precedence</b><br> |
| <span class="since">since 0.7 M3</span><br> |
| <a class="buglink" title="[compiler] [otre] implement change in semantics of precedence declaration" href="https://bugs.eclipse.org/310917">310917</a></p></td> |
| <td><p>The semantics of how exactly a <code class="keyword">precedence</code> declaration should affect <code class="keyword">after</code> callin bindings |
| was underspecified in the OTJLD and the OTRE implemented unintended semantics. |
| </p> |
| <p> |
| To fix these issues <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s4.html#s4.8.a">OTJLD §4.8(a)</a> has been extended to |
| <ul> |
| <li>specify how a precedence declaration affects the execution order:<br> |
| for <code class="keyword">before</code> and <code class="keyword">replace</code> bindings |
| a high precedence (i.e., being listed early) means early triggering, |
| but for <code class="keyword">after</code> bindings a high precedence means <b>late</b> triggering. |
| <li>require precedence declarations which affect after bindings to make this fact explicit by using |
| <code class="keyword">precedence after</code> instead of just <code class="keyword">precedence</code>. |
| </ul> |
| </p> |
| <p> |
| The new semantics have been implemented in the OTRE accordingly (see also the corresponding <a href="#assist">quickfix</a>). |
| </p> |
| </td></tr> |
| <tr> |
| <td><p align="right"><b>Merging precedence of different kinds</b><br> |
| <span class="since">since 0.7 M4</span><br> |
| <a class="buglink" title="[otjld] [compiler] Merging of class-based and binding-based precedences is underspecified" href="https://bugs.eclipse.org/316148">316148</a></p></td> |
| <td><p>The semantics of how exactly <code class="keyword">precedence</code> declarations of different kinds (class-based vs. binding-based) would be merged was underspecified. |
| Consider the following precedence declarations: |
| <div class="listbox"><div class="listing"><pre> <code class="keyword">public team class</code> MyTeam { |
| <code class="keyword">precedence</code> MyRoleB.bl1, MyRoleA.bl3; |
| <code class="keyword">protected class</code> MyRoleB <code class="keyword">playedBy</code> MyBase { |
| <code class="keyword">precedence</code> bl1, bl2; |
| ... |
| } |
| ... |
| }</pre></div></div> |
| Here the C3 algorithm could produce two different orders (<code>bl1, bl3, bl2</code>) or (<code>bl1, bl2, bl3</code>) (both order are consistent with |
| the input lists). Which order is chosen depends on in which order the two precedence lists are passed into the algorithm. |
| </p> |
| <p> |
| To fix these issues <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s4.html#s4.8.d">OTJLD §4.8(d)</a> has been extended to |
| specify that more deeply nested precedence declarations have higher priority than outer precedence declarations. |
| So in the above example the final order of callin bindings will be: (<code>bl1, bl2, bl3</code>), because <code>bl2</code> is mentioned |
| in the inner precedence declaration and thus comes before <code>bl3</code> which is mentioned only in the outer precedence declaration. |
| </p> |
| <p> |
| The compiler has been updated accordingly. |
| </p> |
| </td></tr> |
| <tr> |
| <td><p align="right"><b>Callin in role with binding ambiguity</b><br> |
| <span class="since">since 0.7 M4</span><br> |
| <a class="buglink" title="[otjld] Method bindings in role with binding ambiguity?" href="https://bugs.eclipse.org/316200">316200</a></p></td> |
| <td><p>Previously, callin bindings in a particular situation would be flaged as illegal showing the following message: |
| <div class="hover" style="margin:5px;"> |
| Callin mapping not allowed here, because lifting to role TX.RY is |
| not possible due to a reported binding ambiguity (OTJLD 4.1(b)). |
| </div> |
| A closer analysis revealed that despite lifting ambituity the callin <em>could</em> succeed in lifting if |
| <ol> |
| <li>a suitable role is already found in the cache (perhaps created explicitly), <em>or</em></li> |
| <li>the actual base object has a type for which a specific role without binding ambiguity exists.</li> |
| </ol> |
| </p> |
| <p> |
| In order to support even such corner cases, |
| <ul> |
| <li>Sections <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s2.html#s2.3.4.b">OTJLD §2.3.4(b)</a> and |
| <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s4.html#s4.1.b">OTJLD §4.1(b)</a> have been extended</li> |
| <li>The compiler message has been rephrased in a weaker way.</li> |
| <li>A new warning token <code>"def-bind-ambiguity"</code> (definite binding ambiguity) has been introduced |
| which can be used in a <code>@SuppressWarnings</code> annotation in order to silence that error.<br> |
| Additionally, option <code class="ui">Suppress optional errors with '@SuppressWarnings'</code> must be enabled in the |
| Java Compiler preferences.</li> |
| <li>The generated lift method has been changed to service case (1) above.</li> |
| </ul> |
| </p> |
| </td></tr> |
| <tr><td colspan="2" id="compiler"><h2>Compiler</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Warn about unused result</b><br> |
| <span class="since">since 0.7 M2</span><br> |
| <a class="buglink" title="[compiler] should warn when after callin ignores return value of its role method " href="https://bugs.eclipse.org/310621">310621</a></p></td> |
| <td><p>In an <code class="keyword">after</code> callin binding where both methods declare a return type, users might expect the role method's result to be passed down |
| to the original caller. However, <code class="keyword">after</code> callin bindings may only <em>look</em> at the base method's result but never <em>replace</em> it with its own result. |
| In order to alert users of this issue, a new warning has been introduced. |
| </p> |
| <p style="margin-bottom:0px;"> |
| So this binding: |
| <div class="listbox"><div class="listing"><code><code class="keyword">int</code> foo() <code class="keyword"><- after int</code> bar();</code></div></div> |
| Will yield this warning: |
| <div class="hover" style="margin:5px;"> |
| Callin after binding cannot return a value to the base caller, role method return value of type int will be ignored (OTJLD 4.4(a)) |
| </div> |
| By contrast, the following declaration does not trigger the warning: |
| <div class="listbox"><div class="listing"><code><code class="keyword">void</code> foo() <code class="keyword"><- after int</code> bar();</code></div></div> |
| If desired the warning can be suppressed using the token <code>"ignoredresult"</code> |
| </p> |
| </td></tr> |
| <tr><td colspan="2" id="otequinox"><h2>OT/Equinox</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Aspect bindings for nested teams</b><br> |
| <span class="since">since 0.7 M2</span><br> |
| <a class="buglink" title="nested teams must be specified using their internal name with "$__OT__"" href="https://bugs.eclipse.org/311109">311109</a><br> |
| <a class="buglink" title="Adding InnerTeam for aspectBinding with the PDE Extension Editor results in wrong code" href="https://bugs.eclipse.org/311206">311206</a></p></td> |
| <td><p>Previously, aspect bindings for nested teams could only be specified by using the internal name involving an ugly "$__OT__" prefix. |
| Specifically, when selecting a nested team using the <span class="ui">Browse</span> button the resulting declaration would not work. |
| </p> |
| <p> |
| To fix these issues support has been added to OT/Equinox for interpreting the source and binary names of nested teams without the internal prefix, |
| i.e., both |
| <ul> |
| <li><code>some.pack.OuterTeam.InnerTeam</code> and</li> |
| <li><code>some.pack.OuterTeam$InnerTeam</code></li> |
| </ul> |
| will be understood by the OT/Equinox runtime. |
| </p> |
| </td></tr> |
| <tr> |
| <td><p align="right"><b>Extension point for lifting participant</b><br> |
| <span class="since">since 0.7</span><br> |
| <a class="buglink" title="Extension point for a lifting participant" href="https://bugs.eclipse.org/311081">311081</a></p></td> |
| <td><p>The <a title="OTDT 1.4 New & Noteworthy" href="http://www.objectteams.org/distrib/new_in_1.4.html#runtime">recently introduced</a> |
| concept of a lifting participant is now supported also within OT/Equinox. |
| This is done using the new extension point <code>org.eclipse.objectteams.otequinox.liftingParticipant</code>. |
| In any application at most one extension to this extension point is allowed. |
| The extension must provide a class implementing <code>org.objectteams.ILiftingParticipant</code>. |
| </p> |
| </td></tr> |
| <tr><td colspan="2" id="otre"><h2>Object Teams Runtime Environment</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Detect all system threads</b><br> |
| <span class="since">since 0.7</span><br> |
| <a class="buglink" title="[otre] OTRE doesn't know about all threads" href="https://bugs.eclipse.org/316696">316696</a></p></td> |
| <td><p>It was a long outstanding issue that per-thread (de)activation of teams could not correctly handle all system threads that |
| are created before entering the <code>main</code> function. |
| Only for the AWT-Event-Thread an incomplete workaround was implemented, which could print the following warning at runtime: |
| <pre style="color:red;">Warning: Deactivation for the AWT-Event-Thread is not effective right now!</pre> |
| This problem could be resolved and the workaround is no longer used. |
| </p> |
| </td></tr> |
| </table> |
| </body> |
