Bug 349242 - [help] split otdt.ui.help plug-in
- this shall be the code-part of the plug-in.
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/.classpath b/plugins/org.eclipse.objectteams.otdt.ui.help/.classpath
new file mode 100644
index 0000000..9b7e6c5
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/.classpath
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<classpath>
+ <classpathentry kind="src" path="src"/>
+ <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
+ <classpathentry kind="con" path="OTRE"/>
+ <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
+ <classpathentry kind="output" path="bin"/>
+</classpath>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/.cvsignore b/plugins/org.eclipse.objectteams.otdt.ui.help/.cvsignore
new file mode 100644
index 0000000..ba077a4
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/.cvsignore
@@ -0,0 +1 @@
+bin
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/.project b/plugins/org.eclipse.objectteams.otdt.ui.help/.project
new file mode 100644
index 0000000..15612ac
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/.project
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<projectDescription>
+ <name>org.eclipse.objectteams.otdt.ui.help</name>
+ <comment></comment>
+ <projects>
+ </projects>
+ <buildSpec>
+ <buildCommand>
+ <name>org.eclipse.objectteams.otdt.builder.OTJBuilder</name>
+ <arguments>
+ </arguments>
+ </buildCommand>
+ <buildCommand>
+ <name>org.eclipse.pde.ManifestBuilder</name>
+ <arguments>
+ </arguments>
+ </buildCommand>
+ <buildCommand>
+ <name>org.eclipse.pde.SchemaBuilder</name>
+ <arguments>
+ </arguments>
+ </buildCommand>
+ </buildSpec>
+ <natures>
+ <nature>org.eclipse.pde.PluginNature</nature>
+ <nature>org.eclipse.jdt.core.javanature</nature>
+ <nature>org.eclipse.objectteams.otdt.OTJavaNature</nature>
+ </natures>
+</projectDescription>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/.settings/org.eclipse.jdt.core.prefs b/plugins/org.eclipse.objectteams.otdt.ui.help/.settings/org.eclipse.jdt.core.prefs
new file mode 100644
index 0000000..f8f1ac0
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/.settings/org.eclipse.jdt.core.prefs
@@ -0,0 +1,7 @@
+#Tue Sep 18 18:21:22 CEST 2007
+eclipse.preferences.version=1
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
+org.eclipse.jdt.core.compiler.compliance=1.5
+org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.source=1.5
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/META-INF/MANIFEST.MF b/plugins/org.eclipse.objectteams.otdt.ui.help/META-INF/MANIFEST.MF
new file mode 100644
index 0000000..75e5312
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/META-INF/MANIFEST.MF
@@ -0,0 +1,28 @@
+Manifest-Version: 1.0
+Bundle-ManifestVersion: 2
+Bundle-Name: %pluginName
+Bundle-SymbolicName: org.eclipse.objectteams.otdt.ui.help;singleton:=true
+Bundle-Version: 2.0.0.qualifier
+Bundle-Activator: org.eclipse.objectteams.otdt.ui.help.OTHelpPlugin
+Bundle-Vendor: %providerName
+Bundle-Localization: plugin
+Export-Package: org.eclipse.objectteams.otdt.internal.ui.help.actions;x-internal:=true,
+ org.eclipse.objectteams.otdt.internal.ui.help.views;x-internal:=true,
+ org.eclipse.objectteams.otdt.ui.help
+Require-Bundle: org.eclipse.ui;bundle-version="[3.7.0,4.0.0)",
+ org.eclipse.core.runtime;bundle-version="[3.7.0,4.0.0)",
+ org.eclipse.ui.intro;bundle-version="[3.4.100,4.0.0)",
+ org.eclipse.ui.cheatsheets;bundle-version="[3.4.100,4.0.0)",
+ org.eclipse.help;bundle-version="[3.5.100,4.0.0)",
+ org.eclipse.core.resources;bundle-version="[3.7.0,4.0.0)",
+ org.eclipse.ui.ide;bundle-version="[3.7.0,4.0.0)",
+ org.eclipse.ui.browser;bundle-version="[3.3.100,4.0.0)",
+ org.eclipse.ui.workbench.texteditor;bundle-version="[3.7.0,4.0.0)",
+ org.eclipse.jface.text;bundle-version="[3.7.0,4.0.0)",
+ org.eclipse.jdt.ui;bundle-version="[3.7.0,4.0.0)",
+ org.eclipse.jdt.core;bundle-version="[3.7.0.v_OTDT_r200,4.0.0)",
+ org.eclipse.objectteams.otdt.ui;bundle-version="[2.0.0,3.0.0)",
+ org.eclipse.objectteams.otequinox;bundle-version="[2.0.0,3.0.0)"
+Bundle-RequiredExecutionEnvironment: J2SE-1.5
+Bundle-ActivationPolicy: lazy
+Bundle-Classpath: .
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/about.html b/plugins/org.eclipse.objectteams.otdt.ui.help/about.html
new file mode 100644
index 0000000..66ef6f6
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/about.html
@@ -0,0 +1,28 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+<title>About</title>
+</head>
+<body lang="EN-US">
+<h2>About This Content</h2>
+
+<p>June 15, 2010</p>
+<h3>License</h3>
+
+<p>The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise
+indicated below, the Content is provided to you under the terms and conditions of the
+Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available
+at <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>.
+For purposes of the EPL, "Program" will mean the Content.</p>
+
+<p>If you did not receive this Content directly from the Eclipse Foundation, the Content is
+being redistributed by another party ("Redistributor") and different terms and conditions may
+apply to your use of any object code in the Content. Check the Redistributor's license that was
+provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise
+indicated below, the terms and conditions of the EPL still apply to any source code in the Content
+and such source code may be obtained at <a href="http://www.eclipse.org">http://www.eclipse.org</a>.</p>
+
+</body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/book.css b/plugins/org.eclipse.objectteams.otdt.ui.help/book.css
new file mode 100644
index 0000000..59c346d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/book.css
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/build.properties b/plugins/org.eclipse.objectteams.otdt.ui.help/build.properties
new file mode 100644
index 0000000..f85821a
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/build.properties
@@ -0,0 +1,39 @@
+########################################################################
+# This file is part of "Object Teams Development Tooling"-Software
+#
+# Copyright 2004, 2010 Fraunhofer Gesellschaft, Munich, Germany,
+# for its Fraunhofer Institute and Computer Architecture and Software
+# Technology (FIRST), Berlin, Germany and Technical University Berlin,
+# Germany.
+#
+# All rights reserved. This program and the accompanying materials
+# are made available under the terms of the Eclipse Public License v1.0
+# which accompanies this distribution, and is available at
+# http://www.eclipse.org/legal/epl-v10.html
+# $Id$
+#
+# Please visit http://www.eclipse.org/objectteams for updates and contact.
+#
+# Contributors:
+# Fraunhofer FIRST - Initial API and implementation
+# Technical University Berlin - Initial API and implementation
+########################################################################
+customBuildCallbacks=customBuildCallbacks.xml
+source.. = src/
+output.. = bin/
+bin.includes = plugin.xml,\
+ META-INF/,\
+ .,\
+ cheatsheets/,\
+ css/,\
+ guide/,\
+ icons/,\
+ images/,\
+ intro/,\
+ plugin.properties,\
+ ot.html,\
+ reference/,\
+ book.css,\
+ schema.css,\
+ about.html
+
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/buildDoc.xml b/plugins/org.eclipse.objectteams.otdt.ui.help/buildDoc.xml
new file mode 100644
index 0000000..94ac394
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/buildDoc.xml
@@ -0,0 +1,109 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project name="OTDT Doc Isv Build" default="all" basedir="." >
+
+ <target name="init">
+ <available file="${basedir}/index" property="index.present"/>
+ </target>
+
+ <target name="all" depends="init" unless="index.present">
+ <antcall target="convertSchemaToHtml" />
+ <!--antcall target="generateJavadoc" /-->
+ <!--antcall target="build.index" /-->
+ <!--antcall target="createDocZip" /-->
+ </target>
+
+
+ <target name="build.index" description="Builds search index for the plug-in: org.eclipse.objectteams.otdt.ui.help" if="eclipse.running">
+ <help.buildHelpIndex manifest="${basedir}/plugin.xml" destination="${basedir}"/>
+ </target>
+
+ <target name="convertSchemaToHtml" if="eclipse.running">
+ <mkdir dir="reference"/>
+ <property name="dest" value="reference/extension-points" />
+ <record name="${basedir}/otdtconvert.txt" action="start"/>
+ <echo message="recording schema conversion ... in ${basedir}/otdtconvert.txt"/>
+
+ <pde.convertSchemaToHTML
+ manifest="../org.eclipse.objectteams.otequinox/plugin.xml"
+ destination="${dest}"/>
+ <!--cssURL="file:../../css/schema.css" broken see https://bugs.eclipse.org/300826 -->
+
+ <echo message="done recording schema conversion in ${basedir}/otdtconvert.txt"/>
+
+ <record name="${basedir}/otdtconvert.txt" action="stop"/>
+ </target>
+
+ <target name="getJavadocPath">
+ <available file="${java.home}/../bin/javadoc.exe" property="javadoc" value="${java.home}/../bin/javadoc.exe"/>
+ <available file="${java.home}/../bin/javadoc" property="javadoc" value="${java.home}/../bin/javadoc" />
+ </target>
+
+
+ <target name="generateJavadoc" depends="getJavadocPath" if="javadoc">
+
+ <!--HACK to ensure the platform doc is built before JDT - call to this script should be moved to build.jars target-->
+ <available file="../org.eclipse.platform.doc.isv/index" property="platform.index.present"/>
+ <antcall target="buildPlatformDoc" />
+
+ <property name="optionsFile" value="jdtOptions.tmp.txt" />
+ <copy file="jdtOptions.txt" tofile="${optionsFile}" overwrite="true" />
+
+ <condition property="argsListDelimiter" value=":">
+ <os family="unix" />
+ </condition>
+ <condition property="argsListDelimiter" value=";">
+ <os family="windows" />
+ </condition>
+
+ <replaceregexp file="${basedir}/${optionsFile}" flags="g" match="(\r\n?|\n);" replace="${argsListDelimiter}" />
+ <replace file="${basedir}/${optionsFile}" token="@rt@" value="${bootclasspath}" />
+ <replace file="${basedir}/${optionsFile}" token="@baseLocation@" value="${baseLocation}" />
+
+
+ <!--scrub isv plugin directories of any preexisting api doc content-->
+ <delete dir="reference/api"/>
+ <mkdir dir="reference/api"/>
+
+ <exec dir="." executable="${javadoc}" output="doc.bin.log">
+ <arg line="@${basedir}/${optionsFile} -J-Xmx500M" />
+ </exec>
+ <antcall target="generateJdtAptJavadoc" />
+ </target>
+
+ <target name="generateJdtAptJavadoc">
+ <property name="javadoc15" value="${javadoc}" />
+
+ <property name="jdtaptoptionsFile" value="jdtaptOptions.tmp.txt" />
+ <copy file="jdtaptOptions.txt" tofile="${jdtaptoptionsFile}" overwrite="true" />
+
+ <condition property="argsListDelimiter" value=":">
+ <os family="unix" />
+ </condition>
+ <condition property="argsListDelimiter" value=";">
+ <os family="windows" />
+ </condition>
+
+ <replaceregexp file="${basedir}/${jdtaptoptionsFile}" flags="g" match="(\r\n?|\n);" replace="${argsListDelimiter}" />
+ <replace file="${basedir}/${jdtaptoptionsFile}" token="@rt@" value="${bootclasspath}" />
+
+ <!--scrub isv plugin directories of any preexisting api doc content-->
+ <delete dir="reference/apt" />
+ <mkdir dir="reference/apt" />
+
+ <exec dir="." executable="${javadoc15}" output="jdtapt.doc.bin.log">
+ <arg line="@${basedir}/${jdtaptoptionsFile} -J-Xmx500M" />
+ </exec>
+ </target>
+
+ <target name="buildPlatformDoc" unless="platform.index.present">
+ <ant antfile="buildDoc.xml" dir="../org.eclipse.platform.doc.isv" />
+ </target>
+
+ <target name="createDocZip">
+ <zip zipfile="${basedir}/doc.zip"
+ basedir="${basedir}"
+ includes="book.css, cpy.png, notices.html, about.html, no_help_exists.htm, concepts/**, gettingStarted/**, images/**, reference/**, tasks/**,samples/**,guide/**,questions/**"
+ />
+ </target>
+
+</project>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/cheatsheets/SimpleOTApplication.xml b/plugins/org.eclipse.objectteams.otdt.ui.help/cheatsheets/SimpleOTApplication.xml
new file mode 100644
index 0000000..d8daa1c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/cheatsheets/SimpleOTApplication.xml
@@ -0,0 +1,175 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<cheatsheet title="Simple Object Teams Program">
+
+ <intro
+ href="/org.eclipse.platform.doc.user/reference/ref-cheatsheets.htm">
+ <description>
+ Welcome to the Object Teams tutorial.
+ It will help you build a small Object Teams program.
+ You will create an <b>Object Teams project</b>, a <b>Base class</b>,
+ a <b>Team class</b> and a <b>Role class</b> which contains two
+ kinds of bindings: a <b>callout binding</b> and a <b>callin binding</b>.
+ Let's get started!
+ </description>
+ </intro>
+
+ <item
+ href="/org.eclipse.platform.doc.user/concepts/concepts-4.htm"
+ title="Open the Object Teams Perspective">
+ <action
+ pluginId="org.eclipse.ui.cheatsheets"
+ class="org.eclipse.ui.internal.cheatsheets.actions.OpenPerspective"
+ param1="org.eclipse.objectteams.otdt.ui.OTJavaPerspective"/>
+ <description>
+ Select <b>Window->Open Perspective->Object Teams</b> in the menubar at
+ the top of the workbench. This step changes the perspective to
+ set up the Eclipse workbench for Object Teams development. You can
+ click the "Click to Perform" button to have the "Object Teams"
+ perspective opened automatically.
+ </description>
+ </item>
+
+ <item
+ title="Create an Object Teams Project"
+ skip="true">
+ <action
+ pluginId="org.eclipse.objectteams.otdt.ui"
+ class="org.eclipse.objectteams.otdt.internal.ui.wizards.OpenOTProjectWizardAction"/>
+ <description>
+ The first thing you will need is an Object Teams project. If you
+ already have an Object Teams project in your workspace that you
+ would like to use, you may skip this step by clicking the
+ "Click to Skip" button. If not, select <b>File->New-></b>
+ and choose <b>Object Teams Project</b> in the list. Complete the subsequent
+ pages as required. The "New Object Teams Project" wizard will be automatically
+ displayed when you click the "Click to Perform" button.
+ After creating the project, it will appear in the <b>Package Explorer</b>
+ view. Select the project by clicking it with the mouse, so that the next actions
+ will know that they apply to this project.
+ </description>
+ </item>
+
+ <item
+ href="/org.eclipse.jdt.doc.user/gettingStarted/qs-9.htm"
+ title="Create a Base class"
+ skip="true">
+ <action
+ pluginId="org.eclipse.jdt.ui"
+ class="org.eclipse.jdt.ui.actions.OpenNewClassWizardAction"/>
+ <description>
+ You should now have an Object Teams project in your workspace. The
+ next step in building your Object Teams application is to first
+ create a normal (Base) class. You may do this by either clicking
+ the "Click to Perform" button below to launch the "New Java Class"
+ wizard, or you may use the Eclipse tools to do it, by using the
+ <b>File->New->Class</b> action. Name your class for example
+ "<b>MyBase</b>". If you do not use the "Click to Perform" button below,
+ click the "Click to Skip" button to advance to the next step in
+ building your Object Teams application.
+ </description>
+ </item>
+
+ <item
+ title="Add two methods to your Base class">
+ <description>
+ Now that you have your MyBase class, add, e.g., the following two
+ methods:
+ <br/><b>public void hello() { System.out.println("Hello"); }</b><br/>
+ and
+ <br/><b>public String getWorld() { return "World"; }</b><br/>
+ and save your changes. The first method will be used in a callin binding,
+ the other in a callout binding. These bindings will be members of a
+ Role class which you are going to create in a minute. Click the
+ "Click to Complete" button below when finished.
+ </description>
+ </item>
+
+ <item
+ title="Create a Team class"
+ skip="true">
+ <action
+ pluginId="org.eclipse.objectteams.otdt.ui"
+ class="org.eclipse.objectteams.otdt.internal.ui.wizards.OpenTeamWizardAction"/>
+ <description>
+ The next step in building your Object Teams application is to create a
+ Team class, which is going to be the enclosing context for the Role class.
+ You may do this by either clicking the "Click to Perform" button
+ below to launch the "New Team Class wizard", or you may use the Eclipse
+ tools to do it, by using the <b>File->New->Team</b> action.
+ Name your class, e.g. "<b>MyTeam</b>". If you do not use the "Click to Perform"
+ button below, click the "Click to Skip" button to advance to the next
+ step in building your Object Teams application.
+ </description>
+ </item>
+
+ <item
+ title="Create a Role class"
+ skip="true">
+ <action
+ pluginId="org.eclipse.objectteams.otdt.ui"
+ class="org.eclipse.objectteams.otdt.internal.ui.wizards.OpenRoleWizardAction"/>
+ <description>
+ The next step in building your Object Teams application is to create a
+ Role class for the previously created Team class.
+ You may do this by either clicking the "Click to Perform" button
+ below to launch the New Role Class wizard, or you may use the Eclipse
+ tools to do it, by using the <b>File->New->Role</b> action.
+ Name your class, e.g. "<b>MyRole</b>". Enter the name of the enclosing Team
+ you have created before, in this case "MyTeam". Now bind the Role class to
+ your previously created Base class, either by typing in its name ("MyBase")
+ into the designated input field, or by choosing the Base class after clicking
+ the "Browse..." button next to the input field. If you do not use the "Click
+ to Perform" button below, click the "Click to Skip" button to advance to the
+ next step.
+ </description>
+ </item>
+
+ <item
+ title="Add two methods and two different bindings to your Role class">
+ <description>
+ Now that you have your "MyRole" class, add, e.g., the following two
+ methods:
+ <br/><b>public abstract String getAddressee();</b><br/>
+ and
+ <br/><b>public void greet() { System.out.println(getAddressee()); }</b><br/>
+ These are the Role methods that will be bound in a callout and callin
+ binding respectively. Let's add a callout binding:
+ <br/><b>getAddressee -> getWorld;</b><br/>
+ and a callin binding:
+ <br/><b>greet <- after hello;</b><br/>
+ and save your changes. Click the "Click to Complete" button below when finished.
+ </description>
+ </item>
+
+ <item
+ title="Add a main method.">
+ <description>
+ In order to complete your application, add a main method to your Team class:
+ <br/><b>public static void main(String[] args) {</b>
+ <br/><b>MyTeam myTeam = new MyTeam();</b>
+ <br/><b>myTeam.activate();</b>
+ <br/><b>new MyBase().hello();</b>
+ <br/><b>}</b><br/>
+ Click the "Click to Complete" button below when finished.
+ </description>
+ </item>
+
+ <item
+ href="/org.eclipse.jdt.doc.user/gettingStarted/qs-12.htm"
+ title="Tutorial finished!">
+ <description>
+ Congratulations! You have built your first Object Teams program. Now let's run it!
+ On "MyTeam" (either in the package explorer or in the editor) select from the context menu:
+ <b>Run As->Java Application</b>.
+ Watch the <b>Console</b> view appear, showing the application's output!
+ You can later inspect and modify the run configuration by choosing in the menubar
+ <b>Run->Run-Configurations...</b> and searching the configuration for "MyTeam"
+ under "Java Application". An essential detail you will find in the "JRE" tab of
+ the run configuration dialog: Under the heading <b>Object Teams Runtime</b> there
+ is a checkbox <b>enable OTRE</b> which has to be checked for running OT/J programs
+ (default in Object Teams projects).
+ That's it, you are now ready for Object Teams development!
+ </description>
+ </item>
+
+</cheatsheet>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/book.css b/plugins/org.eclipse.objectteams.otdt.ui.help/css/book.css
new file mode 100644
index 0000000..59c346d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/book.css
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/ot_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/ot_obj.gif
new file mode 100644
index 0000000..b6f6134
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/ot_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/othov_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/othov_obj.gif
new file mode 100644
index 0000000..28296c1
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/othov_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/otjdev_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/otjdev_obj.gif
new file mode 100644
index 0000000..f6526a2
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/otjdev_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/otjdevhov_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/otjdevhov_obj.gif
new file mode 100644
index 0000000..36b47d3
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/graphics/obj_48/otjdevhov_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/ot-overview.properties b/plugins/org.eclipse.objectteams.otdt.ui.help/css/ot-overview.properties
new file mode 100644
index 0000000..a8ed06d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/ot-overview.properties
@@ -0,0 +1,37 @@
+###############################################################################
+# Copyright (c) 2000, 2004 IBM Corporation and others.
+#
+# All rights reserved. This program and the accompanying materials
+# are made available under the terms of the Eclipse Public License v1.0
+# which accompanies this distribution, and is available at
+# http://www.eclipse.org/legal/epl-v10.html
+# $Id$
+#
+# Please visit http://www.eclipse.org/objectteams for updates and contact.
+#
+# Contributors:
+# IBM Corporation - initial API and implementation
+# Fraunhofer FIRST - Initial API and implementation
+# Technical University Berlin - Initial API and implementation
+###############################################################################
+
+overview.page-content.overview-links.java.link-icon = css/graphics/obj_48/javadev_obj.gif
+
+tutorials.page-content.java.layout.ncolumns = 2
+tutorials.page-content.java.hello-world.link-icon = css/graphics/obj_48/javaapp_obj.gif
+tutorials.page-content.java.applet.link-icon = css/graphics/obj_48/javaapplet_obj.gif
+tutorials.page-content.java.swt.link-icon = css/graphics/obj_48/swtapp_obj.gif
+tutorials.page-content.java.ant.link-icon = css/graphics/obj_48/script_obj.gif
+
+
+otdt-root.page-content.layout.vspacing = 5
+
+otdt-root.page-content.ot-motivation.layout.vspacing = 5
+otdt-root.page-content.ot-motivation.layout.ncolumns = 1
+otdt-root.page-content.ot-motivation.moti.layout.vspacing = 5
+otdt-root.page-content.ot-motivation.moti.layout.ncolumns = 1
+
+otdt-root.page-content.ot-keyfeatures.layout.vspacing = 5
+otdt-root.page-content.ot-keyfeatures.layout.ncolumns = 1
+otdt-root.page-content.ot-keyfeatures.features.layout.vspacing = 5
+otdt-root.page-content.ot-keyfeatures.features.layout.ncolumns = 1
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/overview.css b/plugins/org.eclipse.objectteams.otdt.ui.help/css/overview.css
new file mode 100644
index 0000000..238d3a6
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/overview.css
@@ -0,0 +1,75 @@
+body {
+ background-image : url(../graphics/contentpage/overview_wtr.jpg);
+}
+
+.page { min-height : 700px; }
+
+/* show the "selected" image for this page */
+#navigation-links a#overview img, #navigation-links a#overview:hover img { background-image : url(../graphics/icons/ctool/overview48sel.gif); }
+
+/*
+ * Set up the Overview links to be displayed in two columns
+ * that are centered in the middle of the page.
+ */
+
+#overview-links {
+ text-align : left;
+ width : 760px;
+ /* To center in Moz (have to use text-align for IE) */
+ margin : 0px auto;
+}
+
+#overview-links a {
+ width : 370px;
+ text-align : left;
+ margin-left : 5px;
+ margin-right : 5px;
+ margin-top : 5px;
+ margin-bottom : -20px;
+ vertical-align : top;
+}
+
+#overview-links > a { vertical-align : middle; }
+
+#overview-links a img {
+ height : 57px;
+ width : 57px;
+ vertical-align : middle;
+}
+
+#overview-links a .link-label {
+ display : block;
+ width : 300px;
+ position : relative;
+ top : -50px;
+ left : 60px;
+}
+
+#overview-links a p .text {
+ display : block;
+ width : 300px;
+ position : relative;
+ top : -45px;
+ left : 53px;
+}
+
+/* Special case for Mozilla, because the links are displayed
+ in 1 vertical column instead of 2 centered columns */
+#overview-links > a { width : 700px; }
+#overview-links a > .link-label { width : 700px; }
+#overview-links a p > .text { width : 700px; }
+
+#overview-links a:hover { border-right : 5px; }
+
+a#basics img { background-image : url(../graphics/icons/obj48/wbbasics_obj.gif); }
+a#basics:hover img { background-image : url(../graphics/icons/obj48/wbbasicshov_obj.gif); }
+
+a#team img { background-image : url(../graphics/icons/obj48/teamsup_obj.gif); }
+a#team:hover img { background-image : url(../graphics/icons/obj48/teamsuphov_obj.gif); }
+
+
+
+/* Object Teams stuff */
+#h1 {color:#000000; font-weight:bold; font-size:18px;}
+#h2 {color:#000000; font-weight:bold; font-size:14px;}
+#h3 {color:#000000; font-weight:bold; font-size:12px;}
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/root.css b/plugins/org.eclipse.objectteams.otdt.ui.help/css/root.css
new file mode 100644
index 0000000..637c071
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/root.css
@@ -0,0 +1,200 @@
+/*
+ * Set up general font colours, sizes, etc. Some of these will override
+ * settings from the shared CSS
+ */
+.intro-header H1 {
+ font-size : 18pt;
+}
+
+#page-links a .link-label, #action-links a .link-label {
+ font-size : 13pt;
+ font-weight : 600;
+ color : #E5E5E5;
+}
+
+#page-links a p .text, #action-links a p .text {
+ font-size : 13pt;
+ font-weight : 500;
+ color : #E5E5E5;
+}
+
+/*
+ * Set up the content for the otdt-root page.
+ */
+body {
+padding:1em;
+ min-width : 770px;
+ /* since IE doesn't support min-width, use expression */
+ width:expression(document.body.clientWidth < 770? "770px": "auto" );
+ background-image : url(graphics/otdt-rootpage/background.jpg);
+ background-repeat : no-repeat;
+ background-position : top left;
+ background-color : #FFFFFF;
+
+}
+
+#otdt-root {
+ background-image : url(graphics/otdt-rootpage/brandmark.gif);
+ background-repeat : no-repeat;
+ background-position : bottom left;
+ min-height : 450px;
+ height : 100%;
+ height : expression(document.body.clientHeight < 450? "450px": "100%" );
+}
+/*
+ * Set up the navigation bar. It should be centered in the middle
+ * of the page
+ */
+
+#links-background {
+ background-image : url(graphics/otdt-rootpage/dots.gif);
+ background-repeat : repeat-x;
+ width : 100%;
+ height : 177px;
+ margin-top : 18%;
+ margin-bottom : auto;
+ text-align : center;
+}
+
+/* specify a width for Moz so we can center.
+ * **Important** If additional links are added, we will have to increase this width
+ * to accomodate them, otherwise they will wrap to a new line
+ */
+#links-background > #page-links {
+ width : 33em;
+ margin : 0 auto;
+}
+
+#page-links { position : relative; top : 50px; }
+
+#page-links a {
+ position : relative;
+ width : 7em;
+ margin-left : 0.5em;
+ margin-right : 0.5em;
+ text-align : center;
+ vertical-align : top;
+}
+
+/* float left for Moz so the items all appear inline */
+#page-links > a { float : left; position : relative; }
+
+#page-links a img {
+ height : 82px;
+ width : 82px;
+ vertical-align : middle;
+}
+
+/* remove the hover image from the flow of the document,
+ so it doesn't take up space and change the position
+ of the link label and descriptions */
+#page-links a .background-image { position : absolute; }
+
+/* protect against very long labels in IE */
+#page-links a .link-label { word-wrap : break-word; }
+
+#page-links a span {
+ display : block;
+ margin : 0px;
+ padding : 0px;
+}
+
+/* properly align the link text based on class (left vs. right) */
+#page-links a.left p { text-align : left;}
+#page-links a.left span { text-align : left; margin-left : 15px; }
+
+#page-links a.right p { text-align : right;}
+#page-links a.right .link-label { text-align : right; margin-right : 15px; }
+#page-links a.right p .text { position : relative; right : 15px;}
+
+/* hide the link label until users hover over the link */
+#page-links a .link-label { padding-top : 20px; visibility : hidden; }
+#page-links a:hover .link-label,
+#page-links a:focus .link-label,
+#page-links a:active .link-label { visibility : visible; }
+
+/* hide the description until users hover over the link */
+#page-links a p .text { display : none; }
+#page-links a:hover p .text {
+ display : block;
+ width : 15em;
+ position : absolute;
+}
+
+#page-links a:hover,
+#page-links a:focus { border : 0px; }
+
+#page-links a:hover p,
+#page-links a:focus p,
+#page-links a:active p { margin : 0px; padding : 0px; }
+
+/* properties for each of the page-links */
+a#overview .background-image { background-image : url(graphics/icons/ctool/overview72.gif); visibility : hidden; }
+a#tutorials .background-image { background-image : url(graphics/icons/ctool/tutorials72.gif); visibility : hidden; }
+a#samples .background-image { background-image : url(graphics/icons/ctool/samples72.gif); visibility : hidden; }
+a#news .background-image { background-image : url(graphics/icons/ctool/whatsnew72.gif); visibility : hidden; }
+
+/* show the hover image on hover, focus, and active */
+#page-links a:hover .background-image,
+#page-links a:focus .background-image,
+#page-links a:active .background-image { visibility : visible; }
+
+/*
+ * Set up the action links
+ */
+#action-links {
+ width : 98%;
+ position : absolute;
+ left : 0px;
+ top : 20px;
+}
+
+#action-links a#workbench {
+ position : absolute;
+ top : -16px;
+ right : -8px;
+ text-align : right;
+}
+
+#action-links a .background-image,
+#action-links a #workbench_img {
+ height : 53px;
+ width : 53px;
+ text-align : center;
+ vertical-align : top;
+}
+/* special case for mozilla */
+#action-links a > .background-image,
+#action-links a > #workbench_img { vertical-align : middle; }
+
+/* remove the hover image from the flow of the document,
+ so it doesn't take up space and change the position
+ of the main image */
+#action-links a .background-image {
+ position : absolute;
+}
+#action-links a#workbench .background-image {
+ background-image : url(graphics/icons/ctool/wb48.gif);
+ visibility : hidden;
+}
+
+#action-links a#workbench:hover .background-image,
+#action-links a#workbench:focus .background-image,
+#action-links a#workbench:active .background-image {
+ visibility : visible;
+}
+
+/* hide the link and description until users hover over the link */
+#action-links a p .text, #action-links a .link-label { display : none; }
+
+#action-links a:hover .link-label,
+#action-links a:focus .link-label,
+#action-links a:active .link-label { display : block; width : 16em; }
+
+#action-links a:hover p .text,
+#action-links a:focus p .text,
+#action-links a:active p .text { display : block; width : 16em; }
+
+#action-links a:hover,
+#action-links a:focus,
+#action-links a:active { border-right : 0px; }
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/root_swt.properties b/plugins/org.eclipse.objectteams.otdt.ui.help/css/root_swt.properties
new file mode 100644
index 0000000..d086308
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/root_swt.properties
@@ -0,0 +1,29 @@
+
+otdt-root.links-background.page-links.overview.link-icon = css/graphics/icons/etool/overview72.gif
+otdt-root.links-background.page-links.tutorials.link-icon = css/graphics/icons/etool/tutorials72.gif
+otdt-root.links-background.page-links.samples.link-icon= css/graphics/icons/etool/samples72.gif
+otdt-root.links-background.page-links.news.link-icon = css/graphics/icons/etool/whatsnew72.gif
+otdt-root.action-links.workbench.link-icon = css/graphics/icons/etool/wb48.gif
+
+otdt-root.links-background.page-links.overview.hover-icon = css/graphics/icons/ctool/overview72.gif
+otdt-root.links-background.page-links.tutorials.hover-icon = css/graphics/icons/ctool/tutorials72.gif
+otdt-root.links-background.page-links.samples.hover-icon = css/graphics/icons/ctool/samples72.gif
+otdt-root.links-background.page-links.news.hover-icon = css/graphics/icons/ctool/whatsnew72.gif
+otdt-root.action-links.workbench.hover-icon = css/graphics/icons/ctool/wb48.gif
+
+
+otdt-root.links-background.page-links.overview.small-link-icon = css/graphics/icons/etool/overview48.gif
+otdt-root.links-background.page-links.tutorials.small-link-icon = css/graphics/icons/etool/tutorials48.gif
+otdt-root.links-background.page-links.samples.small-link-icon = css/graphics/icons/etool/samples48.gif
+otdt-root.links-background.page-links.news.small-link-icon = css/graphics/icons/etool/whatsnew48.gif
+otdt-root.action-links.workbench.small-link-icon = css/graphics/icons/etool/wb48.gif
+
+otdt-root.links-background.page-links.overview.small-hover-icon = css/graphics/icons/ctool/overview48.gif
+otdt-root.links-background.page-links.tutorials.small-hover-icon = css/graphics/icons/ctool/tutorials48.gif
+otdt-root.links-background.page-links.samples.small-hover-icon = css/graphics/icons/ctool/samples48.gif
+otdt-root.links-background.page-links.news.small-hover-icon = css/graphics/icons/ctool/whatsnew48.gif
+otdt-root.action-links.workbench.small-hover-icon = css/graphics/icons/ctool/wb48.gif
+
+otdt-root.layout.ncolumns = 1
+otdt-root.links-background.page-links.layout.hspacing = 10
+otdt-root.layout.vspacing = 10
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/shared.css b/plugins/org.eclipse.objectteams.otdt.ui.help/css/shared.css
new file mode 100644
index 0000000..00de420
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/shared.css
@@ -0,0 +1,217 @@
+/*
+ * Set up general fonts, sizes and colors
+ */
+body { font-family : Arial, sans-serif; }
+
+H1, H2, H3, H4, p, a { color : #4D4D4D; }
+
+.intro-header H1 {
+ font-size : 16pt;
+ font-weight : normal;
+ color : #E5E5E5;
+}
+
+h2 {
+ font-size : 13pt;
+ font-weight : normal;
+ color : #7B8694;
+}
+/* For regular div labels */
+H4 .div-label {
+ font-size : 10pt;
+ font-weight : bold;
+}
+
+/* For the main page content's title */
+#content-header H4 .div-label {
+ font-size : 14pt;
+ font-weight : normal;
+ color : #8C96A2;
+ float : none;
+ clear : both;
+}
+
+.page-description {
+ font-size : 10pt;
+ float : none;
+ clear : both;
+}
+
+a {
+ font-weight : bold;
+ text-decoration : none;
+ color : #4D4D4D;
+}
+
+a .link-label {
+ font-size : 10pt;
+ font-weight : normal;
+}
+
+#navigation-links a .link-label {
+ font-size : 9pt;
+ font-weight : normal;
+ color : #E5E5E5;
+}
+
+a .text {
+ font-size : 8pt;
+ font-weight : normal;
+}
+
+p .group-description {
+ font-size : 10pt;
+ font-weight : normal;
+}
+
+
+/*
+ * Set up other general properties like padding/margins
+ */
+html, body { width : 100%; height : 100%; }
+
+html, body, div, h1, h4, p, a { margin : 0px; padding : 0px; }
+
+.intro-header H1 { padding-top : 10px; margin-left : 10px; }
+
+/* For regular div labels */
+#page-content div H4 {
+ padding : 10px;
+ padding-bottom : 0px;
+}
+
+/* For the main page content's div label */
+#page-content #content-header H4 {
+ padding-bottom : 10px;
+ padding-top : 0px;
+}
+
+/* special case for Mozilla's main content-header label.
+ Mozilla 1.4 needs more room at the top */
+#page-content > #content-header H4 { padding-top : 10px; }
+
+/* Needed in IE to get shift+tab to show the active image properly */
+a:active {
+ border : solid 0px;
+}
+
+a img {
+ border-width : 0;
+ background-repeat : no-repeat;
+}
+
+/*
+ * to get scrollbars working in both IE and Mozilla
+ */
+html,body { overflow: auto; }
+html>body { overflow: visible; }
+
+/*
+ * Set up the body, decorative background, and navigation for the content
+ * pages.
+ * Note: the root page handles its own background and navigation; these
+ * settings primarily apply to the content pages
+ */
+body {
+ background-color : #FFFFFF;
+ background-repeat : no-repeat;
+ background-position : bottom right;
+}
+
+
+
+.intro-header { background-color : transparent; z-index : 100;}
+
+body, .page{
+ min-width : 770px;
+ /* since IE doesn't support min-width, try expression */
+ width:expression(document.body.clientWidth < 770? "770px": "auto" );
+ min-height : 425px;
+ height : 100%;
+ height : expression(document.body.clientHeight < 425? "425px": "100%" );
+}
+
+.page {
+ background-image : url(graphics/contentpage/wordmark.gif);
+ background-repeat : no-repeat;
+ background-position : bottom left;
+ min-height : 475px;
+}
+
+#page-content {
+ background-repeat : no-repeat;
+ background-position : bottom right;
+ height : 70%;
+}
+
+/*
+ * Lay out the navigation links
+ * (Root page does something similar for its navigation)
+ */
+#navigation-links {
+ position : relative;
+ left : 10px;
+ top : 5px;
+ height : 60;
+ width : 98%;
+}
+
+#navigation-links a {
+ padding-left : 5px;
+ padding-right : 5px;
+ float : left;
+ text-align : center;
+}
+
+#navigation-links a img {
+ height : 52px;
+ width : 52px;
+ vertical-align : middle;
+}
+
+#navigation-links a .link-label { display : block; margin-top : 5px;}
+
+#navigation-links a .text { display : none; }
+
+#navigation-links a:hover,
+#navigation-links a:focus
+#navigation-links a:active { border-right : 0px;}
+
+
+#navigation-links a#workbench { position : absolute; right : 0px; top : -35px; text-align : right;}
+#navigation-links a#workbench .text { display : none; }
+#navigation-links a#workbench img { background-image : url(graphics/icons/etool/wb48.gif); width : 53px; height : 53px;}
+#navigation-links a#workbench:hover img,
+#navigation-links a#workbench:focus img,
+#navigation-links a#workbench:active img { background-image : url(graphics/icons/ctool/wb48.gif); }
+
+/*
+ * Lay out the page title and description
+ */
+h1, p { margin-left : 10px; } /* required in mozilla so the page description is properly indented */
+
+/* position the page content so that the page title overlays the bottom
+ * of the background image, but make sure the content is always on top
+ * (using z-index) */
+#page-content {
+ float : none;
+ clear : both;
+ text-align : center;
+ margin-top : 35px;
+}
+
+.page > #page-content { margin-top : 50px; }
+
+#page-content p {
+ padding-bottom : 15px;
+ text-align : left;
+ float : none;
+ clear : both;
+}
+
+#page-content #content-header H4, .page-description {
+ text-align : left;
+ margin-right : 10px;
+ float : none;
+ clear : both;
+}
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/swt.properties b/plugins/org.eclipse.objectteams.otdt.ui.help/css/swt.properties
new file mode 100644
index 0000000..b367cd8
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/swt.properties
@@ -0,0 +1,24 @@
+###############################################################################
+# Copyright (c) 2000, 2004 IBM Corporation and others.
+#
+# All rights reserved. This program and the accompanying materials
+# are made available under the terms of the Eclipse Public License v1.0
+# which accompanies this distribution, and is available at
+# http://www.eclipse.org/legal/epl-v10.html
+# $Id$
+#
+# Please visit http://www.eclipse.org/objectteams for updates and contact.
+#
+# Contributors:
+# IBM Corporation - initial API and implementation
+# Fraunhofer FIRST - Initial API and implementation
+# Technical University Berlin - Initial API and implementation
+###############################################################################
+tutorials.page-content.java.layout.ncolumns = 2
+
+overview.page-content.overview-links.otdt-root.link-icon = css/graphics/obj_48/otjdev_obj.gif
+tutorials.page-content.ot.ot-Tutorial.link-icon = css/graphics/obj_48/otjdev_obj.gif
+
+tutorials.ot-Tutorial.link-icon = intro/css/graphics/obj_48/otjdev_obj.gif
+tutorials.ot-Tutorial.hover-icon = intro/css/graphics/obj_48/otjdev_obj.gif
+
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/css/tutorials.css b/plugins/org.eclipse.objectteams.otdt.ui.help/css/tutorials.css
new file mode 100644
index 0000000..c10889a
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/css/tutorials.css
@@ -0,0 +1,3 @@
+
+a#ot-tutorial img { background-image : url(/graphics/obj_48/otjdev_obj.gif); }
+a#ot-tutorial:hover img { background-image : url(/graphics/obj_48/otjdevhov_obj.gif); }
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/customBuildCallbacks.xml b/plugins/org.eclipse.objectteams.otdt.ui.help/customBuildCallbacks.xml
new file mode 100644
index 0000000..4974688
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/customBuildCallbacks.xml
@@ -0,0 +1,151 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- ===================================================================== -->
+<!-- Custom targets called from a project's generated build.xml -->
+<!-- Set customBuildCallbacks=<path/to/this/file> in your build.properties.-->
+<!-- ===================================================================== -->
+<project name="Build specific targets and properties" default="noDefault">
+
+ <!-- ===================================================================== -->
+ <!-- Default target -->
+ <!-- ===================================================================== -->
+ <target name="noDefault">
+ <echo message="This file must be called with explicit targets" />
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do before the target build.jars -->
+ <!-- Available parameters : -->
+ <!-- build.result.folder - folder to contain the build results -->
+ <!-- ===================================================================== -->
+ <target name="pre.build.jars">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after the target build.jars -->
+ <!-- Available parameters : -->
+ <!-- build.result.folder - folder to contain the build results -->
+ <!-- ===================================================================== -->
+ <target name="post.build.jars">
+ <ant antfile="buildDoc.xml" />
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do before the target build.sources -->
+ <!-- Available parameters : -->
+ <!-- build.result.folder - folder to contain the build results -->
+ <!-- ===================================================================== -->
+ <target name="pre.build.sources">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after the target build.sources -->
+ <!-- Available parameters : -->
+ <!-- build.result.folder - folder to contain the build results -->
+ <!-- ===================================================================== -->
+ <target name="post.build.sources">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do before the compilation target <name> -->
+ <!-- Substitute "name" with the name of the compilation target, eg @dot -->
+ <!-- Available parameters : -->
+ <!-- source.foldern : n = 1 ... N, the source folders -->
+ <!-- target.folder : where the results of the compilation go -->
+ <!-- <name>.classpath : name = name of the compilation target. A -->
+ <!-- reference to the classpath structure. -->
+ <!-- ===================================================================== -->
+ <target name="pre.activeHelpSample.jar">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after compilation but before jaring -->
+ <!-- Substitute "name" with the name of the compilation target, eg @dot -->
+ <!-- Available parameters : -->
+ <!-- source.foldern : n = 1 ... N, the source folders -->
+ <!-- target.folder : where the results of the compilation go -->
+ <!-- <name>.classpath : name = name of the compilation target. A -->
+ <!-- reference to the classpath structure. -->
+ <!-- ===================================================================== -->
+ <target name="post.compile.activeHelpSample.jar">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after the compilation target <name> -->
+ <!-- Substitute "name" with the name of the compilation target, eg @dot -->
+ <!-- Available parameters : -->
+ <!-- jar.location - the location of the compilation results -->
+ <!-- <name>.classpath : name = name of the compilation target. A -->
+ <!-- reference to the classpath structure. -->
+ <!-- ===================================================================== -->
+ <target name="post.activeHelpSample.jar">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do before the target gather.bin.parts -->
+ <!-- Available parameters : -->
+ <!-- destination.temp.folder - the directory plugins will be collected to -->
+ <!-- feature.directory - the directory containing the resulting feature -->
+ <!-- ===================================================================== -->
+ <target name="pre.gather.bin.parts">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after the target gather.bin.parts -->
+ <!-- Available parameters : -->
+ <!-- base.dir - root of the project -->
+ <!-- build.result.folder - folder containing the build results -->
+ <!-- target.folder - destination folder -->
+ <!-- ===================================================================== -->
+ <target name="post.gather.bin.parts">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do before the target gather.sources -->
+ <!-- Available parameters : -->
+ <!-- destination.temp.folder - destination folder -->
+ <!-- ===================================================================== -->
+ <target name="pre.gather.sources">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after the target gather.sources -->
+ <!-- Available parameters : -->
+ <!-- destination.temp.folder - destination folder -->
+ <!-- ===================================================================== -->
+ <target name="post.gather.sources">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do before the target gather.logs -->
+ <!-- Available parameters : -->
+ <!-- destination.temp.folder - destination folder -->
+ <!-- ===================================================================== -->
+ <target name="pre.gather.logs">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after the target gather.logs -->
+ <!-- Available parameters : -->
+ <!-- destination.temp.folder - destination folder -->
+ <!-- ===================================================================== -->
+ <target name="post.gather.logs">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do before the target clean -->
+ <!-- Available parameters : -->
+ <!-- destination.temp.folder - destination folder -->
+ <!-- ===================================================================== -->
+ <target name="pre.clean">
+ </target>
+
+ <!-- ===================================================================== -->
+ <!-- Steps to do after the target clean -->
+ <!-- Available parameters : -->
+ <!-- plugin.destination - final destination of the build -->
+ <!-- build.result.folder - results of the compilation -->
+ <!-- temp.folder - temporary folder -->
+ <!-- ===================================================================== -->
+ <target name="post.clean">
+ </target>
+</project>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/bindingeditor.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/bindingeditor.html
new file mode 100644
index 0000000..d50c87a
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/bindingeditor.html
@@ -0,0 +1,67 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2011. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otjld/css/ot.css">
+ <link rel=stylesheet type="text/css" href="otguide.css">
+ <style type="text/css">
+ body { margin:10px; }
+ .high { background-color:#a5b7bd;color:white; }
+ .low { background-color:#fff0c8; padding:2px; }
+ .caption { text-decoration:underline; vertical-align:top;position:relative;top:20px; margin-top:10px;}
+ </style>
+ <title>Binding Editor</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1 align="center">Binding Editor</a></h1>
+ The binding editor provides a tabular visualization of all bindings (playedBy, callout, callin) of a given team class.
+ After selecting a team class the binding editor can be invoked using <span class="ui"><img src="../images/calloutbinding_obj.gif">Open Binding Editor</span> from the context menu.
+ <h2>Visualization</h2>
+ The top half of the binding editor consists of three columns: <b>role</b>, <b>binding kind</b>, <b>base</b>.
+ All elements nested in a team or role class can be collapsed/expanded as in other structural views.
+ <img alt="Binding Editor" src="images/screenshots/BindingEditor_FlightBonus.png">
+ <h2>Editing</h2>
+ Bindings can be edited at three levels: <b>types</b>, <b>methods</b>, <b>parameters</b>.
+ Especially, when creating the "Connector" in the <a href="http://wiki.eclipse.org/OTPattern/Connector">Connector Pattern</a>,
+ the binding editor may be all you need, i.e., the full connector definition can be generated using the binding editor
+ with no need to edit source code in the Java editor.
+ <h3>Adding playedBy bindings</h3>
+ When clicking <span class="ui">Add Type Binding</span> you are presented with a twofold type selection dialog.
+ <p>
+ <img alt="Add Type Binding" src="images/screenshots/BindingEditor_AddTypeBinding.png"/>
+ </p>
+ On the left hand side select one of the role types inherited from the super team,
+ on the right hand side select the base class you wish to bind to the role using <code class="keyword">playedBy</code>.
+ When clicking <span class="ui">OK</span> this information will be used for creating a new role class
+ overriding the selected role from the super team and bound to the selected base class.
+ <h3>Adding method bindings</h3>
+ Method bindings are created in the lower half of the binding editor.
+ <p>
+ For creating a <b>callout</b> binding between an existing role method and a base method
+ simply select both methods from the respective lists of Role Methods / Base Methods,
+ also select <span class="ui">-></span> between both lists and click <span class="ui">Apply</span>.<br/>
+ If the selected role method is not abstract, select <span class="ui">=></span> for an overriding callout.</br>
+ For creating a callout binding without an existing role method select <span class="ui"><img src="images/add_correction.gif"> 'New Method()</span>
+ from the left list.
+ </p>
+ <p>
+ For creating a <b>callin</b> binding simply select both methods from the respective lists of Role Methods / Base Methods,
+ also select one of the callin kinds <span class="ui"><- before</span>, <span class="ui"><- replace</span>, or <span class="ui"><- after</span>
+ between both lists and then click <span class="ui">Apply</span>.<br/>
+ </p>
+ <h3>Adding parameter mappings</h3>
+ For creating a parameter mapping first select the method binding, then switch to the tab <span class="ui">Parameter Mapping Configuration</span>.
+ <p>
+ <img alt="Create Parameter Mapping" src="images/screenshots/BindingEditor_ParameterMappings.png"/>
+ </p>
+ Depending on the binding direction enter details in the fields showing either <span class="ui"><-</span> or <span class="ui">-></span>
+ between them.
+ On the target side (where the arrow is pointing to) select one of the declared parameters, on the other side enter a
+ Java expression that can be resolved in the given scope. Don't forget to create each individual parameter mapping using <span class="ui">Apply</span>.
+ <hr/>
+ <p>
+ When closing the binding editor using <span class="ui">OK</span> all pending changes will be generated into the appropriate source file.
+ </p>
+ </body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/builder.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/builder.html
new file mode 100644
index 0000000..15a1a84
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/builder.html
@@ -0,0 +1,29 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otguide.css">
+ <title>Java builder extended for Object Teams</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1>Java builder extended for Object Teams</h1>
+ <p>The <b>OT/J builder</b> is a seamless extension of the Java builder for Object Teams.
+ It manages the incremental compilation of individual source files within a project,
+ which aims at performing minimal work only, as to speed up compilation for large
+ projects if only small changes have been performed.
+ </p><p>
+ By the introduction of role files
+ (<a href="otjld/def/s1.html#s1.2.5"><img src="../icons/ot_paragraph.gif"> 1.2.5</a>)
+ even inner classes (here: roles) can be compiled individually.
+ Incremental compilation is guided by an analysis of the various dependencies among classes.
+ </p><p>
+ If for some reason incremental compilation fails were it should not, a full build can
+ be triggered by <span class="ui">Project->Clean...</code>.
+ </p>
+ <p>Note that the produced class files contain standard Java byte code. However, for execution
+ the Object Teams Runtime Environment (OTRE) is needed in order to weave aspect code into
+ base classes. Additional options in the launching dialog will take care of this detail for you
+ (see <a href="running.html">Running Object Teams programs</a>).
+ </body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/callhierarchy.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/callhierarchy.html
new file mode 100644
index 0000000..273fc99
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/callhierarchy.html
@@ -0,0 +1,37 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otjld/css/ot.css">
+ <style type="text/css">
+ body { margin:10px; }
+ .high { background-color:#a5b7bd;color:white; }
+ .low { background-color:#fff0c8; padding:2px; }
+ .caption { text-decoration:underline; vertical-align:top;position:relative;top:20px; margin-top:10px;}
+ </style>
+ <title>Call hierarchy extended for OT/J</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1 align="center">Call hierarchy extended for OT/J<a name="callhierarchy"></a></h1>
+ <p>
+ The purpose of the Java call hierarchy view is to statically display all potential
+ control flows originating from or leading to a specific program element.
+ Since callout and callin method bindings in OT/J introduce new kinds of control flows,
+ it is only appropriate to also visualize the control flows induced by such method bindings.
+ </p>
+ <p>
+ Whenever a given method can be invoked via a <b>callout method binding</b>,
+ the call hierarchy shows a <img src="../images/calloutbinding_obj.gif"> callout node.
+ Here all calls to the corresponding role method will be forwarded to the base method.
+ </p>
+ <p>
+ Whenever a <b>callin method binding</b> may intercept a given control flow,
+ a <img src="../images/callinbindingreplace_obj.gif"> callin node is shown.
+ Note, that a callin control flow is only taken at runtime,
+ if the enclosing team is active and no guard predicate evaluates to false.
+ </p>
+ <img src="images/screenshots/CallHierarchy.png"
+ alt="Call hierarchy showing Object Teams method bindings">
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/callinmarker.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/callinmarker.html
new file mode 100644
index 0000000..9e96af4
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/callinmarker.html
@@ -0,0 +1,65 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otjld/css/ot.css">
+ <link rel=stylesheet type="text/css" href="otguide.css">
+ <style type="text/css">
+ body { margin:10px; }
+ .high { background-color:#a5b7bd;color:white; }
+ .low { background-color:#fff0c8; padding:2px; }
+ .caption { text-decoration:underline; vertical-align:top;position:relative;top:20px; margin-top:10px;}
+ </style>
+ <title>Binding markers</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1>Binding markers</h1>
+ <p><b>Binding</b> <a href="/help/topic/org.eclipse.platform.doc.user/concepts/concepts-11.htm">
+ markers</a> are OT/J specific annotations on the vertical ruler (marker bar) left of the
+ extended <a href="editor.html">Java Editor</a>. These markers come in three flavors:
+ <ul>
+ <li>A <b>playedBy marker</b> <img src="../images/playedBy_obj.gif"> signals that one or more roles is bound
+ to the current class using <code class="keyword">playedBy</code> (<a href="otjld/def/s2.html#s2.1"><img src="../icons/ot_paragraph.gif"> 2.1</a>).</li>
+ <li>A <b>callin marker</b> <img src="../images/callinbinding_obj.gif"> signals that one or more callin bindings
+ (<a href="otjld/def/s4.html#s4"><img src="../icons/ot_paragraph.gif"> 4</a>) affect the given base method.
+ <li>A <b>callout marker</b> <img src="../images/callout_marker.gif"> signals that one or more callout bindings (<a href="otjld/def/s3.html#s3"><img src="../icons/ot_paragraph.gif"> 3</a>)
+ affect the given base method <b>and</b> that these callout bindings apply decapsulation
+ (<a href="otjld/def/s3.html#s3.4"><img src="../icons/ot_paragraph.gif"> 3.4</a>)
+ — (callout bindings <em>without</em> decapsulation are ranked like regular method calls
+ and thus not considered relevant for marking in the ruler).
+ </ul>
+ <table>
+ <tr><td class="caption">PlayedBy and callin markers</td>
+ <td><img src="images/screenshots/callinmarkers.png"
+ alt="Callin marker annotation in vertical ruler (marker bar)">
+ </tr>
+ <tr><td class="caption">Callout decapsulation marker</td>
+ <td><img src="images/screenshots/calloutmarker.png"
+ alt="Callout decapsulation marker annotation in vertical ruler (marker bar)">
+ </tr>
+ </table>
+ <p>
+ Aside from raising awareness of these bindings, the markers can also be used to directly
+ navigate to the corresponding role or callin/callout binding.
+ When right clicking on a binding marker a pop-up menu will open which contains
+ a corresponding submenu <span class="ui">OT/J bound roles</span>, or <span class="ui">OT/J callin bindings</span>, or <span class="ui">OT/J callout decapsulation</span>.
+ This submenu in turn holds all bindings relevant at the current position,
+ sorted by teams.
+ </p>
+ <table>
+ <tr><td class="caption">PlayedBy marker menu
+ <td><img src="images/screenshots/callinmarker-menu.png"
+ alt="PlayedBy marker menu">
+ </tr>
+ <tr><td class="caption">Callin marker menu
+ <td><img src="images/screenshots/callinmarker-menu3.png"
+ alt="Callin marker menu">
+ </tr>
+ </table>
+ <p>
+ Binding markers are enabled/disabled globally on the <span class="ui">Object Teams</span> preference page.<br>
+ Detailed configuration is possible via <span class="ui">Window->Preferences->General->Editors->Text Editors->Annotations</span>
+ </p>
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/compilation.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/compilation.html
new file mode 100644
index 0000000..f2c0eee
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/compilation.html
@@ -0,0 +1,56 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otguide.css">
+ <title>Compiling Object Teams programs</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1>Compiling Object Teams programs</h1>
+ <p>
+ Object Teams programs are compiled <u>automatically</u> and <u>incrementally</u> using
+ an <b><a href="builder.html">extended Java builder</a></b>.
+ </p>
+ <p>The language accepted by the compiler is defined in the <a href="otjld/def/index.html">OTJLD</a>
+ (OT/J Language Definition), which is bundled with the OTDT.
+ <p>Problems detected by the compiler are classified as either <b><i>warnings</i></b> or
+ <b><i>errors</i></b>.<br />
+ The existence of a warning does not prohibit the execution of the program;
+ some warnings only signal a programming style that is not recommended,
+ others may report situations that are potentially unsafe such that an undeclared
+ exception might occur at runtime.<br />
+ Compile-time errors (as specified by the OT/J Language Specification) imply
+ that byte code generation was incomplete (it may be possible to run even programs with
+ compile errors, but the program will terminate as soon as it tries to execute an
+ erroneous method).
+ <p>
+ <h3>Configuring Diagnostics</h3>
+ For a number of problems you can specify if you want the OT/J compiler
+ to report them as warnings, errors or to ignore them.
+ To change the default settings, use the <span class="ui">Window > Preferences > Java >
+ Compiler (OT/J)</span> preference page (or change the project properties to specify
+ project specific settings).<br />
+ For easy reference, on the preference page each group of diagnostics
+ mentions the paragraph in the language definition that defines the issue at hand.</p>
+ Also note that many of these diagnostics can be fixed using a <a href="quickfix.html">quick fix</a>.
+
+ <h3>Consulting the language definition on problems</h3>
+ <p>When viewing OT/J-specific error/warning messages in the <b>Problems</b> view, the context menu
+ offers a <img src="../icons/ot_paragraph.gif"> <span class="ui">Go To Language Definition</span> link,
+ taking you directly to the paragraph
+ that defines the rule which is being violated by the compiled source code. For presenting the
+ language definition the internal HTML-browser is used to allow easy navigation within the
+ language definition.</p>
+ <img style="margin-left:10px;" title="Language Definition Integrated in the OTDT" src="images/screenshots/langdef.png"/>
+ </p>
+ <p>
+ Alternatively, the same action <span class="ui">Go to Language Definition</span> can be invoked
+ without using the <b>Problems</b> view:
+ <p><u>Using the context menu on the problem marker in the editor's left gutter:</u></p>
+ <img style="margin-left:10px;" title="Language Definition from the left gutter" src="images/screenshots/GoToLangDefGutter.png"/>
+ <p><u>Using a button in the problem hover in the editor:</u></p>
+ <img style="margin-left:10px;" title="Language Definition from the left gutter" src="images/screenshots/GoToLangDefHover.png"/>
+ </p>
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/completion.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/completion.html
new file mode 100644
index 0000000..c8f9001
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/completion.html
@@ -0,0 +1,112 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otjld/css/ot.css">
+ <style type="text/css">
+ body { margin:10px; }
+ .high { background-color:#a5b7bd;color:white; }
+ .low { background-color:#fff0c8; padding:2px; }
+ .caption { text-decoration:underline; vertical-align:top;position:relative;top:20px; margin-top:10px;}
+ </style>
+ <title>OT/J content/code assist</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1 align="center">OT/J code completion<a name="completion"></a></h1>
+ <u>On this page:</u>
+ <br /><a href="#completeRole">1. Overriding an inherited role class</a>
+ <br /><a href="#completeBase">2. Completing a role's base class</a>
+ <br /><a href="#completeMapping">3. Creating callout/callin method bindings</a>
+ <br /><a href="#completeCall">4. Completing special method calls</a>
+ <br /><a href="#completeTemplate">5. Completion templates</a>
+
+ <h2><a name="completeRole">1. Overriding an inherited role class</a></h2>
+ Simply by typing <code class="ui">Ctrl-Space</code> in the body of a team class that inherits from another team, completion proposes
+ to create a role declaration overriding any inherited role from the super team (<a href="otjld/def/s1.html#s1.3.1.c"><img src="../icons/ot_paragraph.gif"> 1.3.1(c).</a>).
+
+ <p>
+ So selecting this proposal:<br>
+ <img style="margin:10px;margin-left:25px;" src="images/screenshots/OverrideRole.png"><br>
+ will create this declaration:
+ <pre style="margin-left:25px;"><code style="color:#606060;">@Override</code>
+<code class="keyword">protected class</code> <code>Subscriber {
+}</code></pre>
+
+ <h2><a name="completeBase">2. Completing a role's base class</a></h2>
+ When expanding the base type after the keyword <code class="keyword">playedBy</code>,
+ completion will also generate an "<code class="keyword">import <strong>base</strong> ...</code>" declaration
+ (<a href="otjld/def/s2.html#s2.1.2.d"><img src="../icons/ot_paragraph.gif"> 2.1.2(d)</a>), if needed.
+
+
+ <h2><a name="completeMapping">3. Creating callout/callin method bindings</a></h2>
+
+ Specific support for code completion exists to facilitate the creation of <b>callout</b> (<a href="otjld/def/s3.html"><img src="../icons/ot_paragraph.gif"> 3.</a>) and <b>callin</b> (<a href="otjld/def/s4.html"><img src="../icons/ot_paragraph.gif"> 4.</a>) method bindings.<br />
+ Completion can be used for
+ <ul>
+ <li><a href="#full">Creating full method bindings (callout/callin)</a>
+ <li><a href="#partial">Completing partial callout/callin bindings</a>
+ <li><a href="#correct">Corrections after callin creation.</a>
+ </ul>
+
+ <h3><a name="full">3.1 Creating full method bindings (callout/callin)</a></h3>
+ Just activating the completion anywhere in the body of a role class allows you to create a full callout or callin binding to an existing base method (or field — "callout to field", see <a href="otjld/def/s3.html#s3.5"><img src="../icons/ot_paragraph.gif"> 3.5</a>).<br />
+ <table>
+ <tr><td colspan=2>
+ After pressing <code>Ctrl-space</code>, selection of the desired binding happens in three steps:
+ <tr><td class="caption">a) Select a base method</td>
+ <td><img src="images/screenshots/complete_binding_1.png">
+ <tr><td class="caption">b) Change the role method name if desired.</td>
+ <td><img src="images/screenshots/complete_binding_2.png">
+ <tr><td class="caption">c) Select the binding kind.</td>
+ <td><img src="images/screenshots/complete_binding_3.png">
+ </table>
+ <h4>3.1.1 Creating callout to field</h4>
+ <p>
+ Two additional kinds of callouts can be generated, by typing "<code>get</code>" or "<code>set</code>" before invoking completion:
+ <table class="border" cellpadding=3>
+ <tr class="z2"><td>after typing <code class="keyword">get</code>
+ <td>Create a callout to field <i>getter</i>.</tr>
+ <tr class="z3">
+ <td>after typing <code class="keyword">set</code>
+ <td>Create a callout to field <i>setter</i>.
+ </table>
+ </p>
+ <h4>3.1.2 Mapping signatures using lifting/lowering</h4>
+ <p>
+ When binding to a base method/field, whose signature contains other base types for which a bound role exists in the current team,
+ completion lets you select whether the role side of the binding should use base or role types.
+ If role types are selected, they will be conform to the corresponding base type by implicitly using lifting (<a href="otjld/def/s2.html#s2.3"><img src="../icons/ot_paragraph.gif"> 2.3</a>) or lowering (<a href="otjld/def/s2.html#s2.2"><img src="../icons/ot_paragraph.gif"> 2.2</a>).
+ </p>
+
+ <h3><a name="partial">3.2 Completing partial callin/callout bindings</a></h3>
+ <p>
+ If a callin or callout binding has been typed up-to and including the "<code class="keyword"><-</code>" or "<code class="keyword">-></code>" token, completion can be used to expand the right hand side specifying the base method or field. For callin bindings you may optionally first type the callin modifier (<code class="keyword">before, replace</code> or <code class="keyword">after</code>). Otherwise you will be prompted for the desired callin modifier.
+ In this case the proposed modifier is inferred to match the bound base method:<br />
+ <table class="border">
+ <tr class="z2"><td>regular method<td>Default is <code class="keyword">before</code> (also <code class="keyword">after</code> is legal).
+ <tr class="z3"><td><code class="keyword">callin</code> method<td>Default is <code class="keyword">replace</code>
+ </table>
+ </p><p>
+ Normally, after "<code class="keyword">-></code>" (as well as for "<code class="keyword"><-</code>") completion will try to expand a base <i>method</i>, if for a callout one of the modifiers <code>get</code> or <code>set</code> has been typed, a <i>field</i> is searched instead.
+
+ <h3><a name="correct">3.3 Corrections after callin creation</a></h3>
+ After generating a callin binding using completion, the following two corrections might be especially helpful:
+ <ul>
+ <li>Adjusting the role method's <code class="keyword">callin</code> modifier, to match the binding's callin modifier.
+ <li>Creating a missing role method.
+ </ul>
+ Both corrections can easily be performed by a <a href="quickfix.html">quickfix</a> offered on the erroneous role method spec.
+
+ <h2><a name="completeCall">4. Completing special method calls</a></h2>
+ <ul>
+ <li>After <code class="keyword">base.</code> (<a href="otjld/def/s4.html#s4.3"><img src="../icons/ot_paragraph.gif"> 4.3</a>) and <code class="keyword">tsuper.</code> (<a href="otjld/def/s1.html#s1.3.1.f"><img src="../icons/ot_paragraph.gif"> 1.3.1(f)</a>) completion offers only those methods that are actually legal in this context,
+ which in bose cases implies the same name and signature as the surrounding role (callin) method.</li>
+ <li>Completion also offers calls to members of the bound base class which are implicitly available using <b>inferred callout</b> (<a href="otjld/def/s3.html#s3.1.j"><img src="../icons/ot_paragraph.gif"> 3.1(j)</a>, <a href="otjld/def/s3.html#s3.5.h"><img src="../icons/ot_paragraph.gif"> 3.5(h)</a>)
+ </ul>
+ <h2><a name="completeTemplate">5. Completion templates</a></h2>
+ Content assist in the
+ form of <a href="/help/topic/org.eclipse.jdt.doc.user/concepts/ctemplates.htm">
+ templates</a> exists for a few specific OT/J language constructs like <span class="low"><code class="keyword">within</code> (<i>Expression</i>)</span>.
+ </p>
+
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/contentassist.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/contentassist.html
new file mode 100644
index 0000000..a8fb902
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/contentassist.html
@@ -0,0 +1,27 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otjld/css/ot.css">
+ <title>OT/J content/code assist</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body style="margin:10px">
+ <h1 align="center">OT/J content/code assist</h1>
+ <p>The <a href="/help/topic/org.eclipse.jdt.doc.user/reference/ref-143.htm">content/code
+ assist (code completions)</a> inherent in the
+ <a href="/help/topic/org.eclipse.jdt.doc.user/concepts/concepts-7.htm">Java editor</a>
+ has been extended in order to provide for Object Teams specific keywords and modifiers (e.g.
+ <code class="keyword">team, playedBy, callin, before, after, replace</code> etc.) as well.
+ Code completion and quick fixes provide more specific assistance depending on the current context of editing.
+ <p>
+ <u>OT/J specific content assist comprises:</u>
+ <ul>
+ <li><a href="completion.html">Completion</a> (<a href="completion.html#completeMapping">callout, callin</a>, <a href="completion.html#completeBase">base class</a>).
+ <li><a href="quickfix.html">Quick fixes</a>
+ <li><a href="quickassist.html">Quick assists</a>
+ </ul>
+ </p>
+
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/css/nn.css b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/css/nn.css
new file mode 100644
index 0000000..af52c5b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/css/nn.css
@@ -0,0 +1,87 @@
+/* Styles for New&Noteworthy documents */
+
+td {border-top: solid thin black;}
+td.noborder {border-top: none;}
+tr {vertical-align: top;}
+.since {
+ font-size:8pt; font-weight:bold;
+ padding-left:3px; padding-right:3px;
+ line-height:40px;
+ text-align:right;
+ color:#000040; background-color:#e0e0e0;
+}
+.since2 {
+ font-size:8pt; font-weight:bold;
+ padding-left:3px; padding-right:3px;
+ text-align:right;
+ color:#000040; background-color:#e0e0e0;
+}
+.since-inline {
+ font-size:8pt; font-weight:bold;
+ padding-left:3px; padding-right:3px;
+ text-align:right;
+ color:#000040; background-color:#e0e0e0;
+}
+a.buglink {
+ background-image:url(../images/bug.gif);
+ padding-left:20px;
+ font-size:9pt;
+ background-repeat:no-repeat;
+ background-position:left;
+ color:#000060;
+ font-weight:normal;
+}
+a.buglink2 {
+ font-size:9pt;
+ color:#000060;
+ font-weight:normal;
+}
+a.otjldlink {
+ background-image:url(../images/otdt/ot_paragraph.png);
+ padding-left:20px;
+ font-size:9pt;
+ background-repeat:no-repeat;
+ background-position:left;
+ color:#000060;
+ font-weight:normal;
+}
+img { margin-top:5px; }
+div.listing {
+ font-family:courier,monospace;
+ margin-left:10pt;
+ padding:5px;
+ background-color:white
+}
+div.listbox {
+ padding:2px;
+ margin-right:50px;
+ background-color:#b0b0b0;
+}
+pre, code {
+ font-family:courier,monospace;
+ font-style:normal;
+}
+.annotation {
+ color:#707070;
+}
+.comment {
+ color:rgb(63,127,95);
+}
+td.h3 {
+ margin-left:120px;
+ font-size:13pt;
+ font-weight:bold;
+}
+div.navigation {
+ /*border-top: solid thin black;*/
+ text-align:center;
+ font-size:11pt; font-weight:bold;
+ margin:20px;
+}
+.ui { background-color:#e0e0e0; padding:2px; }
+
+div.hover {
+ background-color:#F9F6B8;
+ border: 1px solid #c4c295;
+ margin:-3px;padding:3px;
+}
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/css/style.css b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/css/style.css
new file mode 100644
index 0000000..1c3082d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/css/style.css
@@ -0,0 +1,62 @@
+@CHARSET "UTF-8";
+/* from OT-Homepage, referenced from New&Noteworthy pages */
+
+#contentbox
+{
+ position:absolute;top:35px;left:480px;
+ background-color:#D0D0D0;
+ padding:1px;
+}
+
+#contentinner
+{
+ background-color:#def4fe;
+ margin:0px;
+ padding:4px;
+}
+
+#contentinner li
+{
+ padding-top: 0px;
+ padding-bottom: 0px;
+ margin-bottom: 2px;
+ white-space: nowrap;
+}
+
+#widecolumn
+{
+ background: transparent;
+ float: left;
+ margin-right: 20px;
+ width: 640px;
+}
+
+#widecolumn ul, #widecolumn ol
+{
+ margin-left: 20px;
+ padding-bottom: 10px;
+}
+
+
+/* Addition for OT: */
+ul.novaArrow { margin:0px !important;}
+.novaArrow li {
+ background-image:url("/eclipse.org-common/themes/Nova/images/homeitemBullet.png");
+ background-repeat:no-repeat;
+ background-position:0px 0px;
+ padding-left:20px !important;
+ list-style-image: none !important;
+}
+
+code.keyword {
+ color: #7F0055;
+ font-weight: bold;
+}
+
+dt {
+ font-weight: bold;
+}
+
+dd {
+ margin-left: 30px;
+}
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/debugging.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/debugging.html
new file mode 100644
index 0000000..42b715c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/debugging.html
@@ -0,0 +1,40 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otguide.css">
+ <title>Debugging Object Teams programs</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1>Debugging Object Teams programs</h1>
+ <p>Debugging support has been extended in order to help debugging OT/J programs.
+ Debugging OT/J may give rise to a new kind of questions: is a declared
+ callin binding actually firing at run-time? In order to analyze this question
+ a developer may need to investigate:
+ <ol>
+ <li>Has a team instance be created and activated?</li>
+ <li>Is the callin blocked by either a guard predicate or a <code>org.objectteams.LiftingVetoException</code>?</li>
+ </ol>
+ Investigating question 1 is supported by the new <b>team monitor view</b>,
+ support for question 2 is provided by enhancements of the debug view and its stepping actions.
+ </p>
+ <h2><a name="teammonitor" href="teammonitor.html">Team Monitor View</a></h2>
+ A special view exists for monitoring which team instances have been created and whether each
+ of them is currently active or not. When debugging callin bindings which do not trigger while
+ they are intended to do so, the team monitor should provide first help to find out whether
+ there is any active instance of the team being considered. If no active instance exists,
+ callins can not trigger. <a href="teammonitor.html">Read more...</a>
+ <h2><a name="stepping" href="stepping.html">Stepping through OT/J code</a></h2>
+ The byte code into which OT/J programs are translated has some significant differences
+ to the original source code. In order to hide some generated code and to provided
+ convenient stepping even through declarative method bindings, the debug view has
+ been enhanced for OT/J. <a href="stepping.html">Read more...</a>
+ <h2><a name="variables">Variables View</a></h2>
+ By default the variables view hides some internal fields that are generated by the compiler.
+ However, in some situations these variables might come handy for inspecting the linkage between
+ role/base/team instances. For that reason, filtering of these variables
+ can be toggled from the variable view's menu: <span class="ui">Java > Show OT/J Internal Variables</span>.
+ The same holds for the detail drill down of the team monitor.
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/develop.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/develop.html
new file mode 100644
index 0000000..74e474c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/develop.html
@@ -0,0 +1,64 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <title>Key features of the Object Teams Development Tooling</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1>Object Teams Development Tooling</h1>
+ <p>
+ The OTDT is a development environment for the
+ <a href="http://wiki.eclipse.org/OTJ">OT/J</a> programming language.
+ </p>
+ <p>
+ Based on the Eclipse Java development tools (JDT), it includes the following key features, which
+ are explained in the next chapters.<br/>
+
+ </p>
+
+ <h2>Key features of the OTDT</h2>
+ More details can be found on the comprehensive <a href="features.html"><strong>feature list</strong></a>.
+ <ul>
+ <li><b><a href="project.html">Creating</a> an Object Teams project</b> using a wizard</li>
+ <li><b><a href="wizards.html">Creating</a> team and role classes</b> using a wizard</li>
+ <li><a href="editor.html"><b>Editing</b></a> OT/J:
+ <ul style="margin-bottom:0px">
+ <li>Syntax highlighting, <a href="editor.html#navigation">navigation</a>, <a href="contentassist.html">content/code assist</a>, <a href="callinmarker.html">base code annotations</a></li>
+ <li><a href="methodcompare.html"><b>Comparing</b></a> bound methods to facilitate co-evolution of a role with its base</li>
+ <li><a href="refactoring.html"><b>Refactoring</b></a> Object Teams programs</li>
+ </ul></li>
+ <li>Enhanced <b>structural/navigational views</b> and a tabular editor
+ <ul>
+ <li>A table based <a href="bindingeditor.html"><b>binding editor</b></a> specifically supports the creation of <i>connectors</i></li>
+ <li><a href="packageexplorer.html">Package explorer</a> with support for role files/team packages</li>
+ <li><a href="outline.html">Outline</a> showing all OT/J elements</li>
+ <li><a href="typehierarchy.html">Type hierarchy</a> with support for team inheritance</li>
+ <li><a href="callhierarchy.html">Call hierarchy</a> showing control flows induced by callout/callin method bindings</li>
+ </ul>
+ </li>
+ <li><a href="compilation.html"><b>Compiling</b></a> Object Teams programs</li>
+ <li><a href="running.html"><b>Running</b></a> Object Teams programs</li>
+ <li><a href="debugging.html"><b>Debugging</b></a> Object Teams programs</li>
+ </ul>
+
+ <h2>Prerequisites</h2>
+ If you have never used the eclipse Java IDE before, please consider getting familiar with the
+ <a href="/help/topic/org.eclipse.jdt.doc.user/concepts/concepts-1.htm">Java Development Tooling</a>, as
+ the OTDT is built on top of and extends the JDT.
+
+ <h2>Feedback</h2>
+ <p>
+ If you have questions regarding the <a href="otjld/def/index.html">OT/J</a>
+ language or if you experience problems or bugs with the OTDT, do not hesitate to post to the
+ <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.objectteams">Object Teams forum</a>.
+ </p>
+
+ <p>
+ <br>
+ Happy hacking,<br>
+ the OTDT Team.
+ </p>
+
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/editor.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/editor.html
new file mode 100644
index 0000000..9d09bf8
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/editor.html
@@ -0,0 +1,62 @@
+<html>
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otjld/css/ot.css">
+ <link rel=stylesheet type="text/css" href="otguide.css">
+ <title>Java editor with Object Teams capability</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+ </head>
+ <body>
+ <h1>Java editor with Object Teams capability</h1>
+ The extended Java editor provides specialized features for editing
+ OT/J code. The original <a href="/help/topic/org.eclipse.jdt.doc.user/concepts/concepts-7.htm">Java editor</a>
+ has been extended for the following features:
+ <ul>
+ <li><b>Navigation</b> support for Object Teams elements (F3 = <span class="ui">Open Declaration</span>, see below)</li>
+ <li><b>Syntax highlighting</b> for OT/J keywords and modifiers.<br />
+ OT/J keywords are enabled based on the contents of the file being edited.
+ This way the same editor still handles plain Java sources <i>without</i> interpreting OT/J keywords.<br/>
+ However, within an OT/J file syntax highlighting is determined in a context-free manner,
+ which means that scoped keywords
+ (<a href="otjld/def/sA.html#sA.0.1"><img src="../icons/ot_paragraph.gif"> A.0.1</a>)
+ like <code class="keyword">after, base, before, get, result, set</code> are highlighted,
+ even in situations where they have no special meaning.
+ </li>
+ <li><a href="contentassist.html"><b>Content/code assist</b> (code completions)</a> for Object Teams program elements.
+ </li>
+ <li><b>Templates (source patterns)</b> for Object Teams specific language constructs
+ using content assist (<b>Ctrl+Space</b>),
+ e.g. <code class="keyword">within</code> (<i>Expression</i>) <i>Statement</i>
+ </li>
+ <li>New <a href="callinmarker.html"><b>binding marker</b></a> annotations in the vertical ruler (for base classes/methods bound using playedBy/callin/callout)
+ allowing navigation to the affecting role.
+ </li>
+ </ul>
+ <h2><a name="navigation">Navigation</a></h2>
+ Obvious enhancements for the normal F3 navigation regard the following:
+ <ul>
+ <li>Go to a role's base class using the <code class="keyword">playedBy</code> clause.</li>
+ <li>Go to a bound base method or a bound field using a callout or callin binding<br />
+ (the opposite direction is supported by <a href="callinmarker.html">binding markers</a>).</li>
+ </ul>
+ Navigating <strong>role files</strong>
+ (<a href="otjld/def/s1.html#s1.2.5"><img src="../icons/ot_paragraph.gif"> 1.2.5</a>):
+ <ul>
+ <li>Hitting F3 on the <code class="keyword">team package</code> declarations jumps to the enclosing team.</li>
+ <li>In order to navigate from a team to its role file use the quick outline
+ by hitting <code>Ctrl-O</code> twice:<br />
+ role files will be offered for selection along inline members.</li>
+ <li>If javadoc <code>@role</code> tags are used as recommended for listing all role files of the current team
+ (<a href="otjld/def/s1.html#s1.2.5.d"><img src="../icons/ot_paragraph.gif"> 1.2.5(d)</a>),
+ the role names in these tags support F3-navigation to the corresponding roles, too.</li>
+ </ul>
+ Navigating the <strong>implicit role hierarchy</strong> (<a href="otjld/def/s1.html#s1.3.1"><img src="../icons/ot_paragraph.gif"> 1.3.1</a>):
+ <ul>
+ <li>A role class that overrides a corresponding role from the super team is decorated with an override marker (<img src="images/over_co.gif">) in the vertical ruler,
+ which supports the <span class="ui">Open Super Implementation</span> action.</li>
+ <li>A role method overriding a corresponding method from any explicit or implicit super role
+ are also decorated with an override marker (<img src="images/over_co.gif">) supporting navigation to the overridden method.</li>
+ </ul>
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/features.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/features.html
new file mode 100644
index 0000000..7b1fb24
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/features.html
@@ -0,0 +1,377 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../../dtd/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
+ <head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel="stylesheet" href="otjld/css/ot.css" type="text/css" />
+ <link rel="stylesheet" href="otjld/css/otjld.css" type="text/css" />
+ <title>OTDT Feature List</title>
+ <!-- special padding for the table of tests. -->
+ <style type="text/css">
+ td,th { padding-left:15px; padding-right:15px; padding-top:2px; padding-bottom:2px; }
+ </style>
+ </head>
+ <body>
+ <div id="head">
+ <h1>Features of the OTDT (version 2.0)</h1>
+ </div>
+ <div style="margin:10px;margin-top:100px;">
+ <div style="margin-left:40px;padding:2px;float:left;background-color:#D0D0D0;">
+ <div style="padding:4px;background-color:#def4fe;">
+ The release 2.0 is based on Eclipse SDK 3.7.<br/>
+ The OTDT contains a modified version of the JDT core and several added plugins.
+ </div>
+ </div>
+ <br style="clear:both;"/><br/>
+
+ The following components are available:
+
+ <ul>
+ <li><a href="#compiler">Compiler</a></li>
+ <li><a href="#wizards">Wizards</a></li>
+ <li><a href="#editor">Editor</a></li>
+ <li><a href="#bindingEditor">Binding Editor</a></li>
+ <li><a href="#refactoring">Refactoring</a></li>
+ <li><a href="#structureViewers">Structure Viewers</a></li>
+ <li><a href="#Search">Search</a></li>
+ <li><a href="#execution">Execution Environment</a></li>
+ <li><a href="#otequinox">OT/Equinox</a></li>
+ <li><a href="#debugging">Debugging</a></li>
+ <li><a href="#help">Help and additional Information</a></li>
+ </ul>
+
+
+ <p></p>
+
+ <div id="compiler" class="headl"><div class="headr">
+ <h1>Compiler</h1>
+ </div></div>
+
+ The Object Teams Compiler is an incremental compiler, based on the Eclipse Compiler for Java.
+ <dl>
+ <dt><strong>Language Definition</strong></dt>
+ <dd>The compiler implements the language as defined in the OT/J
+ <a href="otjld/def/index.html">language definition</a> version 1.3 (OTJLD).
+ The language definition has continuously been revised to precisely specify the language
+ including various corner cases and combinations of features.
+ </dd>
+ <dt><strong>Language Implementation</strong></dt>
+ <dd>
+ The compiler supports all features of OT/J according to the
+ <a href="otjld/def/index.html"><img alt="otjld" src="../images/ot_paragraph.png"/> OTJLD v1.3</a>
+ §§1-7,9.
+ Support for the join point sub-language (<a href="http://www.objectteams.org/def/0.9/joinpoints.html"><img alt="otjld" src="../images/ot_paragraph.png"/> OTJLD § 8</a>) is not included.
+ <p></p>
+ The compiler can be <strong>configured</strong> using global <code>Preferences</code> or project
+ specific <code>Properties</code>.
+ <ul>
+ <li>Configure OT/J-specific compiler diagnostics as "ignore", "warning" or "error".<br/>
+ Any warnings configured on this property sheet can also be suppressed in the
+ source code using the <code>@SuppressWarnings</code> annotation.</li>
+ <li>Scoped keywords <a href="otjld/def/sA.html#sA.0.1"><img alt="otjld" src="../images/ot_paragraph.png"/> OTJLD § A.0.1</a> can be disabled (default is enabled).
+ </li>
+ </ul>
+ </dd>
+ </dl>
+
+ <div id="wizards" class="headl"><div class="headr">
+ <h1>Wizards</h1>
+ </div></div>
+ <ul>
+
+ <li>The first step to developing with Object Teams in Eclipse is creating an <img class="inline" alt="" src="../images/newprj_wiz.gif"/><code> Object Teams Project</code>. A wizard will guide you through that process. It will also add the Object Teams Runtime Environment (<tt>otre.jar</tt>) to your project's classpath.
+ </li>
+
+ <li>
+
+ Having done that, you can start adding classes — be it regular classes, or <img class="inline" alt="" src="../images/team_obj.gif"/> team or <img class="inline" alt="" src="../images/role_obj.png"/> role classes — wizards will assist you in creating the classes properly.
+ </li>
+ </ul>
+
+
+ <div id="editor" class="headl"><div class="headr">
+ <h1>Editor</h1>
+ </div></div>
+ <ul>
+
+ <li>Editing Object Teams source code is supported by an outline view, showing the structure of the edited source file. This includes the Object Teams specific constructs,
+ <em>teams</em> (<img class="inline" alt="" src="../images/team_obj.gif"/>),
+ <em>roles</em> (<img class="inline" alt="" src="../images/role_obj.png"/>),
+ and <em>method bindings</em> (<img class="inline" alt="" src="../images/callinbindingbefore_obj.gif"/>,
+ <img class="inline" alt="" src="../images/callinbindingreplace_obj.gif"/>,
+ <img class="inline" alt="" src="../images/callinbindingafter_obj.gif"/>,
+ <img class="inline" alt="" src="../images/calloutbinding_obj.gif"/>).</li>
+
+ <li>The editor highlights the Object Teams keywords like "<code class="keyword">team</code>" the same way standard Java keywords are highlighted.</li>
+ <li>All constructs referencing other code elements are navigable. E.g. you can navigate <tt>super()</tt>, <tt>tsuper()</tt>, <tt>base()</tt> calls, as well as <em>callin</em> and <em>callout bindings</em>.
+ The name in a <code class="keyword">team package</code> declaration lets you navigate from a role file
+ (<a href="otjld/def/s1.html#s1.2.5"><img alt="otjld" src="../images/ot_paragraph.png"/> OTJLD § 1.2.5</a>) to its enclosing team.</li>
+
+ <li>Classes to which one or more roles are bound using <code class="keyword">playedBy</code> are
+ annotated with a marker (<img class="inline" alt="" src="../images/playedBy_obj.gif"/>),
+ that allows navigating to the role declaration(s).
+ Similarly, methods in a base class that are bound with a <em>callin binding</em> are
+ annotated with a marker (<img class="inline" alt="" src="../images/callinbinding_obj.gif"/>),
+ that allows navigating to the method binding declaration(s).
+
+ <br/>
+ Because this feature may be resource-consuming in a large workspace the global Object Teams preferences page allows to completely disable the generation of callin markers.</li>
+
+ <li>Semantic highlighting (checkbox "mark occurrences") is fully supported.</li>
+ <li>Code completion (Ctrl-space) is widely supported. It is, e.g., possible to use completion in order to create a callout binding.</li>
+ <li>Content assist provides quick-fixes (Ctrl-1) for a number of OT/J specific errors and warnings.
+ Also a few templates for specific OT/J language constructs —
+ namely <code>with{}</code> and <code>within (<em>Expression</em>){}</code> — are available.</li>
+ </ul>
+
+ <div id="bindingEditor" class="headl"><div class="headr">
+ <h1>Binding Editor</h1>
+ </div></div>
+ <ul>
+ <li>Supports easy creation of connector definitions using a table based graphical user interface. In this context, a <b>connector</b> is meant to be a team that inherits structure
+ (roles) and functionality (methods) from its super-team, and its main purpose is to bind
+ the inherited structure and functionality using <code class="keyword">playedBy</code>
+ declarations and callin/callout method bindings.</li>
+ <li>Type bindings (<code class="keyword">playedBy</code>) can be defined by choosing a provided role type and the desired base type with a type selection dialog.</li>
+ <li>Method bindings (either callin or callout) can be established by choosing a role method and a base method from the provided role and base method list respectively.
+ <ul>
+ <li>Only appropriate binding kinds are selectable in the corresponding context (callin or callout).</li>
+ <li>Besides the provided role methods, a new role method can be implemented by selecting a provided base method, thus creating a callout binding.</li>
+ </ul>
+ </li>
+ <li>Parameter and result mappings are definable by typing in an expression in the corresponding text field of the parameter mapping configuration tab.</li>
+ </ul>
+ The binding editor can be opened either from the new team wizard or using the package explore's context menu (<code><img class="inline" alt="" src="../images/calloutbinding_obj.gif"/> Open Binding Editor</code>).
+ <p></p>
+ <div id="refactoring" class="headl"><div class="headr">
+ <h1>Refactoring</h1>
+ </div></div>
+ <p></p>
+ Significant work has been put into supporting the automated refactoring of OT/J code.
+ The following refactorings take into account the Object Teams-specific
+ relationships (implicit role inheritance, team nesting, role-base bindings and method
+ bindings).
+ <ul>
+ <li><b>Extract Method</b></li>
+ <li><b>Move Method</b></li>
+ <li><b>Pull Up</b> applicable to method or field</li>
+ <li><b>Push Down</b> applicable to method or field</li>
+ <li><b>Rename</b> applicable to: project, source folder, package, type, method, field.<br/>
+ <i>When trying to rename a team package you'll be asked to rename the team class instead.</i></li>
+ </ul>
+ Additionally, specific refactorings for OT/J are being developed. Currently these are implemented:
+ <ul>
+ <li><b>Extract Callin</b></li>
+ <li><b>Inline Callin</b></li>
+ </ul>
+ <p></p>
+
+
+ <div id="structureViewers" class="headl"><div class="headr">
+ <h1>Structure Viewers</h1>
+ </div></div>
+ <dl>
+ <dt><strong>The Package Explorer</strong></dt>
+ <dd>
+ <ul>
+ <li>
+ provides access to all project artifacts and their structure, i.e. source files, used libraries (<em>jar</em>-files), and other documents. Note that team and role classes are annotated with distinct icons (<img class="inline" alt="" src="../images/team_obj.gif"/> for teams and <img class="inline" alt="" src="../images/role_obj.png"/> for roles). (The same icons are used throughout the IDE, whenever a team or role is visible.)
+ </li>
+ <li>
+ If "Java Type Indicators" is enabled under general preferences/label decorations, OT-specific decorations will also be applied to compilation units (files) and team packages.
+ </li>
+ <li>
+ By opening the tree-branches, you can peek at the structure of e.g. classes.
+ </li>
+ <li>For team classes, there is special support for <b>role files</b> (<a href="otjld/def/s1.html#s1.2.5"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 1.2.5</a>):<br/>
+ Role files are separate files and can be shown either
+ <em>physically</em> (<img class="inline" alt="" src="../images/team_package.gif"/>) as (separate) files in the team package or
+ <em>logically</em> (<img class="inline" alt="" src="../images/external_roles.gif"/>) as member types of the enclosing team.
+ </li>
+ <li>
+ Furthermore, the Package Explorer provides the current context for other operations. The Team- and Role-Wizards, for example, have a pre-set source folder, package and enclosing class when a team is selected in the Package Explorer.
+ </li>
+ </ul></dd>
+ <dt><strong>The Hierarchy View</strong></dt>
+ <dd><ul>
+ <li>Object Teams intruduce a new type hierarchy. Besides the normal ("<code>extends</code>") inheritance, there is an additional "<em>implicit</em>" role inheritance, established by role name equality in a team hierarchy. In conjunction with team nesting roles support a controlled form of multiple inheritance.
+ </li>
+ <li>
+ The new implicit inheritance has been integrated completely into the standard JDT
+ <em>Hierarchy View</em>.
+ </li>
+ </ul></dd>
+ </dl>
+
+
+ <div id="search" class="headl"><div class="headr">
+ <h1>Search</h1>
+ </div></div>
+ <p></p>
+ <dl>
+ <dt><strong>Search references</strong></dt>
+ <dd><ul><li>The Java Search functionality has been extended to include search results of
+ Object Teams code, that is, callin and callout bindings, and
+ playedBy-relationships.</li></ul></dd>
+ <dt><strong>Call hierarchy</strong></dt>
+ <dd><ul><li>Also the call hierarchy has been extended for browsing control flows passing
+ through method bindings (callin and callout).</li>
+ <li>The OTDT introduced support for call hierarchies regarding field accesses (read, write, any) and class instantiations. As of version 3.4 this functionality has been adopted by Eclipse.</li>
+ </ul>
+ </dd>
+ </dl>
+ <p></p>
+
+ <div id="execution" class="headl"><div class="headr">
+ <h1>Execution Environment</h1>
+ </div></div>
+ <dl>
+ <dt><strong>Aspect weaving</strong></dt><dd>
+ <ul><li>
+ All aspect oriented languages have some kind of <em>weaving process</em>, where the aspect code is combined with the other (<em>base</em>) code.
+ </li>
+ <li>
+ Object Teams programs perform the weaving at application <em>startup time</em>, i.e. at the moment, the program is launched. In order to do this, there is the so-called <em>Object Teams Runtime Environment (OTRE)</em>, that wraps around the standard launching procedure.
+ </li>
+ <li>
+ All this is handled transparently using the standard Eclipse "Run" feature.
+ Running any main class of an Object Teams project automatically includes
+ the OTRE (This feature has been <a href="new_in_1.3.html#launch">changed in the OTDT 1.2.2</a>).
+ </li>
+ </ul></dd>
+ <dt><strong>Aspect deployment/activation</strong></dt>
+ <dd><ul>
+ <li>A new "Team Activation" tab in the "Run-Configuration" allows to instantiate and activate teams without modifying the program's source code.
+ </li>
+ <li>
+ Teams that cause aspect code to be woven into an application can be added to a program
+ <ul>
+ <li> by explicit reference within the program source code or</li>
+ <li> by a configuration file which is mentioned as a parameter to the VM or</li>
+ <li> by adding them via the aforementioned "Team Activation" tab.</li>
+ </ul>
+ No such configuration is needed for compilation.
+ </li>
+ </ul>
+ </dd>
+ <dt><strong>Technology used</strong></dt>
+ <dd><ul>
+ <li id="JPLIS">Integrating the weaver into the JVM leverages the Java-agent concept of Java 5
+ (<a href="http://java.sun.com/developer/technicalArticles/releases/j2se15/index.html">JPLIS</a>).
+ (<i>The original implementation using the JMangler framework is no longer maintained</i>).<br/>
+ In the future this integration will support aspect weaving not only at load time
+ but also while an application is running.
+ </li>
+ </ul></dd>
+ </dl>
+ <p></p>
+
+ <div id="otequinox" class="headl"><div class="headr">
+ <h1>OT/Equinox</h1>
+ </div></div>
+ <p></p>
+ Starting with the OTDT version 0.9.9 (2006) it is possible to develop Eclipse plugins using
+ OT/J as the implementation language.
+ <ul>
+ <li>Using the plugin <code>org.eclipse.objectteams.otequinox</code>, a plugin ("aspect plugin")
+ may declare that it adapts classes from a specified other plugin ("base plugin").</li>
+ <li>By an integration of the Object Teams Runtime Environment with hooks in the
+ Equinox implementation a <code class="keyword">team</code> class from an <em>aspect plugin</em>
+ can trigger byte-code aspect weaving into its <em>base plugin</em> at load-time.
+ As a result an aspect plugin can indeed adapt the behaviour of another plugin.
+ These bindings are declared using the extension point <code>aspectBindings</code> from
+ the mentioned plugin <code>org.eclipse.objectteams.otequinox</code>.</li>
+ <li>The initial client of the OT/Equinox technology is a tiny plugin which extends Eclipse's
+ "about plugins" dialog by additionally displaying which plugins are being adapted by
+ which aspect plugins. This information is found in the version column of the mentioned dialog.
+ This way a user of the OTDT can always check whether a given plugin performs as shipped,
+ or whether it has been adapted by another plugin.</li>
+ <li>The OTDT uses the capabilities of OT/Equinox for its own implementation.
+ The technology is mainly used for making the JDT-UI aware of Object Teams without having
+ to copy source code or modifying source code of the JDT-UI in place.</li>
+ <li>A new project nature <img class="inline" alt="" src="../images/newpprj_wiz.gif"/>
+ <code>Object Teams Plugin Project</code> is provided, supporting the
+ development of plugins written in OT/J.</li>
+ <li>Support for OT/Equinox is added to the run/debug dialogs for all Equinox related launches.</li>
+ <li>If desired the load-time weaver can be disabled by commenting out or removing the following
+ line from the file <code>configuration/config.ini</code>:
+ <div class="ttindent" style="font-size:small;">
+ osgi.hook.configurators.include=org.eclipse.objectteams.otequinox.hook.HookConfigurator</div>
+ Ideally, disabling OT/Equinox will be handled by temporarily uninstalling this feature,
+ but the required support by the p2 provisioning system is not yet stable enough to do this.</li>
+ </ul>
+ <p></p>
+
+ <div id="debugging" class="headl"><div class="headr">
+ <h1>Debugging</h1>
+ </div></div>
+ <p></p>
+ The debugger has been enhanced to support debugging of OT/J programs at the
+ source code level. It is possible to set breakpoints and step through Object Teams code.
+
+ <dl>
+ <dt><b>Stepping through Code</b></dt>
+ <dd>The following language features produce byte codes for which a standard Java debugger
+ is not able to display appropriate source locations:
+ <ul>
+ <li>Role files (<a href="otjld/def/s1.html#s1.2.5"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 1.2.5</a>)</li>
+ <li>Implicit inheritance (<a href="otjld/def/s1.html#s1.3.1"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 1.3.1</a>)</li>
+ <li>Callout bindings (<a href="otjld/def/s3.html"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 3</a>)
+ (including callout override (<a href="otjld/def/s3.html#s3.1.e"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 3.1(e)</a>))</li>
+ <li>Callin bindings (<a href="otjld/def/s4.html"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 4</a>)</li>
+ </ul>
+ The OTDT-Debugger re-maps the byte codes produced by all this constructs to the
+ appropriate source locations.
+ As a result stepping through these sections of a program completely hides
+ the internal translations from the user.<p></p>
+ The following features are not yet fully supported by the debugger:
+ <ul>
+ <li>Role constructors (see <a href="otjld/def/s2.html#s2.4"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 2.4</a>)</li>
+ <li>Parameters with declared lifting (<a href="otjld/def/s2.html#s2.3.2"><img alt="" src="../images/ot_paragraph.png"/>
+ OTJLD § 2.3.2</a> — code for lifting is not filtered out yet)</li>
+ </ul></dd>
+ <dt><b>Setting Breakpoints</b></dt>
+ <dd>Use double click on ruler or context menu <code>Toggle Breakpoint</code> to set
+ breakpoints in OT/J-Code. Setting breakpoint in role files is supported, too.</dd>
+ <dt id="team_monitor"><b>New View: "Team Monitor"</b></dt>
+ <dd>The team monitor (<img src="../images/tm.gif" alt="" class="inline"/>)
+ view helps to debug issues related to team activation
+ (<a href="otjld/def/s5.html#s5"><img alt="" src="../images/ot_paragraph.png"/> OTJLD § 5</a>).
+ For this purpose it displays all known team instances and shows their activation status as one of
+ <ul>
+ <li>inactive <img src="../images/team_inact.gif" alt="" class="inline"/>,</li>
+ <li>active <img src="../images/team_act.gif" alt="" class="inline"/>
+ (either globally or for the thread selected in the debug view), or</li>
+ <li>implicitly active
+ <img src="../images/team_act_implicit.gif" alt="" class="inline"/>
+ (temporarily active because the team or one of its roles is currently executing code).
+ </li></ul>
+ Also, a selected team can be (de)activated interactively via the context menu.</dd>
+ <dt id="variables_filter"><b>Filtering variables</b></dt>
+ <dd>The OT/J compiler and the loadtime weaver both add some internal variables to the code.
+ By default such internal variables are hidden within the Team Monitor as well
+ as in the standard variables view. Both views can be configured to also show these internal
+ variables if so desired.</dd>
+ <dt><b>Known Issues and Limitations</b></dt>
+ <dd><ul>
+ <li>Dynamic code evaluation is not supported yet,
+ make sure to clear the Expression view.</li>
+ <li>Hot code replacement of woven code is not supported.</li>
+ </ul></dd>
+ </dl>
+
+ <div id="help" class="headl"><div class="headr">
+ <h1>Help and additional Information</h1>
+ </div></div>
+ <p></p>
+ The following sources for help and for further information are bundled with the release:
+ <ul>
+ <li>A Tutorial (available via the welcome page) guiding through the first steps of using the OTDT.</li>
+ <li>Example programs demonstrating key features of Object Teams (also via the welcome page).</li>
+ <li>A detailed <a href="guide/webindex.html">guide</a> on using the OTDT via the Help Index, including a link to the
+ language definition (which is also bundled).</li>
+ <li>Problems that are listed in the problem view are linked (when possible) to a corresponding explanatory entry in the language definition.
+ (Context menu -> <img alt="" src="../images/ot_paragraph.png"/><code> Go to Language Definition</code>).</li>
+ </ul>
+ </div><!-- content -->
+ </body>
+</html>
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/add_correction.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/add_correction.gif
new file mode 100644
index 0000000..ee809ad
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/add_correction.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/brkp_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/brkp_obj.gif
new file mode 100644
index 0000000..a831fe7
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/brkp_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/bug.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/bug.gif
new file mode 100644
index 0000000..ac5431f
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/bug.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/bundle_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/bundle_obj.gif
new file mode 100644
index 0000000..b6096e2
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/bundle_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/debugt_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/debugt_obj.gif
new file mode 100644
index 0000000..c1e4ee3
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/debugt_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/disconnect_co.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/disconnect_co.gif
new file mode 100644
index 0000000..d8fdd8a
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/disconnect_co.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/eclipse_launcher.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/eclipse_launcher.gif
new file mode 100644
index 0000000..eb7b90c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/eclipse_launcher.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/java_app.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/java_app.gif
new file mode 100644
index 0000000..a42a7c8
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/java_app.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/java_attach.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/java_attach.gif
new file mode 100644
index 0000000..3c42f63
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/java_attach.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/julaunch.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/julaunch.gif
new file mode 100644
index 0000000..ec4885d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/julaunch.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/julaunchpgn.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/julaunchpgn.gif
new file mode 100644
index 0000000..6e4ff2c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/julaunchpgn.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/junit.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/junit.gif
new file mode 100644
index 0000000..229e93f
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/junit.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/library_obj.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/library_obj.gif
new file mode 100644
index 0000000..cb55e33
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/library_obj.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/otdt/ot_paragraph.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/otdt/ot_paragraph.png
new file mode 100644
index 0000000..d540c89
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/otdt/ot_paragraph.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/over_co.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/over_co.gif
new file mode 100644
index 0000000..938767b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/over_co.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/AspectBindingsInPackageExplorer.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/AspectBindingsInPackageExplorer.png
new file mode 100644
index 0000000..377d0c5
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/AspectBindingsInPackageExplorer.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_AddTypeBinding.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_AddTypeBinding.png
new file mode 100644
index 0000000..4f46daf
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_AddTypeBinding.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_FlightBonus.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_FlightBonus.png
new file mode 100644
index 0000000..03694b0
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_FlightBonus.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_ParameterMappings.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_ParameterMappings.png
new file mode 100644
index 0000000..8af887d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/BindingEditor_ParameterMappings.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CallHierarchy.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CallHierarchy.png
new file mode 100644
index 0000000..139b69e
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CallHierarchy.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CompareMenu.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CompareMenu.png
new file mode 100644
index 0000000..2745c2d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CompareMenu.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CompareWithBaseMethod.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CompareWithBaseMethod.png
new file mode 100644
index 0000000..5922bd2
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/CompareWithBaseMethod.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/ForcedExports.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/ForcedExports.png
new file mode 100644
index 0000000..1cdfaee
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/ForcedExports.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/GoToLangDefGutter.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/GoToLangDefGutter.png
new file mode 100644
index 0000000..5a86a56
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/GoToLangDefGutter.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/GoToLangDefHover.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/GoToLangDefHover.png
new file mode 100644
index 0000000..a4f9a3c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/GoToLangDefHover.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/JRETab.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/JRETab.png
new file mode 100644
index 0000000..5f31ab0
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/JRETab.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/AddPrecedenceAfter-QuickFix.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/AddPrecedenceAfter-QuickFix.png
new file mode 100644
index 0000000..0945e1e
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/AddPrecedenceAfter-QuickFix.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/AddSignatures-QuickAssist.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/AddSignatures-QuickAssist.png
new file mode 100644
index 0000000..b264144
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/AddSignatures-QuickAssist.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorBaseCallout.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorBaseCallout.png
new file mode 100644
index 0000000..7d3769f
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorBaseCallout.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorCalloutToField1.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorCalloutToField1.png
new file mode 100644
index 0000000..3efda37
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorCalloutToField1.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorCalloutToField2.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorCalloutToField2.png
new file mode 100644
index 0000000..79297f1
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/BindingEditorCalloutToField2.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ChangeSignature2.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ChangeSignature2.png
new file mode 100644
index 0000000..863edd0
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ChangeSignature2.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding1.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding1.png
new file mode 100644
index 0000000..1573b83
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding1.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding2.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding2.png
new file mode 100644
index 0000000..02bdb76
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding2.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding3.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding3.png
new file mode 100644
index 0000000..2f048b3
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/CreateMethodBinding3.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/GoToLangDefGutter.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/GoToLangDefGutter.png
new file mode 100644
index 0000000..5a86a56
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/GoToLangDefGutter.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/GoToLangDefHover.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/GoToLangDefHover.png
new file mode 100644
index 0000000..a4f9a3c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/GoToLangDefHover.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/MoreDebugColoring.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/MoreDebugColoring.png
new file mode 100644
index 0000000..183bc3e
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/MoreDebugColoring.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/OverrideRole.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/OverrideRole.png
new file mode 100644
index 0000000..2da53a1
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/OverrideRole.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ProjectErrors.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ProjectErrors.png
new file mode 100644
index 0000000..48922d8
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ProjectErrors.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ProjectMigration-QuickFix.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ProjectMigration-QuickFix.png
new file mode 100644
index 0000000..0afe364
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/ProjectMigration-QuickFix.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/RemoveSignatures-QuickAssist.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/RemoveSignatures-QuickAssist.png
new file mode 100644
index 0000000..d5e6903
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/RemoveSignatures-QuickAssist.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/RunJRE-OTRE.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/RunJRE-OTRE.png
new file mode 100644
index 0000000..29481d5
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/RunJRE-OTRE.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/Variables_Base.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/Variables_Base.png
new file mode 100644
index 0000000..679b7ef
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/Variables_Base.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/othierarchy.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/othierarchy.png
new file mode 100644
index 0000000..c38dc30
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN07/othierarchy.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CalloutToFieldSeverity.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CalloutToFieldSeverity.png
new file mode 100644
index 0000000..4974fea
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CalloutToFieldSeverity.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CompilerPreferences.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CompilerPreferences.png
new file mode 100644
index 0000000..b5c2360
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CompilerPreferences.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CreateRoleMethodQuickfix.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CreateRoleMethodQuickfix.png
new file mode 100644
index 0000000..38548ab
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/CreateRoleMethodQuickfix.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface1.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface1.png
new file mode 100644
index 0000000..72c17e8
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface1.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface2.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface2.png
new file mode 100644
index 0000000..1799b88
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface2.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface3.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface3.png
new file mode 100644
index 0000000..3752d5a
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/NN08/ExtractInterface3.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/OSGiLaunchSettings.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/OSGiLaunchSettings.png
new file mode 100644
index 0000000..b42806c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/OSGiLaunchSettings.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/OverrideRole.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/OverrideRole.png
new file mode 100644
index 0000000..2da53a1
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/OverrideRole.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RemoteDebugging.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RemoteDebugging.png
new file mode 100644
index 0000000..a9ab7a9
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RemoteDebugging.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RemoveSignatures-QuickAssist.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RemoveSignatures-QuickAssist.png
new file mode 100644
index 0000000..d5e6903
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RemoveSignatures-QuickAssist.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RuntimeWorkbenchMainTab.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RuntimeWorkbenchMainTab.png
new file mode 100644
index 0000000..70fc20b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/RuntimeWorkbenchMainTab.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/addOTNature.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/addOTNature.png
new file mode 100644
index 0000000..96b546f
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/addOTNature.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinMarker.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinMarker.jpg
new file mode 100644
index 0000000..ba523f3
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinMarker.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarker-menu.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarker-menu.png
new file mode 100644
index 0000000..82c2ed6
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarker-menu.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarker-menu3.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarker-menu3.png
new file mode 100644
index 0000000..9898d94
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarker-menu3.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarkers.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarkers.png
new file mode 100644
index 0000000..ca31ef0
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/callinmarkers.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/calloutmarker.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/calloutmarker.png
new file mode 100644
index 0000000..df2792f
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/calloutmarker.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_1.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_1.png
new file mode 100644
index 0000000..06c014c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_1.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_2.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_2.png
new file mode 100644
index 0000000..47bd64d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_2.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_3.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_3.png
new file mode 100644
index 0000000..c469fc5
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/complete_binding_3.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/completion1.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/completion1.png
new file mode 100644
index 0000000..03e1c98
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/completion1.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/debug_prefs_callin_stepping.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/debug_prefs_callin_stepping.png
new file mode 100644
index 0000000..9aacadd
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/debug_prefs_callin_stepping.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/debug_prefs_filtering.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/debug_prefs_filtering.png
new file mode 100644
index 0000000..2415cad
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/debug_prefs_filtering.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/implicitRoleHierarchy.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/implicitRoleHierarchy.jpg
new file mode 100644
index 0000000..9fb553c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/implicitRoleHierarchy.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/langdef.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/langdef.png
new file mode 100644
index 0000000..ceb99ad
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/langdef.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/launchConfig.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/launchConfig.jpg
new file mode 100644
index 0000000..2e3e404
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/launchConfig.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/launchConfig.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/launchConfig.png
new file mode 100644
index 0000000..9a7f728
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/launchConfig.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/outline.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/outline.jpg
new file mode 100644
index 0000000..30d0be8
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/outline.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer.jpg
new file mode 100644
index 0000000..ec54eb2
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer.png
new file mode 100644
index 0000000..ee7a1c2
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer_logical.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer_logical.png
new file mode 100644
index 0000000..317090b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/packageExplorer_logical.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/perspective.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/perspective.jpg
new file mode 100644
index 0000000..46d5145
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/perspective.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/perspective.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/perspective.png
new file mode 100644
index 0000000..8f82b02
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/perspective.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/projectWizard.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/projectWizard.jpg
new file mode 100644
index 0000000..3f421b5
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/projectWizard.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/roleWizard.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/roleWizard.jpg
new file mode 100644
index 0000000..dafeb96
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/roleWizard.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_entered_callin.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_entered_callin.png
new file mode 100644
index 0000000..dc0158e
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_entered_callin.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_entered_earnCredit.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_entered_earnCredit.png
new file mode 100644
index 0000000..9c38c64
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_entered_earnCredit.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_hit_callin.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_hit_callin.png
new file mode 100644
index 0000000..ad6bfb8
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_hit_callin.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_lifting.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_lifting.png
new file mode 100644
index 0000000..28d86cc
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/stack_lifting.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/teamWizard.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/teamWizard.jpg
new file mode 100644
index 0000000..44cc2f9
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/teamWizard.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/team_monitor_marked.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/team_monitor_marked.png
new file mode 100644
index 0000000..9e35920
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/team_monitor_marked.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/typeHierarchy.jpg b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/typeHierarchy.jpg
new file mode 100644
index 0000000..e90444d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/screenshots/typeHierarchy.jpg
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepinto_co.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepinto_co.gif
new file mode 100644
index 0000000..75d165b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepinto_co.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepover_co.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepover_co.gif
new file mode 100644
index 0000000..1ec36ae
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepover_co.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepreturn_co.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepreturn_co.gif
new file mode 100644
index 0000000..4c2f219
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/stepreturn_co.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_act.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_act.gif
new file mode 100644
index 0000000..58a8638
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_act.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_act_implicit.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_act_implicit.gif
new file mode 100644
index 0000000..41dc6c2
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_act_implicit.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_inact.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_inact.gif
new file mode 100644
index 0000000..2b5ea0d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/images/team_inact.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/methodcompare.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/methodcompare.html
new file mode 100644
index 0000000..756ac83
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/methodcompare.html
@@ -0,0 +1,42 @@
+<html>
+<head>
+ <meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
+ <link rel=stylesheet type="text/css" href="../css/book.css">
+ <link rel=stylesheet type="text/css" href="otguide.css">
+ <title>Comparing Bound Methods</title>
+ <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+</head>
+<body>
+<h1>Comparing Bound Methods</h1>
+
+
+
+<table><tr><td width="320" valign="top">
+ <p>
+ <strong>The OTDT provides a special action for comparing a role method with the base method to which it is bound.</strong>
+ </p>
+ <p>
+ To invoke this action the <strong>context menu</strong> of a callin method binding (in package explorer or outline)
+ is used: <span class="ui"><nobr>Compare With > <img src="../images/callinbindingreplace_obj.gif"> Bound Base Method</nobr></span>.
+ Alternatively, the context menu can also be used on a <code class="keyword">callin</code> method.
+ </p>
+ <p>
+ When invoked this action opens a <strong>compare editor</strong>, the left hand side showing the role method
+ and the right hand side showing the bound base method.
+ The role method is editable whereas the base method is shown read-only.
+ </p>
+ <p>
+ The action is most useful for <code class="keyword">callin</code> methods that are created
+ by copying the base method in order to apply fine grained modifications.
+ In this situation the compare editor can be used to inspect and update the modifications
+ as well as adopt any changes that might have occurred to the base method during evolution.
+ </p>
+ </td>
+ <td>
+ <img alt="Compare menu" src="images/screenshots/CompareMenu.png">
+ </td></tr></table>
+ <p>
+ <img alt="Compare editor for bound methods" src="images/screenshots/CompareWithBaseMethod.png">
+ </p>
+</body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_0.7.1.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_0.7.1.html
new file mode 100644
index 0000000..b96821e
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_0.7.1.html
@@ -0,0 +1,230 @@
+<!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">• 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><p align="right"><b>Traditional Hierarchy View</b><br>
+ <span class="since">since 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 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"><- 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 0.7.1</span><br>
+ <a class="buglink" title="[refactoring] adapt "change signature" 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 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 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 0.7.1</span><br>
+ <a class="buglink" title="[otjld] [compiler] Support the "Internal Role" 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 §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 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 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>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_0.7.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_0.7.html
new file mode 100644
index 0000000..55ae0fc
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_0.7.html
@@ -0,0 +1,359 @@
+<!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>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_2.0.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_2.0.html
new file mode 100644
index 0000000..50a659b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/news/new_in_2.0.html
@@ -0,0 +1,220 @@
+<!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.0.0 - New and Noteworthy</title>
+</head>
+<body>
+<h1>OTDT 2.0.0 - New and Noteworthy</h1>
+<div class="navigation"><i>Changes since the 0.7.1 Release</i></div>
+<div style="width:40%; padding:2px;background-color:#707070;"><div style="text-align:justify;background-color:#def4fe;padding:3px;">
+Note, that milestones towards the 2.0.0 release where named 0.8.0M<i>x</i>.
+The switch in version numbers has been made between 0.8.0M7 and 2.0.0 RC1 in preparation for the project's graduation from incubation status.
+</div></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><p align="right"><b>Compiler preferences page cleaned up</b><br>
+ <span class="since">since 0.8.0M5</span><br>
+ <a class="buglink" title="cleanup OT/J compiler preferences page" href="https://bugs.eclipse.org/335739">335739</a></p></td>
+ <td><p>The preference page for OT/J compiler options has be revamped following recent improvements in the JDT UI.
+ The page is now structured into expandable sections per group of problems.
+ Also incremental search within the tree of options is supported.
+ The option to disable "scoped keywords" was apparently never used and has been removed from the preferences.
+ </p>
+ <p><img alt="OT/J Compiler preferences" src="../images/screenshots/NN08/CompilerPreferences.png"></p>
+ <p></p>
+ </td>
+ </tr>
+
+ <tr><td colspan="2" id="assist"><h2>Content assist</h2></td></tr>
+ <tr>
+ <td><p align="right"><b>Create role method quickfix</b><br>
+ <span class="since">since 0.8.0M4</span><br>
+ <a class="buglink" title="Quickfix method generation on missing replace callin method generates wrong method" href="https://bugs.eclipse.org/329988">329988</a></p></td>
+ <td><p>If a role class has a callin binding whose left-hand side does not resolve to an existing role method
+ a quickfix exists for creating the missing role method.
+ Since 0.8.0M4 this quickfix respects the signature of the bound base method even if the callin binding does not declare any signatures
+ (see the <b>int</b> parameter and return in the screenshot below):
+ </p>
+ <p><img alt="Create Role Method Quickfix" src="../images/screenshots/NN08/CreateRoleMethodQuickfix.png"></p>
+ <p></p>
+ </td>
+ </tr>
+ <tr><td colspan="2" id="refactor"><h2>Refactoring</h2></td></tr>
+ <tr>
+ <td><p align="right"><b>Extract role interface</b><br>
+ <span class="since">since 0.8.0M6</span><br>
+ <a class="buglink" title="extract interface on a role should create a role interface" href="https://bugs.eclipse.org/339264">339264</a></p></td>
+ <td><p>A new option has been added to the Extract Interface refactoring:
+ If the enclosing class is a role class a new check box appears:
+ </p>
+ <p><img alt="Extract as role interface checkbox" src="../images/screenshots/NN08/ExtractInterface1.png"></p>
+ <p>If this box is checked the new interface will not be created as a top-level type (as normally done by the JDT),
+ but as a role interface of the current enclosing team.</p>
+ <p><img alt="Extract as role interface preview" src="../images/screenshots/NN08/ExtractInterface2.png"></p>
+ <p>The refactored result looks like this</p>
+ <p><img alt="Extract as role interface result" src="../images/screenshots/NN08/ExtractInterface3.png"></p>
+ </td>
+ </tr>
+<!--
+ <tr><td colspan="2" id="debug"><h2>Run / Debug</h2></td></tr>
+ <tr><td colspan="2" id="api"><h2>API</h2></td></tr>
+-->
+ </tr> <tr><td colspan="2" id="language"><h2>Language</h2></td></tr>
+ <tr>
+ <td><p align="right"><b>Precedence among tsupers</b><br>
+ <span class="since">since 0.8.0M3</span><br>
+ <a class="buglink" title="[compiler] implement changed precedence among different tsupers" href="https://bugs.eclipse.org/326969">326969</a></p></td>
+ <td><p>
+ Previously, <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s1.html#s1.5.e">OTJLD §1.5(e)</a>
+ was inconsistent between its first and second sentences.
+ The first sentence defines the general precendence between <code class="keyword">super</code> and <code class="keyword">tsuper</code>,
+ which will remain unchanged.
+ However, the precendence among different tsupers has been adjusted as demonstrated using this example:
+ <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">Team0</font> {
+ <code class="keyword">protected team class</code> <font color="darkblue">InnerTeamA</font> {
+ <code class="keyword">protected class</code> <b>Role</b> {
+ <code class="keyword">public void</code> rm() { ... }
+ }
+ <code class="keyword">public void</code> tm() { ... }
+ }
+ <code class="keyword">protected team class</code> InnerTeamB <code class="keyword">extends</code> <font color="darkblue">InnerTeamA</font> {
+ <code class="keyword">protected class</code> <b>Role</b> {
+ <code class="keyword">public void</code> rm() { ... }
+ }
+ <code class="keyword">public void</code> tm() { ... }
+ }
+}
+<code class="keyword">public team class</code> <font color="blue">Team1 <code class="keyword">extends</code> Team0</font> {
+ <code class="keyword">protected team class</code> <font color="darkblue">InnerTeamA</font> {
+ <code class="keyword">protected class</code> <b>Role</b> {
+ <code class="keyword">public void</code> rm() { ... }
+ }
+ <code class="keyword">public void</code> tm() { ... }
+ }
+ <code class="keyword">protected team class</code> <font color="darkblue">InnerTeamB</font> <code class="keyword">extends</code> <font color="darkblue">InnerTeamA</font> {
+ <font color="green">// details inherited from Team1.InnerTeamA and Team0.InnerTeamB</font>
+ }
+}
+</pre></div></div>
+ When invoking <code>tm()</code> on an instance of <code>Team1.InnerTeamB</code> two implementation are
+ candidates for execution:<ul>
+ <li><code>Team1.InnerTeamA.tm()</code></li>
+ <li><code>Team0.InnerTeamB.tm()</code>,</li></ul>
+ from which <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s1.html#s1.5.e">OTJLD §1.5(e)</a>
+ selects <code>Team0.InnerTeamB</code>.<br />
+ Correspondingly, when invoking <code>rm()</code> on an instance of <code>Team1.InnerTeamB.R</code> two implementation are
+ candidates for execution:<ul>
+ <li><code>Team1.InnerTeamA.Role.rm()</code></li>
+ <li><code>Team0.InnerTeamB.Role.rm()</code>,</li></ul>
+ from which <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s1.html#s1.5.e">OTJLD §1.5(e)</a>
+ now selects <code>Team0.InnerTeamB.Role</code>, consistent with the above.
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td><p align="right"><b>Avoid role cache</b><br>
+ <span class="since">since 0.8.0M6</span><br>
+ <a class="buglink" title="consider optimization by avoiding the role cache" href="https://bugs.eclipse.org/338582">338582</a></p></td>
+ <td><p>
+ It has been observed that maintaining a large number of roles in the team's internal cache may have significant
+ impact on program performance (observed at 100000 roles of one particular type).
+ A new means for fine tuning has been added for situations where role identity is irrelevant.
+ A role class may now be marked with <code>@Instantiation(ALWAYS)</code> meaning that each lifting operation for this role class
+ will immediately create a new role instance without consulting the role cache. In fact such roles will never be stored in
+ any internal cache. Please read the implications discussed in <a href="http://www.objectteams.org/def/1.3/s2.html#s2.3.1.d">OTJLD §2.3.1(d)</a>.
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td id="bug337413"><p align="right"><b>Dealing with lifting problems</b><br>
+ <span class="since">since 2.0RC1</span><br>
+ <a class="buglink" title="consider changing LiftingFailedException to a checked exception" href="https://bugs.eclipse.org/337413">337413</a></p></td>
+ <td><p>Whenever lifting fails (due to a role binding ambiguity or an abstract relevant role) a <code>LiftingFailedException</code> is thrown
+ from the Object Teams runtime. This exception has now been changed to a checked exception to alert clients of problematic code
+ of the chance of failure. The consequences are defined in the new section
+ <a class="otjldlink" href="http://www.objectteams.org/def/1.3/s2.html#s2.3.5">OTJLD §2.3.5</a>.
+ </p>
+ <p>The compiler now has two general ways to signal lifting problems:
+ <ul>
+ <li>Unhandled exception LiftingFailedException</code></li>
+ <li>Unsafe callin mapping, because lifting to role {0} may fail due to ...</li>
+ </ul>
+ <strong>If none of these messages are given, lifting can be assumed to be safe.</strong>
+ </p>
+ <p>Application code with lifting problems may choose from different strategies:
+ <ul>
+ <li>Avoid abstractness for bound roles:
+ <ul><li>Add method bodies which log the problem.<br/>
+ Benefit: unexpected situations will actually be detected.</li>
+ <li>Remove abstract methods and require clients to cast to a specific role type.<br/>
+ Benefit: client is now clearly repsonsible for dealing with potential <code>ClassCastException</code>
+ in cases where lifting produces an unexpected result.</li>
+ </ul></li>
+ <li>Team methods with declared lifting may choose to declare <code>LiftingFailedException</code><br/>
+ Benefit: client is alerted of the chance of failure, must handle unexpected situations.</li>
+ <li>Callin bindings with unsafe lifting may in special situations pass through using
+ <code>@SuppressWarnings("hidden-lifting-problem")</code><br/>
+ Benefit: owner of the role has to explicitly assert that s/he is aware of the chance that
+ the callin binding will not fire due to a lifting problem.</li>
+ <li>Revise the role hierarchy to avoid abstract relevant roles and potential binding ambiguities.</li>
+ </ul>
+ </p>
+ </td>
+ </tr>
+ <tr><td colspan="2" id="compiler"><h2>Compiler</h2></td></tr>
+ <tr>
+ <td><p align="right"><b>Severity of write decapsulation</b><br>
+ <span class="since">since 0.8.0M5</span><br>
+ <a class="buglink" title="separate tuning of severity of decapsulation in "set" callout-to-field" href="https://bugs.eclipse.org/335523">335523</a></p></td>
+ <td><p>When a role uses a callout <code class="keyword">set</code> to field with decapsulation this may be considered more severe
+ than a corresponding <code class="keyword">get</code> access. Therefor, the compiler now supports separate configurability for both
+ kinds of problems.
+ </p>
+ <p><img alt="Callouts to field with different severity" src="../images/screenshots/NN08/CalloutToFieldSeverity.png"></p>
+ <p></p>
+ </td>
+ </tr>
+
+<!--
+ <tr><td colspan="2" id="otre"><h2>Object Teams Runtime Environment</h2></td></tr>
+-->
+</table>
+</body>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otguide.css b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otguide.css
new file mode 100644
index 0000000..77c7bba
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otguide.css
@@ -0,0 +1,2 @@
+.ui { background-color:#e0e0e0; padding:2px; }
+body { margin:10px; }
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/ot.css b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/ot.css
new file mode 100644
index 0000000..ca9fe52
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/ot.css
@@ -0,0 +1,606 @@
+/**
+ * @author mosconi
+ */
+
+/**
+ * color table
+ * light-yellow: #fffce4
+ * light-gray: #e0e0f0
+ * violet: #606080
+ * light-violet: #9090b0
+ */
+
+/* page initialization */
+html,body {
+ /* overflow: auto; */ /* this caused Firefox to not display long pages correctly */
+ padding: 0;
+ margin: 0;
+ margin-bottom: 4px;
+ border: 0;
+ font-family: helvetica, avalon, sans-serif;
+ /* font-size: 12pt; */
+}
+
+img {
+ border-style: none;
+}
+
+h4 {
+ color: #000060;
+}
+
+dt {
+ margin-top: 10px;
+}
+
+dd {
+ margin-bottom: 10px;
+}
+
+/* hyperlinks */
+a:link {
+ color: #3010ff;
+ text-decoration: none;
+}
+
+a:visited {
+ color: #5060f7;
+ text-decoration: none;
+}
+
+a:focus {
+
+}
+
+a:hover {
+ color: black;
+ background-color: #e8e8fc;
+ text-decoration: none;
+}
+
+a:active {
+
+}
+
+a img,a.img {
+ border-style: none;
+ background-color: transparent;
+}
+
+a.nohover:hover {
+ background-color: transparent;
+}
+
+/* top page area (horizontal) */
+#head {
+ position: absolute; /* switched to 'fixed' by javascript dynamically */
+ top: 0;
+ left: 0;
+ height: 80px; /* defines header height */
+ width: 100%;
+ margin: 0;
+ padding: 0;
+ border: 0;
+ border-bottom: solid 2px #e0e0f0; /* light-gray */
+ background-color: #fffce4; /* light-yellow */
+ background-image: url(../images/WebHeadBar.png);
+ background-position: top;
+ background-repeat: repeat-x;
+ z-index: 5;
+}
+
+/* page heading (title) */
+#head h1 {
+ margin: 0;
+ margin-top: 40px; /* vertically centered in head */
+ padding: 0;
+ text-align: center;
+ font-size: 18pt;
+ white-space: nowrap;
+}
+
+/* left page area (vertical) - contains logo */
+#left {
+ position: fixed;
+ top: 0;
+ left: 0;
+ width: 191px; /* image size */
+ height: 100%;
+ overflow: auto;
+ border: 0;
+ border-right: solid 2px #e0e0f0; /* light-gray */
+ background-color: #fffce4; /* light-yellow */
+ background-image: url(../images/WebHead1.png);
+ background-position: left top;
+ background-repeat: no-repeat;
+ background-attachment: scroll;
+ z-index: 6;
+}
+
+/* right part of the logo */
+#logo {
+ position: absolute; /* switched to 'fixed' by javascript dynamically */
+ top: 0;
+ left: 191px; /* width of #left */
+ width: 49px; /* image size */
+ height: 80px; /* height of #head */
+ border: 0;
+ background-color: #fffce4; /* light-yellow */
+ background-image: url(../images/WebHead2.png);
+ background-position: left top;
+ background-repeat: no-repeat;
+ z-index: 7;
+}
+
+/* rounded top left corner of content area */
+#corner {
+ position: absolute; /* switched to 'fixed' by javascript dynamically */
+ top: 80px; /* height of #head */
+ left: 191px; /* width of #left */
+ width: 30px; /* image size */
+ height: 30px; /* image size */
+ border: 0;
+ background-image: url(../images/bend-trans.png);
+ background-repeat: no-repeat;
+ z-index: 9;
+}
+
+#head.fixed,#logo.fixed,#corner.fixed,#metanav.fixed,#ctxtnav.fixed,#search.fixed {
+ /* class applied by javascript dynamically */
+ position: fixed;
+ overflow: none;
+}
+
+/* content page area */
+#content,#footer {
+ position: static;
+ padding-left: 15px;
+ padding-right: 15px;
+ padding-bottom: 0;
+ padding-top: 97px; /* height of #head (+ border) + 15 padding */
+ /* more compatible than margin-top */
+ margin-left: 193px; /* width of #left (+ border) */
+ border: 0;
+ z-index: 1;
+}
+
+/* page footer: */
+#footer {
+ padding-top: 0;
+ padding-bottom: 10px;
+ margin-bottom: 10px;
+ font-size: 10pt;
+ color: gray;
+}
+
+.w3c {
+ float: right;
+}
+
+/* navigation box - specializes div.box */
+#nav-box {
+ top: 120px;
+}
+
+#nav-box ul {
+ margin-top: -7px;
+}
+
+#nav-box li {
+ background: url(../images/arrow-right-trans.png) no-repeat left 50%;
+ padding-left: 23px;
+}
+
+#nav-box li:hover {
+ background: #e8e8fc url(../images/arrow-right2-trans.png) no-repeat left 50%;
+}
+
+#nav-box li.active {
+ background: #e8e8fc url(../images/arrow-right2-trans.png) no-repeat left 50%;
+ /* border-right: solid 4px #606080; */
+ margin-right: -4px;
+}
+
+#nav-box dt {
+ font-size: 8pt;
+ margin-top: -2px;
+ margin-bottom: 0;
+ margin-left: 35px;
+ padding: 0px;
+}
+
+#nav-box a:link,#nav-box a:visited {
+ border-bottom: none;
+}
+
+/* news box - specializes div.box */
+#news-box {
+ top: 180px;
+ font-size: 9pt;
+}
+
+#news-box ul a {
+ margin-bottom: 5px;
+ padding-bottom: 5px;
+ border-bottom: solid 1px #e0e0f0; /* light-gray */
+ color: #000000;
+}
+
+#news-box .date {
+ font-style: italic;
+ text-decoration: underline;
+}
+
+#news-box ul a:link .date {
+ color: #3010ff; /* a:link-blue */
+}
+
+#news-box ul a:visited .date {
+ color: #5060f7; /* a:visited-blue */
+}
+
+/* boxes for #left area */
+div.box {
+ position: relative;
+ left: 10px;
+ width: 165px;
+ margin: 0;
+ padding: 0;
+ border: solid 2px #606080; /* violet */
+ background-color: #ffffff;
+ z-index: 7;
+ font-size: 10pt;
+}
+
+.box-content {
+ margin-top: 0;
+ margin-bottom: 0;
+ margin-left: 12px;
+ margin-right: 12px;
+}
+
+div.box ul {
+ list-style: none;
+ padding-left: 0;
+}
+
+div.box ul a {
+ width: 100%;
+ display: block;
+ margin: 0;
+ padding: 0;
+}
+
+div.box ul a:hover {
+ border-right: solid 4px #606080;
+}
+
+/* boxes for #left area - top rounded heading */
+div.boxheadl {
+ position: relative;
+ top: -15px;
+ left: -2px;
+ height: 30px;
+ width: 169px; /* width of div.box + 4px border */
+ background: url(../images/heading-left-small.png) no-repeat left;
+ margin: 0;
+ padding: 0;
+}
+
+div.boxheadr {
+ height: 30px;
+ background: url(../images/heading-right-small.png) no-repeat top right;
+ margin: 0;
+ padding: 0;
+}
+
+div.boxheadr h1 {
+ height: 26px;
+ border-top: 2px solid #606080; /* violet */
+ border-bottom: 2px solid #606080; /* violet */
+ background-color: #9090b0; /* light-violet */
+ color: #fffce4; /* light-yellow */
+ font-size: 14pt;
+ font-style: normal;
+ font-weight: normal;
+ text-align: center;
+ line-height: 26px;
+ vertical-align: middle;
+ white-space: nowrap;
+ margin: 0;
+ margin-left: 15px;
+ margin-right: 15px;
+ padding: 0;
+}
+
+/* boxes for #left area - bottom rounded corners */
+div.boxbottoml {
+ position: relative;
+ top: 15px;
+ left: -2px;
+ height: 15px;
+ width: 169px; /* width of div.box + 4px border */
+ background: url(../images/bottom-left-small.png) no-repeat left;
+ margin: 0;
+ margin-top: -15px;
+ padding: 0;
+}
+
+div.boxbottomr {
+ height: 15px;
+ background: url(../images/bottom-right-small.png) no-repeat right bottom;
+ margin: 0;
+ padding: 0;
+}
+
+div.boxbottomm {
+ height: 13px;
+ background-color: #ffffff;
+ border-bottom: 2px solid #606080; /* violet */
+ margin: 0;
+ margin-left: 15px;
+ margin-right: 15px;
+}
+
+/* Section heading rounded bar (with icon) */
+div.headl {
+ height: 40px;
+ width: 100%;
+ background: url(../images/heading-left.png) no-repeat left;
+ margin-bottom: 10px;
+ margin-top: 30px;
+ padding: 0;
+}
+
+div.headr {
+ height: 40px;
+ background: url(../images/heading-right.png) no-repeat right;
+ margin: 0;
+ padding: 0;
+}
+
+div.headr h1 {
+ height: 36px;
+ border-top: 2px solid #606080; /* violet */
+ border-bottom: 2px solid #606080; /* violet */
+ background: #9090b0 url(../images/ot32.png) no-repeat left 50%;
+ color: #fffce4; /* light-yellow */
+ font-size: 18pt;
+ line-height: 36px;
+ vertical-align: middle;
+ white-space: nowrap;
+ overflow: hidden;
+ margin: 0;
+ margin-left: 20px;
+ margin-right: 20px;
+ padding: 0;
+ padding-left: 50px;
+}
+
+/* horizontal line */
+div.line,span.line,dt.line {
+ display: block;
+ clear: both;
+ width: 100%;
+ height: 4px;
+ background: url(../images/line.gif) no-repeat left;
+}
+
+/* publications: separator line mentioning the year: */
+span.yearline {
+ display: block;
+ clear: both;
+ width: 100%;
+ height: 4px;
+ background: url(../images/line.gif) no-repeat left;
+ margin: 0;
+ padding-left: 616px;
+ color: gray;
+ font-weight: bold;
+}
+
+/* Intro: */
+div.intro {
+ width: 90%;
+ max-width: 820px;
+ margin: 10px;
+ margin-left: 40px;
+ margin-right: auto;
+}
+
+div.term {
+ float: left;
+ width: 25%;
+ min-width: 130px;
+ max-width: 190px;
+ padding: 2px;
+ color: #000060;
+}
+
+div.termdesc {
+ float: left;
+ width: 70%;
+ min-width: 300px;
+ max-width: 600px;
+ padding: 2px;
+}
+
+/* tables: */
+table,td,th { /* from otjld.css - should be refactored */
+ border-style: none;
+ border-width: 0;
+ border-spacing: 0px;
+ border-collapse: collapse;
+ padding: 2px 6px;
+}
+
+.border td {
+ border: 1px solid #e0e0f0;
+}
+
+.noborder td {
+ border: none;
+}
+
+table.default,table.default td {
+ border-style: solid;
+ border-color: #e0e0f0;
+ border-width: 2px;
+ border-spacing: 0px;
+ border-collapse: collapse;
+ padding: 2px 6px;
+ margin: 10px;
+}
+
+table.default th {
+ background-color: #e0e0f0;
+}
+
+table.default-mm th {
+ color: #fffce4; /* light-yellow */
+ background-color: #9090b0; /* light-violet */
+}
+
+table.default td {
+ background-color: #fffce4; /* light-yellow */
+}
+
+span.hint-box {
+ display: inline-block;
+ width: auto;
+ background-color: #fffce4; /* light-yellow */
+ border: 2px solid #e0e0f0;
+ padding: 2px 10px;
+}
+
+a.helplink {
+ background: url(../images/linkto_help.gif) no-repeat left;
+ padding-left: 20px;
+ font-size: 10pt;
+}
+
+/* misc layout options */
+.center {
+ text-align: center;
+}
+
+.indent5 {
+ padding-left: 5mm;
+}
+
+div.indent {
+ margin-left: 20pt;
+}
+
+div.ttindent {
+ font-family: courier, monospace;
+ margin-left: 20pt;
+}
+
+/* special highlighting: */
+.black {
+ color: black;
+ font-weight: bold;
+}
+
+.darkblue {
+ color: #000060;
+}
+
+.error {
+ color: red;
+}
+
+.blue {
+ color: blue;
+}
+
+.green {
+ color: green;
+}
+
+.underline {
+ text-decoration: underline;
+}
+
+code.keyword {
+ color: #7F0055;
+ font-weight: bold;
+}
+
+/* zebra stripes ;-) */
+.z1 {
+ background-color: #fff0c8;
+}
+
+.z2 {
+ background-color: #fff8e0;
+}
+
+.z3 {
+ background-color: #fffce4;
+}
+
+/* to clear floats: */
+div.clearer {
+ clear: both;
+ line-height: 0pt;
+ font-size: 1px;
+}
+
+/* Trac specific: */
+/* Meta navigation in Trac needs different link colors: */
+#metanav ul li {
+ color: #efefff;
+ background-color: transparent;
+}
+
+#metanav a:link,#metanav a:visited {
+ color: #fffec4;
+ background-color: transparent;
+}
+
+#metanav a:hover {
+ color: white;
+ background-color: #9090b0;
+}
+
+/* Meta navigation positioned within the top bar: */
+div#metanav {
+ position: absolute; /* switched to 'fixed' by javascript dynamically */
+ top: 8px;
+ right: 210px;
+ z-index: 10;
+}
+
+/* Context navigation positioned at the bottom of our header: */
+div#ctxtnav {
+ position: absolute; /* switched to 'fixed' by javascript dynamically */
+ top: 65px;
+ right: 0px;
+ z-index: 8;
+}
+
+div#tabcontent {
+ clear: both;
+ margin-left: 0;
+}
+
+form#search {
+ position: absolute; /* switched to 'fixed' by javascript dynamically */
+ top: 0;
+ right: 0;
+ z-index: 6;
+}
+
+form.addnew {
+ position: relative;
+ top: -300px;
+}
+
+form#addsubj {
+ position: relative;
+ top: -550px;
+ left: -250px;
+}
+
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/ot.fix-ie6.css b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/ot.fix-ie6.css
new file mode 100644
index 0000000..2f2055b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/ot.fix-ie6.css
@@ -0,0 +1,45 @@
+/**
+ * contains fixes for IE version < 7
+ * @author mosconi
+ */
+html {
+ height: 100%;
+ max-height: 100%;
+}
+
+#left {
+ position: absolute; /* switched to 'fixed' by javascript dynamically */
+ height: 1000px;
+}
+#left.fixed { /* class applied by javascript dynamically */
+ position: fixed;
+}
+
+/* display content over rounded corner background */
+#content {
+ z-index: 99; /* overwritten by javascript to 1 */
+}
+
+div.boxheadr {
+ margin-right: -4px;
+ overflow: visible;
+}
+div.boxbottomr {
+ margin-right: -4px;
+ overflow: visible;
+}
+div.boxbottomm{
+ height: 13px;
+ overflow: hidden;
+ margin-top: 0;
+ margin-bottom: 0;
+ margin-left: 15px;
+ margin-right: 15px;
+}
+
+#nav-box li {
+ background: none;
+ list-style: url(../images/arrow-right-trans.png);
+ padding-left: 5px;
+ margin-left: 15px;
+}
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/otjld.css b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/otjld.css
new file mode 100644
index 0000000..eed8a8b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/css/otjld.css
@@ -0,0 +1,291 @@
+/* override margins from ot.css: */
+body.otdt {
+ margin: 4px;
+ padding: 4px;
+}
+
+body.otdt #content {
+ margin: 0;
+ padding: 0;
+}
+
+body.otdt #footer {
+ margin-top: 10px;
+ margin-left: 4px;
+}
+
+/* Syntax links: */
+a.syntax {
+ border: 1px solid red;
+ margin: 2px;
+ padding: 2px;
+}
+
+/* ToC page: */
+div.toc {
+ font-weight: bold;
+ padding-left: 20px;
+}
+
+div.toc.depth1 {
+ font-size: 1.2em;
+}
+
+div.toc.depth2 {
+ padding-left: 50px;
+}
+div.toc.depth2 a {
+ color: black;
+}
+
+div.toc.depth3 {
+ padding-left: 80px;
+}
+div.toc.depth3 a {
+ color: black;
+}
+
+/* Chapter headings (with icon): */
+div.chapter {
+ margin: 0px;
+ padding: 0px;
+}
+
+/* Mini-ToC-Box: */
+div#toc-box {
+ position: fixed;
+ top: 100px;
+ right: 5px;
+ width: 22pt;
+ z-index: 9;
+ background-color: #fff8e0;
+ border: 2px solid #e0e0f0;
+ border-right: none;
+ font-size: 10pt;
+ white-space: nowrap;
+ opacity: 0.5;
+ -moz-opacity: 0.5;
+ filter: alpha(opacity=50);
+}
+
+div#toc-box.web {
+ top: 200px;
+}
+
+div#toc-box:hover {
+ right: 5px;
+ width: auto;
+ border: 2px solid #e0e0f0;
+ opacity: 0.9;
+ -moz-opacity: 0.9;
+ filter: alpha(opacity=90);
+}
+
+ul.toc-box {
+ list-style-type: none;
+ margin: 5px;
+ padding: 0px;
+}
+
+/* (Sub)sections: */
+div.sect, div.aux {
+ padding-left: 5px;
+ margin-right: 25pt;
+}
+
+h2.sect {
+ position: relative;
+ background-color: #e0e0f0;
+ padding: 2px;
+ padding-left: 10px;
+}
+
+h3.sect, h4.aux {
+ position: relative;
+ background-color: #e0e0f0;
+ padding: 2px;
+ padding-left: 5px;
+}
+
+div.subsect {
+ width: 90%;
+ margin-left: 20px;
+ margin-right: 20px;
+ margin-top: 10px;
+ margin-bottom: 10px;
+}
+
+h4.subsect {
+ font-weight: normal;
+ margin-left: -20px;
+ margin-bottom: 4px;
+}
+h4.subsect + p {
+ margin-top: 2px;
+}
+
+h4.subsect .title {
+ text-decoration: underline;
+}
+
+span.toplink {
+ position: absolute; right: 10px;
+ font-size: 10pt;
+ font-weight: normal;
+}
+
+/* Listings: */
+div.listing {
+ float: none;
+ width: 90%;
+ overflow: auto;
+ font-family: Courier;
+ font-size: 10pt;
+ padding: 0;
+ margin: 2px;
+}
+
+div.listing.frame {
+ border: 4px solid #9090B0;
+}
+
+table.listing {
+ width: 100%;
+ border: none;
+ border-spacing: 0;
+ border-collapse: collapse;
+}
+
+tr.line.odd {
+ background-color: #fff0c8;
+}
+
+tr.line.even {
+ background-color: #fff8e0;
+}
+
+div.listing pre {
+ margin: 0px;
+ padding: 2px;
+}
+
+td.ln {
+ color: #5060f7;
+ width: 20px;
+ text-align: right;
+ vertical-align: middle;
+ font-size: 12pt;
+ padding-left: 5px;
+ padding-right: 10px;
+}
+
+pre em {
+ font-style: normal;
+ color: blue;
+}
+pre .comment {
+ color: green;
+}
+
+h5.listing {
+ margin-bottom: 0px;
+}
+
+/* other OTJLD elements: */
+div.note {
+ font-style: italic;
+ margin-left: 10px;
+}
+
+div.codecomment {
+ width: 90%;
+ background-color: #fff8e0;
+ font-size: 0.8em;
+ margin-top: 5px;
+ padding: 2px;
+}
+div.codecomment>h5, div.note>h5 {
+ margin: 2px;
+}
+div.codecomment>h5+p, div.note>h5+p {
+ margin-top: 2px;
+}
+
+table.syntaxrule {
+ width: 80%;
+ border: 2px solid #e0e0f0;
+ border-spacing: 0px;
+ border-collapse: collapse;
+ margin: 4px;
+ padding: 0;
+}
+table.syntaxrule td.sect {
+ width: 80px;
+ border: 2px solid #e0e0f0;
+ padding: 5px;
+ vertical-align: top;
+ font-weight: bold;
+}
+table.syntaxrule td.rule {
+ padding-left: 20px;
+ background-color: #fff8e0;
+}
+table.syntaxrule .title {
+ margin-left: -10px;
+ font-weight: bold;
+ font-style: italic;
+ color: blue;
+}
+
+ol.constraints {
+ list-style-type: lower-alpha;
+}
+ol.constraints .title {
+ text-decoration: underline;
+}
+h5.constraints {
+ margin-bottom: 2px;
+}
+
+/* page navigation: */
+table.nav {
+ border: 2px solid #e0e0f0;
+ border-collapse: collapse;
+ width: 95%;
+ white-space: nowrap;
+ margin-left: auto;
+ margin-right: auto;
+ margin-top: 5px;
+ margin-bottom: 5px;
+ background-color: #fff8e0;
+ font-size: 10pt;
+}
+
+td.back {
+ width: 35%;
+ padding-left: 4px;
+ text-align: left;
+ white-space: nowrap;
+}
+td.top {
+ border: 2px solid #e0e0f0;
+ text-align: center;
+ white-space: nowrap;
+}
+td.next {
+ width: 35%;
+ padding-right: 4px;
+ text-align: right;
+ white-space: nowrap;
+}
+
+div.breadcrumb {
+ width: 95%;
+ margin-left: auto;
+ margin-right: auto;
+ white-space: nowrap;
+}
+
+a.nav {
+ font-size: 10pt;
+}
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/heading_left.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/heading_left.png
new file mode 100644
index 0000000..bc2bff7
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/heading_left.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/heading_right.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/heading_right.png
new file mode 100644
index 0000000..3c4af59
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/heading_right.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/line.gif b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/line.gif
new file mode 100644
index 0000000..212443d
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/line.gif
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/otjld.css b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/otjld.css
new file mode 100644
index 0000000..3766d48
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/otjld.css
@@ -0,0 +1,474 @@
+body {
+ background-color: #ffffff;
+ font-family: helvetica,avalon,sans-serif;
+ margin: 4px;
+ padding: 4px;
+}
+
+/* Web-Design: (copied from ot2.css) */
+
+body.web-design {
+ z-index:0;
+ background-image:url(gray.png);
+ background-repeat:repeat-y;
+ background-position: left;
+}
+
+#logo {
+ position: fixed; top: 0px; left: 0px;
+ white-space: nowrap;
+ width: 100%;
+ z-index: 16;
+}
+
+img#topbar {
+ vertical-align: top;
+}
+
+a#back {
+ background-color: inherit;
+}
+
+a.showmenu { color:#fffce4; background-color:inherit; }
+a:hover.showmenu { color:#FFA500; background-color:inherit; cursor:pointer;} /* color: orange1 */
+div#showmenu {
+ position:fixed;top:10px;left:2px;
+ font-size:6pt;
+ z-index:17;
+}
+
+#chead {
+ position:fixed;top:-7px;left:0px;
+ background-color:#fffce4;
+ background-image:url(gray.png);
+ background-repeat:repeat-x;
+ background-position: bottom;
+
+ padding-top:13px;
+ padding-left:0px;
+ padding-right:0px;
+ width:100%;
+ height:38px;
+ z-index:10;
+ margin-left:22px;
+ margin-top:35px;
+ font-size:18pt;
+ font-weight:bold;
+ text-align:center;
+ text-shadow: #e4e0d6 2px 3px 1px;
+}
+
+#bend{
+ position:fixed;top:60px;left: 0px;
+ background-image:url(bend-trans.png);
+ background-repeat:no-repeat;
+ width:30px;
+ height:50px;
+ margin-left:0px;
+ margin-top:0px;
+ z-index:11;
+}
+
+#spacer {
+ height: 80px;
+}
+
+
+/* Links: */
+a:visited { color: #5060f7; text-decoration: none; }
+a:link { color: #3010ff; text-decoration: none; }
+a:hover { color: black; background-color: #e8e8fc; }
+
+a.syntax {
+ border: 1px solid red;
+ margin: 2px;
+ padding: 2px;
+}
+
+a img {
+ border-style: none;
+}
+
+/* ToC page: */
+div.toc {
+ font-weight: bold;
+ padding-left: 20px;
+}
+
+div.toc.depth1 {
+ font-size: 1.2em;
+}
+
+div.toc.depth2 {
+ padding-left: 50px;
+}
+div.toc.depth2 a {
+ color: black;
+}
+
+div.toc.depth3 {
+ padding-left: 80px;
+}
+div.toc.depth3 a {
+ color: black;
+}
+
+/* Chapter headings (with icon): */
+div.chapter {
+ margin: 0px;
+ padding: 0px;
+}
+
+div.headl {
+ height: 40px;
+ width: 100%;
+ background: url(heading_left.png) no-repeat left;
+ margin-bottom: 10px;
+ margin-top: 0px;
+ padding: 0px;
+}
+
+div.headr {
+ height: 40px;
+ background: url(heading_right.png) no-repeat top right;
+ margin: 0px;
+ padding: 0px;
+}
+
+div.headr h1 {
+ height: 34px;
+ border-top: 2px solid #626280;
+ border-bottom: 2px solid #626280;
+ background-color: #9090B0;
+ color:#ffffe0;
+ font-size: 20pt;
+ margin-left: 50px;
+ margin-right: 22px;
+ padding-left: 10px;
+ padding-top: 2px;
+ margin-top: 0px;
+ margin-bottom: 0px;
+ padding-bottom: 0px;
+}
+
+/* Mini-ToC-Box: */
+div.toc-box, div#toc-box { /* transitionally support both class and id [SH] */
+ position: fixed;
+ top: 100px;
+ right: 5px;
+ width: 22pt;
+ z-index: 9;
+ background-color: #fff8e0;
+ border: 2px solid #e0e0f0;
+ border-right: none;
+ font-size: 10pt;
+ white-space: nowrap;
+ opacity: 0.5;
+ -moz-opacity: 0.5;
+ filter: alpha(opacity=50);
+}
+
+div#toc-box.web-design {
+ top: 180px;
+}
+
+div#toc-box:hover {
+ right: 5px;
+ width: auto;
+ border: 2px solid #e0e0f0;
+ opacity: 0.9;
+ -moz-opacity: 0.9;
+ filter: alpha(opacity=90);
+}
+
+ul.toc-box {
+ list-style-type: none;
+ margin: 5px;
+ padding: 0px;
+}
+
+/* Intro: */
+div.intro {
+ width: 90%;
+ max-width: 820px;
+ margin: 10px;
+ margin-left: 40px;
+ margin-right: auto;
+}
+
+div.line {
+ clear: both;
+ height: 5px;
+ background: url(line.gif) no-repeat left;
+}
+
+div.term {
+ float: left;
+ width: 25%;
+ min-width: 130px;
+ max-width: 190px;
+ padding: 2px;
+ color: #000060;
+}
+
+div.termdesc {
+ float: left;
+ width: 70%;
+ min-width: 300px;
+ max-width: 600px;
+ padding: 2px;
+}
+
+/* (Sub)sections: */
+div.sect, div.aux {
+ padding-left: 5px;
+ margin-right: 25pt;
+}
+
+h2.sect {
+ position: relative;
+ background-color: #e0e0f0;
+ padding: 2px;
+ padding-left: 10px;
+}
+
+h3.sect, h4.aux {
+ position: relative;
+ background-color: #e0e0f0;
+ padding: 2px;
+ padding-left: 5px;
+}
+
+div.subsect {
+ width: 90%;
+ margin-left: 20px;
+ margin-right: 20px;
+ margin-top: 10px;
+ margin-bottom: 10px;
+}
+
+h4.subsect {
+ font-weight: normal;
+ margin-left: -20px;
+ margin-bottom: 4px;
+}
+h4.subsect + p {
+ margin-top: 2px;
+}
+
+h4.subsect .title {
+ text-decoration: underline;
+}
+
+span.toplink {
+ position: absolute; right: 10px;
+ font-size: 10pt;
+ font-weight: normal;
+}
+
+/* Listings: */
+div.listing {
+ float: none;
+ width: 90%;
+ overflow: auto;
+ font-family: Courier;
+ font-size: 10pt;
+ padding: 0;
+ margin: 2px;
+}
+
+div.listing.frame {
+ border: 4px solid #9090B0;
+}
+
+table.listing {
+ width: 100%;
+ border: none;
+ border-spacing: 0;
+ border-collapse: collapse;
+}
+
+tr.line.odd {
+ background-color: #fff0c8;
+}
+
+tr.line.even {
+ background-color: #fff8e0;
+}
+
+div.listing pre {
+ margin: 0px;
+ padding: 2px;
+}
+
+td.ln {
+ color: #5060f7;
+ width: 20px;
+ text-align: right;
+ vertical-align: middle;
+ font-size: 12pt;
+ padding-left: 5px;
+ padding-right: 10px;
+}
+
+pre em {
+ font-style: normal;
+ color: blue;
+}
+pre .comment {
+ color: green;
+}
+
+h5.listing {
+ margin-bottom: 0px;
+}
+
+/* other OTJLD elements: */
+div.note {
+ font-style: italic;
+ margin-left: 10px;
+}
+
+div.codecomment {
+ width: 90%;
+ background-color: #fff8e0;
+ font-size: 0.8em;
+ margin-top: 5px;
+ padding: 2px;
+}
+div.codecomment>h5, div.note>h5 {
+ margin: 2px;
+}
+div.codecomment>h5+p, div.note>h5+p {
+ margin-top: 2px;
+}
+
+table.syntaxrule {
+ width: 80%;
+ border: 2px solid #e0e0f0;
+ border-spacing: 0px;
+ border-collapse: collapse;
+ margin: 4px;
+ padding: 0;
+}
+table.syntaxrule td.sect {
+ width: 80px;
+ border: 2px solid #e0e0f0;
+ padding: 5px;
+ vertical-align: top;
+ font-weight: bold;
+}
+table.syntaxrule td.rule {
+ padding-left: 20px;
+ background-color: #fff8e0;
+}
+table.syntaxrule .title {
+ margin-left: -10px;
+ font-weight: bold;
+ font-style: italic;
+ color: blue;
+}
+
+ol.constraints {
+ list-style-type: lower-alpha;
+}
+ol.constraints .title {
+ text-decoration: underline;
+}
+h5.constraints {
+ margin-bottom: 2px;
+}
+
+/* page navigation: */
+table.nav {
+ border: 2px solid #e0e0f0;
+ border-collapse: collapse;
+ width: 95%;
+ white-space: nowrap;
+ margin-left: auto;
+ margin-right: auto;
+ margin-top: 5px;
+ margin-bottom: 5px;
+ background-color: #fff8e0;
+ font-size: 10pt;
+}
+
+td.back {
+ width: 35%;
+ padding-left: 4px;
+ text-align: left;
+ white-space: nowrap;
+}
+td.top {
+ border: 2px solid #e0e0f0;
+ text-align: center;
+ white-space: nowrap;
+}
+td.next {
+ width: 35%;
+ padding-right: 4px;
+ text-align: right;
+ white-space: nowrap;
+}
+
+div.nav {
+ width: 95%;
+ margin-left: auto;
+ margin-right: auto;
+ white-space: nowrap;
+}
+
+a.nav {
+ font-size: 10pt;
+}
+
+/* page footer: */
+div.footer {
+ margin-top: 10px;
+ font-size: 10pt;
+ color: gray;
+}
+
+#w3c {
+ float: right;
+}
+
+/* to clear floats: */
+div.clearer {
+ clear: both;
+ line-height: 0pt;
+ font-size: 1px;
+}
+
+/* tables: */
+table {
+ border-style: solid;
+ border-color: #e0e0f0;
+ border-spacing: 0px;
+ border-collapse: collapse;
+}
+
+/* special highlighting: */
+.error {
+ color: red;
+}
+
+.blue {
+ color: blue;
+}
+.green {
+ color: green;
+}
+
+.underline {
+ text-decoration: underline;
+}
+
+/* zebra stripes ;-) */
+.z1 { background-color:#fff0c8; }
+
+.z2 { background-color:#fff8e0; }
+
+span.indent5 {
+ padding-left: 5mm;
+}
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/valid-xhtml11-blue.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/valid-xhtml11-blue.png
new file mode 100644
index 0000000..88fefcbf
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/css/valid-xhtml11-blue.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/Layering.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/Layering.png
new file mode 100644
index 0000000..0f54738
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/Layering.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/foo.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/foo.png
new file mode 100644
index 0000000..aefdfd6
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/foo.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/guards.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/guards.png
new file mode 100644
index 0000000..741696c
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/guards.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/implicitly_overriding_playedby.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/implicitly_overriding_playedby.png
new file mode 100644
index 0000000..b76a2cb
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/implicitly_overriding_playedby.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/implicitly_overriding_playedby_base.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/implicitly_overriding_playedby_base.png
new file mode 100644
index 0000000..b7c24e4
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/implicitly_overriding_playedby_base.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/smart_lifting_small.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/smart_lifting_small.png
new file mode 100644
index 0000000..362ff65
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/smart_lifting_small.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/team_nesting_hor.png b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/team_nesting_hor.png
new file mode 100644
index 0000000..d1df4dc
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/images/team_nesting_hor.png
Binary files differ
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/index.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/index.html
new file mode 100644
index 0000000..db92afc
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/index.html
@@ -0,0 +1,128 @@
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+ <link rel="stylesheet" type="text/css" href="../css/ot.css" />
+ <link rel="stylesheet" type="text/css" href="../css/otjld.css" />
+ <title>OT/J Language Definition v1.3</title>
+ </head>
+ <body class="otdt">
+ <div id="content">
+ <div class="headl">
+ <div class="headr">
+ <h1>Table of Contents</h1>
+ </div>
+ </div>
+ <div class="toc depth1"><a href="s0.html" rel="section">§0 About this Document</a></div>
+ <div class="toc depth2"><a href="s0.html#s0.1" rel="section">§0.1 Purpose(s) of this document</a></div>
+ <div class="toc depth2"><a href="s0.html#s0.2" rel="section">§0.2 Text structure</a></div>
+ <div class="toc depth2"><a href="s0.html#s0.3" rel="section">§0.3 Compiler messages</a></div>
+ <div class="toc depth2"><a href="s0.html#s0.4" rel="section">§0.4 Versions</a></div>
+ <div class="toc depth2"><a href="s0.html#s0.5" rel="section">§0.5 Publishing</a></div>
+ <div class="toc depth1"><a href="s1.html" rel="section">§1 Teams and Roles</a></div>
+ <div class="toc depth2"><a href="s1.html#s1.1" rel="section">§1.1 Team classes</a></div>
+ <div class="toc depth2"><a href="s1.html#s1.2" rel="section">§1.2 Role classes and objects</a></div>
+ <div class="toc depth3"><a href="s1.html#s1.2.1" rel="section">§1.2.1 Modifiers for roles</a></div>
+ <div class="toc depth3"><a href="s1.html#s1.2.2" rel="section">§1.2.2 Externalized roles</a></div>
+ <div class="toc depth3"><a href="s1.html#s1.2.3" rel="section">§1.2.3 Protected roles</a></div>
+ <div class="toc depth3"><a href="s1.html#s1.2.4" rel="section">§1.2.4 Type tests and casts</a></div>
+ <div class="toc depth3"><a href="s1.html#s1.2.5" rel="section">§1.2.5 File structure</a></div>
+ <div class="toc depth2"><a href="s1.html#s1.3" rel="section">§1.3 Acquisition and implicit inheritance of role classes</a></div>
+ <div class="toc depth3"><a href="s1.html#s1.3.1" rel="section">§1.3.1 Acquisition and implicit inheritance of role classes</a></div>
+ <div class="toc depth3"><a href="s1.html#s1.3.2" rel="section">§1.3.2 Regular role inheritance</a></div>
+ <div class="toc depth2"><a href="s1.html#s1.4" rel="section">§1.4 Name clashes</a></div>
+ <div class="toc depth2"><a href="s1.html#s1.5" rel="section">§1.5 Team and role nesting</a></div>
+ <div class="toc depth1"><a href="s2.html" rel="section">§2 Role Binding</a></div>
+ <div class="toc depth2"><a href="s2.html#s2.1" rel="section">§2.1 playedBy relation</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.1.1" rel="section">§2.1.1 Binding interfaces</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.1.2" rel="section">§2.1.2 Legal base classes</a></div>
+ <div class="toc depth2"><a href="s2.html#s2.2" rel="section">§2.2 Lowering</a></div>
+ <div class="toc depth2"><a href="s2.html#s2.3" rel="section">§2.3 Lifting</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.3.1" rel="section">§2.3.1 Implicit role creation</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.3.2" rel="section">§2.3.2 Declared lifting</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.3.3" rel="section">§2.3.3 Smart lifting</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.3.4" rel="section">§2.3.4 Binding ambiguities</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.3.5" rel="section">§2.3.5 Consequences of lifting problems</a></div>
+ <div class="toc depth2"><a href="s2.html#s2.4" rel="section">§2.4 Explicit role creation</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.4.1" rel="section">§2.4.1 Role creation via a lifting constructor</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.4.2" rel="section">§2.4.2 Role creation via a regular constructor</a></div>
+ <div class="toc depth3"><a href="s2.html#s2.4.3" rel="section">§2.4.3 Role creation in the presence of smart lifting</a></div>
+ <div class="toc depth2"><a href="s2.html#s2.5" rel="section">§2.5 Abstract Roles</a></div>
+ <div class="toc depth2"><a href="s2.html#s2.6" rel="section">§2.6 Explicit base references</a></div>
+ <div class="toc depth2"><a href="s2.html#s2.7" rel="section">§2.7 Advanced structures</a></div>
+ <div class="toc depth1"><a href="s3.html" rel="section">§3 Callout Binding</a></div>
+ <div class="toc depth2"><a href="s3.html#s3.1" rel="section">§3.1 Callout method binding</a></div>
+ <div class="toc depth2"><a href="s3.html#s3.2" rel="section">§3.2 Callout parameter mapping</a></div>
+ <div class="toc depth2"><a href="s3.html#s3.3" rel="section">§3.3 Lifting and lowering</a></div>
+ <div class="toc depth2"><a href="s3.html#s3.4" rel="section">§3.4 Overriding access restrictions</a></div>
+ <div class="toc depth2"><a href="s3.html#s3.5" rel="section">§3.5 Callout to field</a></div>
+ <div class="toc depth1"><a href="s4.html" rel="section">§4 Callin Binding</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.1" rel="section">§4.1 Callin method binding</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.2" rel="section">§4.2 Callin modifiers (before, after, replace)</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.3" rel="section">§4.3 Base calls</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.4" rel="section">§4.4 Callin parameter mapping</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.5" rel="section">§4.5 Lifting and lowering</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.6" rel="section">§4.6 Overriding access restrictions</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.7" rel="section">§4.7 Callin binding with static methods</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.8" rel="section">§4.8 Callin precedence</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.9" rel="section">§4.9 Callin inheritance</a></div>
+ <div class="toc depth3"><a href="s4.html#s4.9.1" rel="section">§4.9.1 Base side inheritance</a></div>
+ <div class="toc depth3"><a href="s4.html#s4.9.2" rel="section">§4.9.2 Role side inheritance</a></div>
+ <div class="toc depth3"><a href="s4.html#s4.9.3" rel="section">§4.9.3 Covariant return types</a></div>
+ <div class="toc depth2"><a href="s4.html#s4.10" rel="section">§4.10 Generic callin bindings</a></div>
+ <div class="toc depth1"><a href="s5.html" rel="section">§5 Team Activation</a></div>
+ <div class="toc depth2"><a href="s5.html#s5.1" rel="section">§5.1 Effect of team activation</a></div>
+ <div class="toc depth3"><a href="s5.html#s5.1.1" rel="section">§5.1.1 Global vs. thread local team activation</a></div>
+ <div class="toc depth3"><a href="s5.html#s5.1.2" rel="section">§5.1.2 Effect on garbage collection</a></div>
+ <div class="toc depth2"><a href="s5.html#s5.2" rel="section">§5.2 Explicit team activation</a></div>
+ <div class="toc depth2"><a href="s5.html#s5.3" rel="section">§5.3 Implicit team activation</a></div>
+ <div class="toc depth2"><a href="s5.html#s5.4" rel="section">§5.4 Guard predicates</a></div>
+ <div class="toc depth3"><a href="s5.html#s5.4.1" rel="section">§5.4.1 Regular guards</a></div>
+ <div class="toc depth3"><a href="s5.html#s5.4.2" rel="section">§5.4.2 Base guards</a></div>
+ <div class="toc depth3"><a href="s5.html#s5.4.3" rel="section">§5.4.3 Multiple guards</a></div>
+ <div class="toc depth2"><a href="s5.html#s5.5" rel="section">§5.5 Unanticipated team activation</a></div>
+ <div class="toc depth1"><a href="s6.html" rel="section">§6 Object Teams API</a></div>
+ <div class="toc depth2"><a href="s6.html#s6.1" rel="section">§6.1 Reflection</a></div>
+ <div class="toc depth2"><a href="s6.html#s6.2" rel="section">§6.2 Other API Elements</a></div>
+ <div class="toc depth2"><a href="s6.html#s6.3" rel="section">§6.3 Annotations</a></div>
+ <div class="toc depth1"><a href="s7.html" rel="section">§7 Role Encapsulation</a></div>
+ <div class="toc depth2"><a href="s7.html#s7.1" rel="section">§7.1 Opaque roles</a></div>
+ <div class="toc depth2"><a href="s7.html#s7.2" rel="section">§7.2 Confined roles</a></div>
+ <div class="toc depth1"><a href="s8.html" rel="section">§8 Join Point Queries</a></div>
+ <div class="toc depth2"><a href="s8.html#s8.1" rel="section">§8.1 Join point queries</a></div>
+ <div class="toc depth2"><a href="s8.html#s8.2" rel="section">§8.2 Query expressions</a></div>
+ <div class="toc depth2"><a href="s8.html#s8.3" rel="section">§8.3 OT/J meta model</a></div>
+ <div class="toc depth1"><a href="s9.html" rel="section">§9 Value Dependent Classes</a></div>
+ <div class="toc depth2"><a href="s9.html#s9.1" rel="section">§9.1 Defining classes with value parameters</a></div>
+ <div class="toc depth2"><a href="s9.html#s9.2" rel="section">§9.2 Using classes with value parameters</a></div>
+ <div class="toc depth3"><a href="s9.html#s9.2.1" rel="section">§9.2.1 Parameter substitution</a></div>
+ <div class="toc depth3"><a href="s9.html#s9.2.2" rel="section">§9.2.2 Type conformance</a></div>
+ <div class="toc depth2"><a href="s9.html#s9.3" rel="section">§9.3 Restrictions and limitations</a></div>
+ <div class="toc depth1"><a href="sA.html" rel="section">§A OT/J Syntax</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.0" rel="section">§A.0 Keywords</a></div>
+ <div class="toc depth3"><a href="sA.html#sA.0.1" rel="section">§A.0.1 Scoped keywords</a></div>
+ <div class="toc depth3"><a href="sA.html#sA.0.2" rel="section">§A.0.2 Inheriting scoped keywords</a></div>
+ <div class="toc depth3"><a href="sA.html#sA.0.3" rel="section">§A.0.3 Internal names</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.1" rel="section">§A.1 Class definitions</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.2" rel="section">§A.2 Modifiers</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.3" rel="section">§A.3 Method bindings</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.4" rel="section">§A.4 Parameter mappings</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.5" rel="section">§A.5 Statements</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.6" rel="section">§A.6 Types</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.7" rel="section">§A.7 Guard predicates</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.8" rel="section">§A.8 Precedence declaration</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.9" rel="section">§A.9 Value dependent types</a></div>
+ <div class="toc depth2"><a href="sA.html#sA.10" rel="section">§A.10 Packages and imports</a></div>
+ <div class="toc depth1"><a href="sB.html" rel="section">§B Changes between versions</a></div>
+ <div class="toc depth2"><a href="sB.html#sB.1" rel="section">§B.1 Paragraphs changed between versions</a></div>
+ <div class="toc depth2"><a href="sB.html#sB.2" rel="section">§B.2 Additions between versions</a></div>
+ </div>
+ <div id="footer">
+ <hr /><a class="w3c img" href="http://jigsaw.w3.org/css-validator/check/referer"
+ shape="rect"><img src="../images/valid-css2-blue.png" alt="Valid CSS!" height="31" width="88" /></a><a class="w3c img" href="http://validator.w3.org/check?uri=referer" shape="rect"><img src="../images/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31"
+ width="88" /></a><address>© Stephan Herrmann, Christine Hundt, Marco Mosconi</address>
+ OT/J version 1.3 — last modified: 2011-05-15
+ </div>
+ </body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s0.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s0.html
new file mode 100644
index 0000000..625687b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s0.html
@@ -0,0 +1,190 @@
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+ <link rel="stylesheet" type="text/css" href="../css/ot.css" />
+ <link rel="stylesheet" type="text/css" href="../css/otjld.css" />
+ <title>OT/J Language Definition v1.3</title>
+ </head>
+ <body class="otdt">
+ <div id="content">
+ <table class="nav">
+ <tr>
+ <td class="back"><a id="top"></a></td>
+ <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
+ <td class="next"><a href="s1.html" rel="next">§1 Teams and Roles >></a></td>
+ </tr>
+ </table>
+ <div class="chapter" id="s0">
+ <div class="headl">
+ <div class="headr">
+ <h1>§0 About this Document</h1>
+ </div>
+ </div>
+ <div id="toc-box">
+ <ul class="toc-box">
+ <li><a href="s0.html">§0 About this Document</a></li>
+ <li><a href="#s0.1">§0.1 Purpose(s) of this document</a></li>
+ <li><a href="#s0.2">§0.2 Text structure</a></li>
+ <li><a href="#s0.3">§0.3 Compiler messages</a></li>
+ <li><a href="#s0.4">§0.4 Versions</a></li>
+ <li><a href="#s0.5">§0.5 Publishing</a></li>
+ </ul>
+ </div>
+ <div class="intro">
+ <h3>Levels of this document</h3>
+ <div class="line"></div>
+ <div class="term">Terms, concepts</div>
+ <div class="termdesc">Each chapter of this document starts with a short synopsis of
+ concepts covered by the chapter (like this).
+ </div>
+ <div class="line"></div>
+ <div class="term">Definition</div>
+ <div class="termdesc">The actual definition is given in small numbered paragraphs.</div>
+ <div class="line"></div>
+ <div class="term">Examples</div>
+ <div class="termdesc">Examples and accompanying explanations will be interspersed
+ into the definition.
+ </div>
+ <div class="line"></div>
+ </div>
+ <div class="sect depth2" id="s0.1">
+ <h2 class="sect">§0.1 Purpose(s) of this document<a class="img" href="s0.html#s0.1"
+ title="PermaLink to §0.1 Purpose(s) of this document"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §0</a></span></h2>
+ <p>This document defines the OT/J programming language.
+ The main goals were to create a precise and complete reference for this language.
+ Didactical considerations had lower priorities, which means that this document is not designed
+ as an introductory tutorial.
+ Still, we advise programmers learning the OT/J language, to consult this document whenever
+ a compiler error message is not perfectly clear to them (see <a href="#s0.3" title="§0.3 Compiler messages" class="sect">§0.3</a>).
+
+ </p>
+ </div>
+ <div class="sect depth2" id="s0.2">
+ <h2 class="sect">§0.2 Text structure<a class="img" href="s0.html#s0.2"
+ title="PermaLink to §0.2 Text structure"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §0</a></span></h2>
+ <p>Each chapter of this document starts with a short synopsis of
+ concepts covered by the chapter (see above).
+
+ </p>
+ <div class="syntaxlink"><a href="sA.html" title="§A OT/J Syntax" class="syntax">→ Syntax §A</a></div>
+ <div class="subsect depth3" id="s0.2.a">
+ <h4 class="subsect">(a) <span class="title">Paragraphs</span><a class="img" href="s0.html#s0.2.a" title="PermaLink to (a) Paragraphs"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The actual definition is structured into small paragraphs for easy referral.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s0.2.b">
+ <h4 class="subsect">(b) <span class="title">Syntax Links</span><a class="img" href="s0.html#s0.2.b" title="PermaLink to (b) Syntax Links"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Links to the syntax precede definitions whenever new syntax is introduced.
+
+ </p>
+ </div>
+ <p>Interspersed you will find some example program listings.
+ Examples are typeset in a box:
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> ...</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>Explanations for examples look like the following:
+
+ </p>
+ <div class="codecomment">
+ <h5>Effects:</h5>
+ <ul>
+ <li>Lines 1-3 show a minimal OT/J program, which should not cause any headache.</li>
+ </ul>
+ </div>
+ <p>Examples are given for illustration only.
+
+ </p>
+ <p>Additional paragraphs like "Language implementation", or
+ "open issues" provide some background information which is
+ not necessary for understanding the definition, which might
+ however, help to understand why things are the way they are
+ and what other things might be added to the language in the future.
+
+ </p>
+ </div>
+ <div class="sect depth2" id="s0.3">
+ <h2 class="sect">§0.3 Compiler messages<a class="img" href="s0.html#s0.3"
+ title="PermaLink to §0.3 Compiler messages"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §0</a></span></h2>
+ <p>Error messages given by the Object Teams compiler refer to this
+ definition whenever appropriate. This way it should be easy to find
+ out, why the compiler rejected your program. Please make sure
+ you are using a language definition whose version matches the
+ version of your compiler.
+
+ </p>
+ </div>
+ <div class="sect depth2" id="s0.4">
+ <h2 class="sect">§0.4 Versions<a class="img" href="s0.html#s0.4"
+ title="PermaLink to §0.4 Versions"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §0</a></span></h2>
+ <p>The structure of this document has changed between versions
+ 0.6.1 and 0.7 of this document. This change reflects the
+ transition from our first compiler for OT/J (called <code>otc</code>)
+ and the <code>OTDT</code> (Object Teams Development Tooling)
+ plugin for Eclipse.
+
+ </p>
+ <p>Starting with the OTDT v0.7.x, the major and minor number of the tool
+ correspond to the major and minor version number of the OTJLD (this document),
+ ie., the OTDT v1.0.x implements the language as defined in the OTJLD v1.0.
+
+ </p>
+ <p><strong>Changes</strong> between the current and previous versions are listed in appendix <a href="sB.html" title="§B Changes between versions" class="sect">§B</a>.
+
+ </p>
+ </div>
+ <div class="sect depth2" id="s0.5">
+ <h2 class="sect">§0.5 Publishing<a class="img" href="s0.html#s0.5"
+ title="PermaLink to §0.5 Publishing"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §0</a></span></h2>
+ <p>The sources of this language definition are maintained in a target-independent XML format. Three different versions are generated
+ from these sources, using XSLT:
+ </p>
+ <ul>
+ <li><a href="http://www.objectteams.org/def/" class="ext">Online version</a> (XHTML)
+ </li>
+ <li>Tooling version (XHTML – directly accessible from inside the OTDT)</li>
+ <li>Print version (LaTeX/PDF)</li>
+ </ul>
+ </div>
+ </div>
+ <table class="nav">
+ <tr>
+ <td class="back"></td>
+ <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
+ <td class="next"><a href="s1.html" rel="next">§1 Teams and Roles >></a></td>
+ </tr>
+ </table>
+ </div>
+ <div id="footer">
+ <hr /><a class="w3c img" href="http://jigsaw.w3.org/css-validator/check/referer"
+ shape="rect"><img src="../images/valid-css2-blue.png" alt="Valid CSS!" height="31" width="88" /></a><a class="w3c img" href="http://validator.w3.org/check?uri=referer" shape="rect"><img src="../images/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31"
+ width="88" /></a><address>© Stephan Herrmann, Christine Hundt, Marco Mosconi</address>
+ OT/J version 1.3 — last modified: 2011-05-15
+ </div>
+ </body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s1.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s1.html
new file mode 100644
index 0000000..d2d5ae0
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s1.html
@@ -0,0 +1,1857 @@
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+ <link rel="stylesheet" type="text/css" href="../css/ot.css" />
+ <link rel="stylesheet" type="text/css" href="../css/otjld.css" />
+ <title>OT/J Language Definition v1.3</title>
+ </head>
+ <body class="otdt">
+ <div id="content">
+ <table class="nav">
+ <tr>
+ <td class="back"><a id="top"></a><a href="s0.html" rel="prev"><< §0 About this Document</a></td>
+ <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
+ <td class="next"><a href="s2.html" rel="next">§2 Role Binding >></a></td>
+ </tr>
+ </table>
+ <div class="chapter" id="s1">
+ <div class="headl">
+ <div class="headr">
+ <h1>§1 Teams and Roles</h1>
+ </div>
+ </div>
+ <div id="toc-box">
+ <ul class="toc-box">
+ <li><a href="s1.html">§1 Teams and Roles</a></li>
+ <li><a href="#s1.1">§1.1 Team classes</a></li>
+ <li><a href="#s1.2">§1.2 Role classes and objects</a></li>
+ <li><a href="#s1.3">§1.3 Acquisition and implicit inheritance of role classes</a></li>
+ <li><a href="#s1.4">§1.4 Name clashes</a></li>
+ <li><a href="#s1.5">§1.5 Team and role nesting</a></li>
+ </ul>
+ </div>
+ <div class="intro">
+ <h3>Fundamental concepts of Teams</h3>
+ <div class="line"></div>
+ <div class="term">Teams and Roles</div>
+ <div class="termdesc">Classes that are defined with the modifier <code>team</code>
+ are called team classes, or <strong>teams</strong> for short.<br />
+ Direct inner classes of a team are called role classes, or <strong>roles</strong>
+ for short.
+ </div>
+ <div class="line"></div>
+ <div class="term">Role inheritance</div>
+ <div class="termdesc">Inheritance between teams introduces a special inheritance relationship
+ between their contained roles. The rules of this <strong>implicit inheritance</strong> are given below (<a href="#s1.3.1"
+ title="§1.3.1 Acquisition and implicit inheritance of role classes"
+ class="sect">§1.3.1</a>).
+ </div>
+ <div class="line"></div>
+ <div class="term">Externalized role</div>
+ <div class="termdesc">Roles are generally confined to the context of their
+ enclosing team instance. Subject to specific restrictions,
+ a role <em>may</em> be passed outside
+ its team using the concept of externalized roles (<a href="#s1.2.2" title="§1.2.2 Externalized roles" class="sect">§1.2.2</a>).
+ </div>
+ <div class="line"></div>
+ </div>
+ <div class="sect depth2" id="s1.1">
+ <h2 class="sect">§1.1 Team classes<a class="img" href="s1.html#s1.1"
+ title="PermaLink to §1.1 Team classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §1</a></span></h2>
+ <div class="syntaxlink"><a href="sA.html#sA.1.1" title="§A.1.1 ClassDeclaration"
+ class="syntax">→ Syntax §A.1.1</a></div>
+ <p>A class declared with the modifier <code>team</code> is a <em>team class</em> (or team for short).
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <em><b>team</b> <b>class</b> MyTeamA</em> {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> ...</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>Teams are meant as containers for <em>roles</em>, which are defined in the following
+ paragraphs.
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <em><b>class</b> MyRole</em></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> ...</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>Teams introduce a new variant of inheritance for contained role classes
+ (see <a href="#s1.3.1"
+ title="§1.3.1 Acquisition and implicit inheritance of role classes"
+ class="sect">§1.3.1</a> below).
+ Other properties of teams, which are defined in later sections, are:
+
+ </p>
+ <ul>
+ <li>Team activation (<a href="s5.html" title="§5 Team Activation" class="sect">§5</a>)
+ </li>
+ <li>Abstractness and instantiation (<a href="s2.html#s2.5" title="§2.5 Abstract Roles" class="sect">§2.5</a>)
+ </li>
+ <li>Declared lifting in team methods (<a href="s2.html#s2.3.2" title="§2.3.2 Declared lifting"
+ class="sect">§2.3.2</a>)
+ </li>
+ <li>Reflective functions defined in <code>org.objectteams.ITeam</code> (<a href="s6.html#s6.1" title="§6.1 Reflection" class="sect">§6.1</a>)
+ </li>
+ </ul>
+ <p>Apart from these differences, team classes are regular Java classes with
+ methods and fields, whose instances are regular Java objects.
+
+ </p>
+ </div>
+ <div class="sect depth2" id="s1.2">
+ <h2 class="sect">§1.2 Role classes and objects<a class="img" href="s1.html#s1.2"
+ title="PermaLink to §1.2 Role classes and objects"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §1</a></span></h2>
+ <p>Each direct inner class of a team is a role class.
+ Just like inner classes, each instance of a role class has an implicit reference
+ to its enclosing team instance. This reference is immutable.
+ Within the implementation of a role it can be accessed by qualifying the identifier
+ <code>this</code> with the name of the team class, as in:
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <em><b>class</b> MyRole</em> {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>public</b> <b>void</b> print() { System.out.println("Team: "+ <em>MyTeamA.this</em>); }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>Creation of role instances is further restricted as defined in
+ <a href="s2.html#s2.4" title="§2.4 Explicit role creation"
+ class="sect">§2.4</a>.
+ Teams can also define role interfaces just like role classes.
+ With respect to role specific properties a role interface is treated like a fully
+ abstract class.
+
+ </p>
+ <div class="sect depth3" id="s1.2.1">
+ <h3 class="sect">§1.2.1 Modifiers for roles<a class="img" href="s1.html#s1.2.1"
+ title="PermaLink to §1.2.1 Modifiers for roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s1.2">↑ §1.2</a></span></h3>
+ <p>Member classes of a team cannot be <code>static</code>.
+ Also the use of access modifiers for roles is restricted and modifiers have different (stronger) semantics than for
+ regular classes (see below). With respect to accessibility a team acts mainly like a package regarding its roles.
+
+ </p>
+ <div class="subsect depth4" id="s1.2.1.a">
+ <h4 class="subsect">(a) <span class="title">Role class protection</span><a class="img" href="s1.html#s1.2.1.a"
+ title="PermaLink to (a) Role class protection"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role class must have exactly one of the access modifiers <code>public</code>
+ or <code>protected</code>.<br />
+ This rule does not affect the class modifiers <code>abstract</code>, <code>final</code> and <code>strictfp</code>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.1.b">
+ <h4 class="subsect">(b) <span class="title">protected role classes</span><a class="img" href="s1.html#s1.2.1.b"
+ title="PermaLink to (b) protected role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A <code>protected</code> role can only be accessed from within the enclosing
+ team or any of its sub-teams. The actual border of encapsulation is the
+ enclosing team <em>instance</em>. The rules for protected roles are given
+ in <a href="#s1.2.3" title="§1.2.3 Protected roles" class="sect">§1.2.3</a> below.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.1.c">
+ <h4 class="subsect">(c) <span class="title">public role classes</span><a class="img" href="s1.html#s1.2.1.c"
+ title="PermaLink to (c) public role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Only <code>public</code> roles can ever be accessed outside their enclosing team.
+ Accessing a role outside the enclosing team instance is governed by the rules
+ of <strong>externalized roles</strong>, to be defined next (<a href="#s1.2.2" title="§1.2.2 Externalized roles" class="sect">§1.2.2</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.1.d">
+ <h4 class="subsect">(d) <span class="title">abstract role classes</span><a class="img" href="s1.html#s1.2.1.d"
+ title="PermaLink to (d) abstract role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role class has to be marked <strong>abstract</strong> if any of its methods
+ is not effective.<br />
+ The <em>methods of a role class</em> comprise direct methods and
+ methods acquired by inheritance.
+ In addition to regular inheritance a role class may acquire methods
+ also via implicit inheritance (<a href="#s1.3.1"
+ title="§1.3.1 Acquisition and implicit inheritance of role classes"
+ class="sect">§1.3.1</a>).<br />
+ A method may become <em>effective</em> by either:
+
+ </p>
+ <ul>
+ <li>implementation (i.e., a regular method body), or</li>
+ <li>a callout binding (see <a href="s3.html" title="§3 Callout Binding" class="sect">§3</a>).
+ </li>
+ </ul>
+ <p><a href="s2.html#s2.5" title="§2.5 Abstract Roles" class="sect">§2.5</a> discusses under which
+ circumstances abstract roles force the enclosing team to be abstract, too.
+
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.1.e">
+ <h4 class="subsect">(e) <span class="title">Role features</span><a class="img" href="s1.html#s1.2.1.e"
+ title="PermaLink to (e) Role features"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Access modifiers for members of roles have some special interpretation:
+
+ </p>
+ <ol>
+ <li>A private member is also visible in any implicit sub role
+ (see implicit inheritance <a href="#s1.3.1.c"
+ title="§1.3.1.(c) Overriding and implicit inheritance"
+ class="sect">§1.3.1.(c)</a>).<br />
+ In contrast to inner classes in Java, private members of a role are not
+ visible to the enclosing team.
+ </li>
+ <li>The default visibility of role members restricts access to the
+ current class and its sub-classes (explicit and implicit).
+ </li>
+ <li><code>protected</code> role members can only be accessed from the enclosing
+ team or via <a href="s4.html" title="§4 Callin Binding" class="sect">callin (§4)</a>.
+ </li>
+ <li><code>public</code> role members grant unrestricted access.
+ </li>
+ </ol>
+ <p>Additionally, a role always has access to all the features that its enclosing team has access to.</p>
+ <p>Only <code>public</code> members can ever be accessed via an <a href="#s1.2.2" title="§1.2.2 Externalized roles" class="sect">externalized role (§1.2.2)</a>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.1.f">
+ <h4 class="subsect">(f) <span class="title">Static role methods</span><a class="img" href="s1.html#s1.2.1.f"
+ title="PermaLink to (f) Static role methods"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>In contrast to inner classes in pure Java, a role class may indeed define static methods. A static role method requires no
+ role
+ instance <em>but</em> it still requires a team instance in scope. Static role methods can be called:
+
+ </p>
+ <ul>
+ <li>from the enclosing team,</li>
+ <li>via callin (see <a href="s4.html#s4.7"
+ title="§4.7 Callin binding with static methods"
+ class="sect">§4.7</a>).
+ </li>
+ </ul>
+ <p>Within a static role method the syntax <code>MyTeam.this</code> is available for accessing the enclosing team instance.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.1.g">
+ <h4 class="subsect">(g) <span class="title">No static initializers</span><a class="img" href="s1.html#s1.2.1.g"
+ title="PermaLink to (g) No static initializers"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A static field of a role class must not have a non-constant initialization expression.
+ Static initialization blocks are already prohibited for inner classes by Java (see <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#262890"
+ class="ext">JLS §8.1.2</a>).
+
+ </p>
+ <div class="note">
+ <h5>Note:</h5>
+ Static initialization generally provides a means for performing initialization code prior to instantiation, i.e., at
+ class-loading time.
+ Before any role can be created already two levels of initialization are performed: (1) The (outer most) enclosing team
+ class performs static initializations when it is loaded. (2) Any enclosing team executes
+ its constructor when it is instantiated. It should be possible to allocate any early initialization to either of these
+ two phases instead of using static role initializers.
+
+ </div>
+ </div>
+ </div>
+ <div class="sect depth3" id="s1.2.2">
+ <h3 class="sect">§1.2.2 Externalized roles<a class="img" href="s1.html#s1.2.2"
+ title="PermaLink to §1.2.2 Externalized roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s1.2">↑ §1.2</a></span></h3>
+ <div class="syntaxlink"><a href="sA.html#sA.9.2" title="§A.9.2 ActualTypeArgument"
+ class="syntax">→ Syntax §A.9.2</a></div>
+ <p>Normally, a team encapsulates its role against unwanted access from the outside.
+ If roles are visible outside their enclosing team instance we speak of
+ <strong>externalized roles</strong>.
+
+ </p>
+ <p>Externalized roles are subject to specific typing rules in order to ensure,
+ that role instances from different team instances cannot be mixed in
+ inconsistent ways. In the presence of implicit inheritance
+ (<a href="#s1.3.1"
+ title="§1.3.1 Acquisition and implicit inheritance of role classes"
+ class="sect">§1.3.1</a>) inconsistencies could otherwise occur, which lead
+ to typing errors that could only be detected at run-time.
+ Externalized roles use the theory of
+ "virtual classes" <a href="#fn1-virtual-classes" class="int">[1]</a>,
+ or more specifically
+ "family polymorphism" <a href="#fn2-family-polymorphism" class="int">[2]</a>,
+ in order to achieve the desired type safety.
+ These theories use special forms of <em>dependent types</em>.
+ Externalized roles have <em>types that depend on a team instance</em>.
+
+ </p>
+ <p><a href="#s1.2.3" title="§1.2.3 Protected roles" class="sect">§1.2.3</a> deduces even stronger forms of encapsulation
+ from the rules about externalized roles.
+
+ </p>
+ <div class="subsect depth4" id="s1.2.2.a">
+ <h4 class="subsect">(a) <span class="title">Visibility</span><a class="img" href="s1.html#s1.2.2.a" title="PermaLink to (a) Visibility"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Only instances of a <code>public</code> role class can ever be externalized.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.b">
+ <h4 class="subsect">(b) <span class="title">Declaration with anchored type</span><a class="img" href="s1.html#s1.2.2.b"
+ title="PermaLink to (b) Declaration with anchored type"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Outside a team role types are legal only if denoted relative
+ to an existing team instance (further on called "anchored types").
+ The syntax is:
+ </p>
+ <div class="listing plain"><pre><em>final</em> MyTeam myTeam = <i>expression</i>;
+<em>RoleClass<@myTeam></em> role = <i>expression</i>;</pre></div>
+ <p>The syntax <code>Type<@anchor></code> is a special case of a parameterized type, more specifically a <a href="s9.html" title="§9 Value Dependent Classes" class="sect">value dependent type (§9)</a>.
+ The type argument (i.e., the expression after the at-sign) can be a simple name or a path. It must refer to an instance
+ of a team class.
+ The role type is said to be <em>anchored</em> to this team instance.<br />
+ The type-part of this syntax (in front of the angle brackets) must be the simple name of a role type directly contained
+ in the given team (including roles that are acquired by implicit inheritance).<br /></p>
+ <div class="note">
+ <h5>Note:</h5>
+ Previous versions of the OTJLD used a different syntax for anchored types, where the role type was prefixed with the anchor
+ expression, separated by a dot (<code>anchor.Type</code>,
+ see <a href="sA.html#sA.6.3" title="§A.6.3 AnchoredType" class="sect">§A.6.3</a>). A compiler may still support that path syntax but it should be flagged as being deprecated.
+
+ </div>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.c">
+ <h4 class="subsect">(c) <span class="title">Immutable anchor</span><a class="img" href="s1.html#s1.2.2.c"
+ title="PermaLink to (c) Immutable anchor"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Anchoring the type of an externalized role to a team instance
+ requires the team to be referenced by a variable which
+ is marked <code>final</code> (i.e., immutable).
+ The type anchor can be a path <code>v.f1.f2...</code> where
+ <code>v</code> is any final variable and <code>f1</code> ...
+ are final fields.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.d">
+ <h4 class="subsect">(d) <span class="title">Implicit type anchors</span><a class="img" href="s1.html#s1.2.2.d"
+ title="PermaLink to (d) Implicit type anchors"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The current team instance can be used as a default anchor
+ for role types:
+
+ </p>
+ <ol>
+ <li>In non-static team level methods role types are by default interpreted as anchored to <code>this</code> (referring to the team instance). I.e., the following two declarations express the same:
+
+ <div class="listing plain"><pre><b>public</b> RoleX getRoleX (RoleY r) { <i> stmts </i> }
+<b>public</b> RoleX<@<em>this</em>> getRoleX (RoleY<@<em>this</em>> r) { <i> stmts </i> }</pre></div>
+ </li>
+ <li>
+ In analogy, <em>role methods</em> use the enclosing team instance as the
+ default anchor for any role types.
+ </li>
+ </ol>
+ <p>Note, that <code>this</code> and <code><em>Outer</em>.this</code> are always
+ <code>final</code>.<br />
+ The compiler uses the pseudo identifier <strong><code>tthis</code></strong> to denote
+ such implicit type anchors in error messages.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.e">
+ <h4 class="subsect">(e) <span class="title">Conformance</span><a class="img" href="s1.html#s1.2.2.e" title="PermaLink to (e) Conformance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Conformance between
+ two types <code>RoleX<@teamA></code> and <code>RoleY<@teamB></code>
+ not only requires the role types to be compatible, but also
+ the team instances to be provably <em>the same object</em>.
+ The compiler must be able to statically analyze anchor identity.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.f">
+ <h4 class="subsect">(f) <span class="title">Substitutions for type anchors</span><a class="img" href="s1.html#s1.2.2.f"
+ title="PermaLink to (f) Substitutions for type anchors"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Only two substitutions are considered for determining
+ team identity:
+
+ </p>
+ <ol>
+ <li>
+ For type checking the application of team methods,
+ <code>this</code> is <strong>substituted</strong> by the actual call target.
+ For role methods a reference of the form <code><em>Outer</em>.this</code>
+ is substituted by the enclosing instance of the call target.
+
+ </li>
+ <li>Assignments from a <code>final</code> identifier
+ to another <code>final</code> identifier are transitively
+ followed, i.e., if <code>t1, t2</code> are final,
+ after an assignment <code>t1=t2</code>
+ the types <code>R<@t1></code> and <code>R<@t2></code> are considered
+ identical. Otherwise <code>R<@t1></code> and <code>R<@t2></code>
+ are incommensurable.<br />
+ Attaching an actual parameter to a formal parameter in a
+ method call is also considered as an assignment with respect to
+ this rule.
+
+ </li>
+ </ol>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.g">
+ <h4 class="subsect">(g) <span class="title">Legal contexts</span><a class="img" href="s1.html#s1.2.2.g"
+ title="PermaLink to (g) Legal contexts"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Anchored types for externalized roles may be used in the
+ following contexts:
+
+ </p>
+ <ol>
+ <li>Declaration of an attribute</li>
+ <li>Declaration of a local variable</li>
+ <li>Declaration of a parameter or result type
+ of a method or constructor
+ </li>
+ <li>In the <code>playedBy</code> clause of a role class
+ (see <a href="s2.html#s2.1" title="§2.1 playedBy relation" class="sect">§2.1</a>).
+ </li>
+ </ol>
+ <p>It is not legal to inherit from an anchored type, since
+ this would require membership of the referenced team instance,
+ which can only be achieved by class nesting.
+
+ </p>
+ <div class="note">
+ <h5>Note:</h5>
+ Item 4.
+ — within the given restriction — admits the case where
+ the same class is a role of one team and the base class for
+ the role of another team. Another form of nesting is
+ defined in <a href="#s1.5" title="§1.5 Team and role nesting" class="sect">§1.5</a>.
+
+ </div>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.h">
+ <h4 class="subsect">(h) <span class="title">Externalized creation</span><a class="img" href="s1.html#s1.2.2.h"
+ title="PermaLink to (h) Externalized creation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role can be created as externalized using either of these equivalent forms:</p>
+ <div class="listing plain"><pre>outer.<b>new</b> Role()
+<b>new</b> Role<@outer>()</pre></div>
+ <p>This requires the enclosing instance <code>outer</code> to be
+ declared <code>final</code>. The expression has the
+ type <code>Role<@outer></code> following the rules of
+ externalized roles.<br />
+ The type <code>Role</code> in this expression must be a simple
+ (unqualified) name.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.2.i">
+ <h4 class="subsect">(i) <span class="title">No import</span><a class="img" href="s1.html#s1.2.2.i" title="PermaLink to (i) No import"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>It is neither useful nor legal to import a role type.<br /></p>
+ <div class="note">
+ <h5>Rationale:</h5>
+ Importing a type allows to use the unqualified name in situations that would otherwise require to use the fully qualified
+ name,
+ i.e., the type prefixed with its containing package and enclosing class. Roles, however are contained in a team <i>instance</i>.
+ Outside their team, role types can only be accessed using an anchored type which uses a team instance to qualify the
+ role type.
+ Relative to this team anchor, roles are <i>always</i> denoted using their simple name, which makes importing roles useless.
+
+ </div>
+ <p>A static import for a constant declared in a role is, however, legal.
+
+ </p>
+ </div>
+ <h5 class="listing">Example code (Externalized Roles):</h5>
+ <div class="listing example frame" id="l1.2.2-1">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>team</b> <b>class</b> FlightBonus <b>extends</b> Bonus {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> Subscriber {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>void</b> clearCredits() { ... }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <b>void</b> unsubscribe(Subscriber subscr) { ... }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="listing example frame" id="l1.2.2-2">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre><b>class</b> ClearAction <b>extends</b> Action {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> <em>final</em> FlightBonus context;</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre> <em>Subscriber<@context></em> subscriber;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre> ClearAction (<em>final</em> FlightBonus bonus, <em>Subscriber<@bonus></em> subscr) {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre> context = bonus; <span class="comment">// unique assignment to 'context'</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">12</td>
+ <td><pre> subscriber = subscr;</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">13</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">14</td>
+ <td><pre> <b>void</b> actionPerformed () {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">15</td>
+ <td><pre> subscriber.clearCredits();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">16</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">17</td>
+ <td><pre> <b>protected</b> <b>void</b> finalize () {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">18</td>
+ <td><pre> context.unsubscribe(subscriber);</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">19</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">20</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="codecomment">
+ <h5>Effects:</h5>
+ <ul>
+ <li>Lines 1-6 show a terse extract of a published example
+ <a href="http://www.objectteams.org/publications/index.html#NODe02" class="ext">[NODe02]</a>. Here passengers can be subscribers in a flight bonus program.
+ </li>
+ <li>Lines 7-20 show a sub-class of <code>Action</code> which is
+ used to associate the action of resetting a subscriber's credits
+ to a button or similar element in an application's GUI.
+ </li>
+ <li>Attribute <code>context</code> (line 8) and parameter
+ <code>bonus</code> (line 10) serve as anchor for the type of
+ externalized roles.
+ </li>
+ <li>Attribute <code>subscriber</code> (line 9) and parameter
+ <code>subscr</code> (line 10) store a Subscriber role outside the
+ FlightBonus team.
+ </li>
+ <li>In order to type-check the assignment in line 12, the compiler
+ has to ensure that the types of LHS and RHS are anchored to
+ the same team instance. This can be verified by checking that
+ both anchors are indeed <code>final</code> and prior to the
+ role assignment a team assignment has taken place (line 11).<br /><span class="underline">Note,</span> that the Java rules for <strong>definite assignments</strong> to
+ final variables ensure that exactly one assignment to a variable occurs
+ prior to its use as type anchor. No further checks are needed.
+
+ </li>
+ <li>It is now legal to store this role reference and use it at
+ some later point in time, e.g., for invoking method
+ <code>clearCredits</code> (line 15).
+ This method call is also an example for implicit team activation
+ (<a href="s5.html#s5.3.b"
+ title="§5.3.(b) Methods of externalized roles"
+ class="sect">§5.3.(b)</a>).
+
+ </li>
+ <li>Line 18 demonstrates how an externalized role can be
+ passed to a team level method. The signature of <code>unsubscribe</code>
+ is for this call expanded to
+ <div class="indent">
+ void unsubscribe(Subscriber<@context> subscr)
+
+ </div>
+ (by substituting the call target <code>context</code> for
+ <code>this</code>). This proves identical types for actual and
+ formal parameters.
+ </li>
+ </ul>
+ </div>
+ </div>
+ <div class="sect depth3" id="s1.2.3">
+ <h3 class="sect">§1.2.3 Protected roles<a class="img" href="s1.html#s1.2.3"
+ title="PermaLink to §1.2.3 Protected roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s1.2">↑ §1.2</a></span></h3>
+ <p>Roles can only be <code>public</code> or <code>protected</code>.
+ A <code>protected</code> role is encapsulated
+ by its enclosing team instance. This is enforced by these rules:
+
+ </p>
+ <div class="subsect depth4" id="s1.2.3.a">
+ <h4 class="subsect">(a) <span class="title">Importing role classes</span><a class="img" href="s1.html#s1.2.3.a"
+ title="PermaLink to (a) Importing role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p><i>This rule is superseded by <a href="#s1.2.2.i" title="§1.2.2.(i) No import" class="sect">§1.2.2.(i)</a></i></p>
+ </div>
+ <div class="subsect depth4" id="s1.2.3.b">
+ <h4 class="subsect">(b) <span class="title">Qualified role types</span><a class="img" href="s1.html#s1.2.3.b"
+ title="PermaLink to (b) Qualified role types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The name of a <code>protected</code> role class may never be used qualified, neither
+ prefixed by its <em>enclosing type</em> nor parameterized by a <em>variable as type anchor</em> (cf. <a href="#s1.2.2.a" title="§1.2.2.(a) Visibility" class="sect">§1.2.2.(a)</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.3.c">
+ <h4 class="subsect">(c) <span class="title">Mixing qualified and unqualified types</span><a class="img" href="s1.html#s1.2.3.c"
+ title="PermaLink to (c) Mixing qualified and unqualified types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>An externalized role type is never compatible to an unqualified role type,
+ except for the substitutions in <a href="#s1.2.2.f"
+ title="§1.2.2.(f) Substitutions for type anchors"
+ class="sect">§1.2.2.(f)</a>, where
+ an explicit anchor can be matched with the implicit anchor <code>this</code>.
+
+ </p>
+ </div>
+ <p>Rules (a) and (b) ensure that the name of a protected role class cannot be used
+ outside the lexical scope of its enclosing team. Rule (c) ensures that team methods
+ containing unqualified role types in their signature cannot be invoked on a team other
+ than the current team. Accordingly, for role methods the team context must be the
+ enclosing team instance.
+
+ </p>
+ <div class="subsect depth4" id="s1.2.3.d">
+ <h4 class="subsect">(d) <span class="title">Levels of encapsulation</span><a class="img" href="s1.html#s1.2.3.d"
+ title="PermaLink to (d) Levels of encapsulation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Since protected role types can not be used for externalization, instances of these types are already quite effectively encapsulated
+ by their enclosing team.
+ Based on this concept, encapsulation for protected roles can be made even stricter by the rules of <em>role confinement</em>.
+ On the contrary, even protected roles can be externalized as <em>opaque roles</em> which still expose (almost) no information.
+ Confinement and opaque roles are subject of <a href="s7.html" title="§7 Role Encapsulation" class="sect">§7</a>.
+
+ </p>
+ </div>
+ </div>
+ <div class="sect depth3" id="s1.2.4">
+ <h3 class="sect">§1.2.4 Type tests and casts<a class="img" href="s1.html#s1.2.4"
+ title="PermaLink to §1.2.4 Type tests and casts"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s1.2">↑ §1.2</a></span></h3>
+ <p>In accordance with <a href="#s1.2.2.e" title="§1.2.2.(e) Conformance" class="sect">§1.2.2.(e)</a>, in OT/J
+ the <code>instanceof</code> operator and type casts have extended semantics for roles.
+
+ </p>
+ <div class="subsect depth4" id="s1.2.4.a">
+ <h4 class="subsect">(a) <span class="title">instanceof</span><a class="img" href="s1.html#s1.2.4.a" title="PermaLink to (a) instanceof"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>For role types the <code>instanceof</code> operator yields true only if
+ both components of the type match: the dynamic role type must be compatible
+ to the given static type, and also type anchors must be the same instance.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.4.b">
+ <h4 class="subsect">(b) <span class="title">Casting</span><a class="img" href="s1.html#s1.2.4.b" title="PermaLink to (b) Casting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Casts may also fail if the casted expression is anchored to a different
+ team instance than the cast type. Such failure is signaled by a
+ <code>org.objectteams.RoleCastException</code>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.4.c">
+ <h4 class="subsect">(c) <span class="title">Class literal</span><a class="img" href="s1.html#s1.2.4.c"
+ title="PermaLink to (c) Class literal"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A class literal of form <code>R.class</code> is dynamically bound to the class <code>R</code>
+ visible in the current instance context. Using a class literal for a role outside its
+ enclosing team instance (see <a href="#s1.2.2" title="§1.2.2 Externalized roles" class="sect">§1.2.2</a>) requires the following syntax:
+
+ </p>
+ <div class="listing plain"><pre>RoleClass<em><@teamAnchor></em><strong>.class</strong></pre></div>
+ </div>
+ </div>
+ <div class="sect depth3" id="s1.2.5">
+ <h3 class="sect">§1.2.5 File structure<a class="img" href="s1.html#s1.2.5"
+ title="PermaLink to §1.2.5 File structure"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s1.2">↑ §1.2</a></span></h3>
+ <p>Just like regular inner classes, role classes may be inlined in the
+ source code of the enclosing team. As an alternative style it is possible
+ to store role classes in separate <strong>role files</strong> according to the following rules:
+
+ </p>
+ <div class="subsect depth4" id="s1.2.5.a">
+ <h4 class="subsect">(a) <span class="title">Role directory</span><a class="img" href="s1.html#s1.2.5.a"
+ title="PermaLink to (a) Role directory"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>In the directory of the team class a new directory is created
+ which has the same name as the team without the <tt>.java</tt> suffix.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.5.b">
+ <h4 class="subsect">(b) <span class="title">Role files</span><a class="img" href="s1.html#s1.2.5.b" title="PermaLink to (b) Role files"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Role classes are stored in this directory (a). The file names are
+ derived from the role class name extended by <tt>.java</tt>.<br />
+ A role file must contain exactly one top-level type.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.5.c">
+ <h4 class="subsect">(c) <span class="title">package statement</span><a class="img" href="s1.html#s1.2.5.c"
+ title="PermaLink to (c) package statement"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role class in a role file declares as its package the fully qualified
+ name of the enclosing team class. The package statement of a role file
+ must use the <code>team</code> modifier as its first token.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.5.d">
+ <h4 class="subsect">(d) <span class="title">Reference to role file</span><a class="img" href="s1.html#s1.2.5.d"
+ title="PermaLink to (d) Reference to role file"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A team should mention in its javadoc comment each role class which
+ is stored externally using a <tt>@role</tt> tag.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.5.e">
+ <h4 class="subsect">(e) <span class="title">Legal types in role files</span><a class="img" href="s1.html#s1.2.5.e"
+ title="PermaLink to (e) Legal types in role files"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The type in a role file must not be an <code>enum</code>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.2.5.f">
+ <h4 class="subsect">(f) <span class="title">Imports in role files</span><a class="img" href="s1.html#s1.2.5.f"
+ title="PermaLink to (f) Imports in role files"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role file may have imports of its own.
+ Within the role definition these imports are visible <em>in addition</em> to all imports of the enclosing team.
+ Only <code>base</code> imports (see <a href="s2.html#s2.1.2.d" title="§2.1.2.(d) Base imports"
+ class="sect">§2.1.2.(d)</a>)
+ <em>must</em> be defined in the team.
+ </p>
+ </div>
+ <p>Semantically, there is no difference between inlined role classes and those
+ stored in separate role files.
+
+ </p>
+ <div class="note">
+ <h5>Note:</h5>
+ Current Java compilers disallow a type to have the same fully qualified
+ name as a package. However, the JLS does not seem to make a statement in this respect.
+ In OT/J, a package and a type are interpreted as being the same team, if both have the
+ same fully qualified name and both have the <code>team</code> modifier.
+
+ </div>
+ <h5 class="listing">Role file example:</h5>
+ <div class="listing example frame" id="l1.2.5-1">
+ <table class="listing">
+ <tr class="lhead">
+ <td colspan="2">in file <code>org/objectteams/examples/MyTeamA.java</code> :
+ </td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>package</b> org.objectteams.examples;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre><span class="comment">/**</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <span class="comment">* @author Stephan Herrmann</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <span class="comment">* @date 20.02.2007</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <span class="comment">* @file MyTeamA.java</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> <span class="comment">* <em>@role MyRole</em></span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <span class="comment">*/</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre> ...</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="listing example frame" id="l1.2.5-2">
+ <table class="listing">
+ <tr class="lhead">
+ <td colspan="2">in file <code>org/objectteams/examples<strong class="blue">/MyTeamA/MyRole.java</strong></code>:
+ </td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><em><b>team</b> <b>package</b> org.objectteams.examples.MyTeamA;</em></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre><b>public</b> <b>class</b> MyRole {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> ...</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ </div>
+ <div class="sect depth2" id="s1.3">
+ <h2 class="sect">§1.3 Acquisition and implicit inheritance of role classes<a class="img" href="s1.html#s1.3"
+ title="PermaLink to §1.3 Acquisition and implicit inheritance of role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §1</a></span></h2>
+ <p> Every team class implicitly implements the predefined interface <code>org.objectteams.ITeam</code>.
+ If a team class has no explicit <code>extends</code> clause it implicitly extends <code>org.objectteams.Team</code>,
+ thus providing implementations for the methods in <code>org.objectteams.ITeam</code>.
+ If a team class extends a non-team class, the compiler implicitly adds implementations for all methods declared
+ in <code>org.objectteams.ITeam</code> to the team class.
+ Any subclass of a team (including <code>org.objectteams.Team</code>) must again be a team.
+ Interface implementation is not affected by this rule.
+
+ </p>
+ <p>Infrastructure provided via interface <code>org.objectteams.ITeam</code> is presented in <a href="s6.html" title="§6 Object Teams API" class="sect">§6</a>.
+
+ </p>
+ <div class="sect depth3" id="s1.3.1">
+ <h3 class="sect">§1.3.1 Acquisition and implicit inheritance of role classes<a class="img" href="s1.html#s1.3.1"
+ title="PermaLink to §1.3.1 Acquisition and implicit inheritance of role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s1.3">↑ §1.3</a></span></h3>
+ <p>A team acquires all roles from its super-team. This relation is
+ similar to inheritance of inner classes, but with a few decisive
+ differences as defined next. Two implementation options are mentioned <a href="#aux1.1" class="int">below</a>,
+ which can be used to realize the special semantics of role
+ acquisition (virtual classes and copy inheritance).
+
+ </p>
+ <h5 class="listing">Implicit role inheritance</h5>
+ <div class="listing example frame" id="l1.3.1-1">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> S {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>protected</b> <b>class</b> R0 {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>protected</b> <b>class</b> R1 <em><b>extends</b> R0</em> {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>boolean</b> ok;</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> R2 m() {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> <b>void</b> n(<em>R2</em> r) {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> <b>protected</b> <b>class</b> R2 {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="listing example frame" id="l1.3.1-2">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">10</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> T <em><b>extends</b> S</em> {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">11</td>
+ <td><pre> @Override <b>protected</b> <em><b>class</b> R1</em> {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">12</td>
+ <td><pre> <strong>R2</strong> m() {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">13</td>
+ <td><pre> if(<em>ok</em>) { <b>return</b> <em>tsuper</em>.m(); }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">14</td>
+ <td><pre> <b>else</b> { <b>return</b> null; }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">15</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">16</td>
+ <td><pre> <b>void</b> doIt() {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">17</td>
+ <td><pre> n(m());</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">18</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">19</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">20</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.a">
+ <h4 class="subsect">(a) <span class="title">Role class acquisition</span><a class="img" href="s1.html#s1.3.1.a"
+ title="PermaLink to (a) Role class acquisition"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A team <code>T</code> which extends a super-team <code>S</code>
+ has one role class <code>T.R</code> corresponding to each role <code>S.R</code>
+ of the super-team.
+ The new type <code>T.R</code> <strong>overrides</strong> <code>R</code> for the
+ context of <code>T</code> and its roles.
+ Acquisition of role classes can either be direct (see (b) below), or
+ it may involve overriding and implicit inheritance ((c) below).
+
+ </p>
+ <div class="codecomment">In the above example (<a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a>) the team <code>S</code> operates
+ on types <code>S.R0</code>, <code>S.R1</code> and <code>S.R2</code>,
+ while <code>T</code> operates on types <code>T.R0</code>, <code>T.R1</code>
+ and <code>T.R2</code>.<br /><em>(Type references like "<code>S.R0</code>" are actually illegal in source code
+ (<a href="#s1.2.3.b" title="§1.2.3.(b) Qualified role types"
+ class="sect">§1.2.3.(b)</a>). Here they are used for explanatory purposes only)</em></div>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.b">
+ <h4 class="subsect">(b) <span class="title">Direct role acquisition</span><a class="img" href="s1.html#s1.3.1.b"
+ title="PermaLink to (b) Direct role acquisition"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Within a sub-team <code>T</code> each role <code>S.R</code> of its
+ super-team <code>S</code> is available by the simple name <code>R</code>
+ without further declaration.
+
+ </p>
+ <div class="codecomment">The role <code>R2</code> in <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> can be used in the sub-team
+ <code>T</code> (line 12), because this role type is defined in the super class of the enclosing team.
+
+ </div>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.c">
+ <h4 class="subsect">(c) <span class="title">Overriding and implicit inheritance</span><a class="img" href="s1.html#s1.3.1.c"
+ title="PermaLink to (c) Overriding and implicit inheritance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a team contains a role class definition by the same name as
+ a role defined in its super-team,
+ the new role class overrides the corresponding role from the super-team
+ and <strong>implicitly inherits</strong> all of its features.
+ Such relation is established only by name correspondence.
+
+ </p>
+ <p>A role that overrides an inherited role should be marked with an <code>@Override</code> annotation.
+ A compiler should optionally flag a missing <code>@Override</code> annotation with a warning.
+ Conversely, it is an error if a role is marked with an <code>@Override</code> annotation but does not actually
+ override an inherited role.
+
+ </p>
+ <p>It is an error to override a role class with an interface or vice versa. A final role cannot be overridden.<br />
+ Unlike regular inheritance, <strong>constructors</strong> are also inherited
+ along implicit inheritance, and can be overridden just like normal methods.
+
+ </p>
+ <div class="codecomment">
+ In <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a><code> R1</code> in <code>T</code> implicitly inherits all features of
+ <code>R1</code> in <code>S</code>. This is, because its enclosing team
+ <code>T</code> extends the team <code>S</code> (line 10) and the role
+ definition uses the same name <code>R1</code> (line 11).
+ Hence the attribute <code><strong>ok</strong></code> is available in the method
+ <code>m()</code> in <code>T.R1</code> (line 13). <code>T.R1</code> also overrides <code>S.R1</code>
+ which is marked by the <code>@Override</code> annotation in line 11.
+
+ </div>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.d">
+ <h4 class="subsect">(d) <span class="title">Lack of subtyping</span><a class="img" href="s1.html#s1.3.1.d"
+ title="PermaLink to (d) Lack of subtyping"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Direct acquisition of roles from a super-team and implicit inheritance
+ do not establish a <strong>subtype</strong> relation.
+ A role of a given team is never conform (i.e., substitutable)
+ to any role of any <em>other</em> team.
+ <code>S.R</code> and <code>T.R</code> are always incommensurable.<br /><span class="underline">Note,</span> that this rule is a direct consequence of <a href="#s1.2.2.e" title="§1.2.2.(e) Conformance" class="sect">§1.2.2.(e)</a>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.e">
+ <h4 class="subsect">(e) <span class="title">Dynamic binding of types</span><a class="img" href="s1.html#s1.3.1.e"
+ title="PermaLink to (e) Dynamic binding of types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Overriding an acquired role by a new role class has the following
+ implication: If an expression or declaration, which is evaluated on behalf of
+ an instance of team <code>T</code> or one of its contained roles,
+ refers to a role <code>R</code>, <code>R</code> will always
+ resolve to <code>T.R</code> even if <code>R</code> was introduced in
+ a super-team of <code>T</code> and even if the specific line of code
+ was inherited from a super-team or one of its roles.
+ Only the dynamic type of the enclosing team-instance is used to determine
+ the correct role class (see below for an example).
+
+ </p>
+ <p>A special case of dynamically binding role types relates to so-called class literals
+ (see <a href="http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#251530"
+ class="ext">JLS §15.8.2</a>).
+ Role class literals are covered in <a href="s6.html#s6.1.c" title="§6.1.(c) Class literals for roles"
+ class="sect">§6.1.(c)</a>.
+
+ </p>
+ <p>The above is strictly needed only for cases involving implicit inheritance.
+ It may, however, help intuition, to also consider the directly acquired
+ role <code>T.R</code> in (b) to override the given role <code>S.R</code>.
+
+ </p>
+ <div class="codecomment">
+ In line 17 of <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> the implicitly inherited method <code>n</code> is called
+ with the result of an invocation of <code>m</code>. Although
+ <code>n</code> was defined in <code>S</code> (thus with argument type
+ <code>S.R2, see line 6</code>) in the context of <code>T</code> it
+ expects an argument of <code>T.R2</code>. This is correctly provided by
+ the invocation of <code>m</code> in the context of <code>T</code>.
+
+ </div>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.f">
+ <h4 class="subsect">(f) <span class="title">tsuper</span><a class="img" href="s1.html#s1.3.1.f" title="PermaLink to (f) tsuper"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <div class="syntaxlink"><a href="sA.html#sA.5.4" title="§A.5.4 TSuperCall" class="syntax">→ Syntax §A.5.4</a></div>
+ <p>Super calls along implicit inheritance use the new keyword
+ <strong>tsuper</strong>. While <code>super</code> is still available
+ along regular inheritance, a call <code>tsuper.m()</code>
+ selects the version of <code>m</code> of the corresponding role
+ acquired from the super-team.
+
+ </p>
+ <p>See <a href="s2.html#s2.4.2"
+ title="§2.4.2 Role creation via a regular constructor"
+ class="sect">§2.4.2</a> for <code>tsuper</code>
+ in the context of role constructors.
+
+ </p>
+ <p><code>tsuper</code> can only be used to invoke a corresponding
+ version of the enclosing method or constructor, i.e., an expression
+ <code>tsuper.m()</code> may only occur within the method <code>m</code>
+ with both methods having the same signature
+ (see <a href="s2.html#s2.3.2.b"
+ title="§2.3.2.(b) Super in the context of declared lifting"
+ class="sect">§2.3.2.(b)</a> for an exception, where both methods have slightly different signatures).
+
+ </p>
+ <div class="codecomment">
+ In <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> the role <code>R1</code> in team <code>T</code>
+ overrides the implicitly inherited method <code>m()</code> from <code>S</code>. <code><strong>tsuper</strong>.m()</code> calls the overridden method <code>m()</code>
+ from <code>S.R1</code> (line 13).
+
+ </div>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.g">
+ <h4 class="subsect">(g) <span class="title">Implicitly inheriting super-types</span><a class="img" href="s1.html#s1.3.1.g"
+ title="PermaLink to (g) Implicitly inheriting super-types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a role class has an explicit super class (using <code>extends</code>)
+ this relation is inherited along implicit inheritance.
+
+ </p>
+ <div class="codecomment">
+ In <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> the role <code>R1</code> in <code>T</code> has <code>T.R0</code>
+ as its implicitly inherited super class, because the corresponding role in the super-team
+ <code><strong>extends R0</strong></code> (line 3).
+
+ </div>
+ <p>Overriding an implicitly inherited super class is governed by
+ <a href="#s1.3.2.b"
+ title="§1.3.2.(b) Inheriting and overriding the extends clause"
+ class="sect">§1.3.2.(b)</a>, below.<br />
+ The list of implemented interfaces is merged along implicit
+ inheritance.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.h">
+ <h4 class="subsect">(h) <span class="title">Preserving visibility</span><a class="img" href="s1.html#s1.3.1.h"
+ title="PermaLink to (h) Preserving visibility"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role class must provide at least as much access as the implicit super role,
+ or a compile-time error occurs (this is in analogy to <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#227965"
+ class="ext">JLS §8.4.6.3</a>).
+ Access rights of methods overridden by implicit inheritance follow
+ the same rules as for normal overriding.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.i">
+ <h4 class="subsect">(i) <span class="title">Dynamic binding of constructors</span><a class="img" href="s1.html#s1.3.1.i"
+ title="PermaLink to (i) Dynamic binding of constructors"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>When creating a role instance using <code>new</code> not only the
+ type to instantiate is bound dynamically (cf. <a href="#s1.3.1.e" title="§1.3.1.(e) Dynamic binding of types"
+ class="sect">§1.3.1.(e)</a>), but also the constructor to
+ invoke is dynamically bound in accordance to the concrete
+ type.<br />
+ Within role constructors all <code>this(..)</code> and
+ <code>super(..)</code> calls are bound statically with respect to explicit inheritance
+ and dynamically with respect to implicit inheritance. This means the target role name is
+ determined statically, but using that name the suitable role type is determined
+ using dynamic binding.
+ <br />
+ See also <a href="s2.html#s2.5.a"
+ title="§2.5.(a) Using abstract classes for creation"
+ class="sect">§2.5.(a)</a> on using constructors of abstract role classes.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.j">
+ <h4 class="subsect">(j) <span class="title">Overriding and compatibility</span><a class="img" href="s1.html#s1.3.1.j"
+ title="PermaLink to (j) Overriding and compatibility"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The rules of <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#228745"
+ class="ext">JLS §8.4.6</a>
+ also apply to methods <em>and constructors</em> inherited via implicit inheritance.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.1.k">
+ <h4 class="subsect">(k) <span class="title">Covariant return types</span><a class="img" href="s1.html#s1.3.1.k"
+ title="PermaLink to (k) Covariant return types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Given a team <code>T1</code> with two roles <code>R1</code> and <code>R2</code> where <code>R2</code> explicitly inherits from <code>R1</code>, both roles defining
+ a method <code>m</code> returning some type <code>A</code>.
+ Given also a sub-team of <code>T1</code>, <code>T2</code>, where <code>T2.R1</code> overrides <code>m</code> with a covariant return type <code>B</code>
+ (sub-type of <code>A</code>):
+
+ </p>
+ <div class="listing plain"><pre> <b>public</b> <b>team</b> <b>class</b> T1 {
+ <b>protected</b> <b>abstract</b> <b>class</b> R1 {
+ <b>abstract</b> A m();
+ }
+ <b>protected</b> <b>class</b> R2 <b>extends</b> R1 {
+ A m() { <b>return</b> <b>new</b> A(); }
+ }
+ }
+ <b>public</b> <b>team</b> <b>class</b> T2 <b>extends</b> T1 {
+ <b>protected</b> <b>class</b> R1 {
+ @Override B m() { <b>return</b> <b>new</b> B(); } <span class="error">// this declaration renders <b>class</b> T2.R2 illegal</span>
+ }
+ }</pre></div>
+ <p>
+ In this situation role <code>T2.R2</code> will be illegal unless also overriding <code>m</code> with a return type that is at least <code>B</code>.
+ Note, that the actual error occurs at the implicitly inherited method <code>T2.R2.m</code> which is not visible in the source code,
+ even <code>T2.R2</code> need not be mentioned explicitly in the source code.
+ A compiler should flag this as an imcompatibility at the team level, because a team must specialize inherited roles
+ in a consistent way.
+
+ </p>
+ </div>
+ <h5 class="listing">Example code (Teams and Roles):</h5>
+ <div class="listing example frame" id="l1.3.1-3">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>protected</b> <b>class</b> MyRole {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> String name;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>public</b> MyRole (String n) { name = n; }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <b>public</b> <b>void</b> print() { System.out.println("id="+name); }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <b>protected</b> MyRole getRole() { <b>return</b> <b>new</b> MyRole("Joe"); }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="listing example frame" id="l1.3.1-4">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">10</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MySubTeam <b>extends</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">11</td>
+ <td><pre> <b>protected</b> <b>class</b> MyRole {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">12</td>
+ <td><pre> <b>int</b> age;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">13</td>
+ <td><pre> <b>public</b> <b>void</b> setAge(<b>int</b> a) { age = a; }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">14</td>
+ <td><pre> <b>public</b> <b>void</b> print() {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">15</td>
+ <td><pre> tsuper.print();</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">16</td>
+ <td><pre> System.out.println("age="+age);</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">17</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">18</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">19</td>
+ <td><pre> <b>public</b> <b>void</b> doit() {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">20</td>
+ <td><pre> MyRole r = getRole();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">21</td>
+ <td><pre> r.setAge(27);</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">22</td>
+ <td><pre> r.print();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">23</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">24</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">25</td>
+ <td><pre>...</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">26</td>
+ <td><pre>MySubTeam myTeam = <b>new</b> MySubTeam();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">27</td>
+ <td><pre>myTeam.doit();</pre></td>
+ </tr>
+ </table>
+ </div>
+ <h5 class="listing">Program output</h5>
+ <div class="listing example frame"><pre>id=Joe
+age=27</pre></div>
+ <div class="codecomment">
+ <h5>Effects:</h5>
+ <ul>
+ <li>According to <a href="#s1.3"
+ title="§1.3 Acquisition and implicit inheritance of role classes"
+ class="sect">§1.3</a>, <code>MyTeamA</code> implements
+ <code>ITeam</code> (line 1).
+ </li>
+ <li>An implicit role inheritance is created for
+ <code>MySubTeam.MyRole</code> (<a href="#s1.3.1.c"
+ title="§1.3.1.(c) Overriding and implicit inheritance"
+ class="sect">§1.3.1.(c)</a>; line 11).<br />
+ If we visualize this special inheritance using a fictitious keyword
+ <code>overrides</code> the compiler would see a declaration:
+
+ <div class="listing plain"><pre><b>protected</b> <b>class</b> MyRole <em>overrides MyTeamA.MyRole</em> { ... }</pre></div>
+ </li>
+ <li>Invoking <code>getRole()</code> on <code>myTeam</code> (line 27, 20)
+ creates an instance of <code>MySubTeam.MyRole</code> because the
+ acquired role <code>MyTeamA.MyRole</code> is overridden by
+ <code>MySubTeam.MyRole</code>
+ following the rules of implicit inheritance (cf. <a href="#s1.3.1.e" title="§1.3.1.(e) Dynamic binding of types"
+ class="sect">§1.3.1.(e)</a>).
+
+ </li>
+ <li>Overriding of role methods and access to inherited features works as usual.
+
+ </li>
+ <li>As an example for <a href="#s1.3.1.f" title="§1.3.1.(f) tsuper" class="sect">§1.3.1.(f)</a> see the call <code>tsuper.print()</code>
+ (line 15), which selects the implementation of <code>MyTeamA.MyRole.print</code>.
+
+ </li>
+ </ul>
+ </div>
+ </div>
+ <div class="sect depth3" id="s1.3.2">
+ <h3 class="sect">§1.3.2 Regular role inheritance<a class="img" href="s1.html#s1.3.2"
+ title="PermaLink to §1.3.2 Regular role inheritance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s1.3">↑ §1.3</a></span></h3>
+ <p>In addition to implicit inheritance, roles may also inherit using
+ the standard Java keyword <code>extends</code>. These restrictions apply:
+
+ </p>
+ <div class="subsect depth4" id="s1.3.2.a">
+ <h4 class="subsect">(a) <span class="title">Super-class restrictions</span><a class="img" href="s1.html#s1.3.2.a"
+ title="PermaLink to (a) Super-class restrictions"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If the super-class of a role is again a role it must be a direct role of
+ an enclosing team
+ This rule is simply enforced by disallowing type anchors in the
+ <code>extends</code> clause
+ (see <a href="#s1.2.2.g" title="§1.2.2.(g) Legal contexts" class="sect">§1.2.2.(g)</a>).
+ As an effect, the super-class may never be more deeply nested than the sub-class.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.2.b">
+ <h4 class="subsect">(b) <span class="title">Inheriting and overriding the extends clause</span><a class="img" href="s1.html#s1.3.2.b"
+ title="PermaLink to (b) Inheriting and overriding the extends clause"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a role overrides another role by implicit inheritance, it may
+ change the inherited <code>extends</code> clause
+ (see <a href="#s1.3.1.g"
+ title="§1.3.1.(g) Implicitly inheriting super-types"
+ class="sect">§1.3.1.(g)</a> above) only if the new super-class
+ is a sub-class of the class in the overridden extends clause.
+ I.e., an implicit sub-role may <em>specialize</em> the extends clause of its
+ implicit super-role.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.2.c">
+ <h4 class="subsect">(c) <span class="title">Constructors and overridden 'extends' </span><a class="img" href="s1.html#s1.3.2.c"
+ title="PermaLink to (c) Constructors and overridden 'extends' "><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Each constructor of a role class that overrides the extends clause of its
+ implicit super-role must invoke a constructor of this newly introduced
+ explicit super-class. Thus it may not use a <code>tsuper</code> constructor
+ (see <a href="s2.html#s2.4.2"
+ title="§2.4.2 Role creation via a regular constructor"
+ class="sect">§2.4.2</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.2.d">
+ <h4 class="subsect">(d) <span class="title">Adding implemented interfaces</span><a class="img" href="s1.html#s1.3.2.d"
+ title="PermaLink to (d) Adding implemented interfaces"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p><code>implements</code> declarations are additive, i.e., an implicit
+ sub-role may add more interfaces but has to implement all interfaces of
+ its implicit super-role, too.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s1.3.2.e">
+ <h4 class="subsect">(e) <span class="title">Visibility of inherited methods</span><a class="img" href="s1.html#s1.3.2.e"
+ title="PermaLink to (e) Visibility of inherited methods"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>
+ When a role inherits non-public methods from a regular class (as its super class),
+ these methods are considered as private for the role, i.e., they can only be
+ accessed in an unqualified method call <code>m()</code> using the implicit receiver <code>this</code>.
+
+ </p>
+ </div>
+ </div>
+ </div>
+ <div class="sect depth2" id="s1.4">
+ <h2 class="sect">§1.4 Name clashes<a class="img" href="s1.html#s1.4"
+ title="PermaLink to §1.4 Name clashes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §1</a></span></h2>
+ <p>OT/J restricts Java with respect to handling of conflicting names.
+
+ </p>
+ <div class="subsect depth3" id="s1.4.a">
+ <h4 class="subsect">(a) <span class="title">Names of role classes</span><a class="img" href="s1.html#s1.4.a"
+ title="PermaLink to (a) Names of role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role class may not have the same name as a method or field of
+ its enclosing team. A role class may not shadow another class that is visible in the scope of the enclosing team.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s1.4.b">
+ <h4 class="subsect">(b) <span class="title">Names of role methods and fields</span><a class="img" href="s1.html#s1.4.b"
+ title="PermaLink to (b) Names of role methods and fields"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Along implicit inheritance, the names of methods or fields may
+ not hide, shadow or obscure any previously visible name.<br />
+ (see JLS <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#40898"
+ class="ext">§8.3</a>,
+ <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#227928"
+ class="ext">§8.4.6.2</a>,
+ <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#246026"
+ class="ext">§8.5</a>,
+ <a href="http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#78642"
+ class="ext">§9.3</a>,
+ <a href="http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#252566"
+ class="ext">§9.5</a> (hiding),
+ <a href="http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#34133"
+ class="ext">§6.3.1</a> (shadowing),
+ <a href="http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#104058"
+ class="ext">§6.3.2</a> (obscuring).
+
+ </p>
+ </div>
+ </div>
+ <div class="sect depth2" id="s1.5">
+ <h2 class="sect">§1.5 Team and role nesting<a class="img" href="s1.html#s1.5"
+ title="PermaLink to §1.5 Team and role nesting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §1</a></span></h2>
+ <p>Multi-level nesting of classes is restricted only by the following rules.
+
+ </p>
+ <h5 class="listing">Example code (Nesting):</h5>
+ <div class="listing example frame" id="l1.5">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> SuperOuter {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeam</em> {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> Runnable foo() { <b>return</b> null; }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeamSub</em> <b>extends</b> <strong>RoleAndTeam</strong> {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre> Runnable foo() { <b>throw</b> <b>new</b> RuntimeException(); }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">12</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">13</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> OuterTeam <b>extends</b> SuperOuter {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">14</td>
+ <td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeam</em> {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">15</td>
+ <td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">16</td>
+ <td><pre> Runnable foo() {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">17</td>
+ <td><pre> <b>class</b> Local {};</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">18</td>
+ <td><pre> <b>return</b> <b>new</b> Runnable() { <span class="comment">// anonymous class definition</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">19</td>
+ <td><pre> <b>public</b> <b>void</b> run() {}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">20</td>
+ <td><pre> };</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">21</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">22</td>
+ <td><pre> <span class="comment">// <span class="error">class IllegalMember {}</span></span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">23</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">24</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">25</td>
+ <td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeamSub</em> {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">26</td>
+ <td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">27</td>
+ <td><pre> Runnable foo() {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">28</td>
+ <td><pre> <em>RoleAndTeamSub.tsuper</em>.foo();</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">29</td>
+ <td><pre> <b>return</b> <em>OuterTeam.tsuper</em>.foo();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">30</td>
+ <td><pre> };</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">31</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">32</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">33</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="subsect depth3" id="s1.5.a">
+ <h4 class="subsect">(a) <span class="title">Nested teams</span><a class="img" href="s1.html#s1.5.a" title="PermaLink to (a) Nested teams"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a role class is also marked using the <code>team</code> modifier,
+ it may contain roles at the next level of nesting.
+
+ </p>
+ <div class="codecomment">
+ <ul>
+ <li>In the above example (<a href="#l1.5" class="listing">Listing 1.5</a>) class <code>RoleAndTeam</code> starting in line 14
+ is a role of <code>OuterTeam</code> and at the same time a
+ team containing a further role <code>InnerRole</code></li>
+ </ul>
+ </div>
+ <p>Such a hybrid role-and-team has all properties of both kinds of classes.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s1.5.b">
+ <h4 class="subsect">(b) <span class="title">Nested classes of roles</span><a class="img" href="s1.html#s1.5.b"
+ title="PermaLink to (b) Nested classes of roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A regular role class (ie., not marked as <code>team</code>, see above)
+ may contain local types (see <a href="http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#247766"
+ class="ext">JLS §14.3</a>
+ - in the example: class <code>Local</code>), anonymous types
+ (<a href="http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#252986"
+ class="ext">JLS §15.9.5</a>
+ - in the example: class defined in lines 18-20)
+ but no member types (<a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#246026"
+ class="ext">JLS §8.5</a>
+ - in the example: illegal class
+ <code>IllegalMember</code>).
+ <br />
+ The effect is, that nested types of a regular role cannot be
+ used outside the scope of their enclosing role.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s1.5.c">
+ <h4 class="subsect">(c) <span class="title">Prohibition of cycles</span><a class="img" href="s1.html#s1.5.c"
+ title="PermaLink to (c) Prohibition of cycles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A nested team may not extend its own enclosing team.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s1.5.d">
+ <h4 class="subsect">(d) <span class="title">Prohibition of name clashes</span><a class="img" href="s1.html#s1.5.d"
+ title="PermaLink to (d) Prohibition of name clashes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A nested team may inherit roles from multiple sources: its explicit super team
+ and any of its implicit super classes (roles) from different levels of nesting.
+ If from different sources a team inherits two or more roles of the same name
+ that are not related by implicit inheritance, this is an illegal name clash.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s1.5.e">
+ <h4 class="subsect">(e) <span class="title">Precedence among different supers</span><a class="img" href="s1.html#s1.5.e"
+ title="PermaLink to (e) Precedence among different supers"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a role inherits the same feature from several super roles (super and tsuper),
+ an implicitly inherited version always overrides any explicitly inherited feature,
+ i.e., a role with the same simple name is closer related than one with a different name.
+ </p>
+ <p>
+ Also implicit inheritance alone may produce several candidate methods inherited by a role class.
+ This is a result of team-nesting where each level of nesting may add one more tsuper role
+ if outer teams also participate in an inheritance relationship.
+ In this case a role inherited from an <em>implicit</em> super team of the enclosing team
+ is closer related than a role inherited from an <em>explicit</em> super team.
+ If necessary this rule is applied inside out until a nesting level is found where indeed
+ explicit team inheritance is involved.<br />
+ So when comparing classes by their fully qualified names
+ the longest common suffix will determine the closest relationship.
+ E.g., <code>SuperOuter.RoleAndTeamSub.InnerRole</code>
+ is the closest ancestor of <code>SubOuter.RoleAndTeamSub.InnerRole</code>
+ because both share the name suffix <code>RoleAndTeamSub.InnerRole</code>.
+
+ </p>
+ <div class="codecomment">
+ <table>
+ <colgroup span="1">
+ <col align="left" span="1" />
+ <col align="center" span="1" />
+ </colgroup>
+ <tr>
+ <td valign="top" rowspan="1" colspan="1">
+ <p>In the above example (<a href="#l1.5" class="listing">Listing 1.5</a>) role <code class="small">OuterTeam.RoleAndTeamSub.InnerRole</code>
+ has two direct tsuper roles:
+ <code class="small">OuterTeam.RoleAndTeam.InnerRole</code> and <code class="small">SuperOuter.RoleAndTeamSub.InnerRole</code>.
+ Without the method <code>foo</code> defined in lines 27-30, the enclosing class <code class="small">OuterTeam.RoleAndTeamSub.InnerRole</code>
+ would inherit the method <code>foo</code> defined in <code>SuperOuter.RoleAndTeamSub.InnerRole</code> (line 9),
+ because the common name suffix <code>RoleAndTeamSub.InnerRole</code>
+ creates a stronger relationship making that class the closest ancestor.
+ </p>
+ </td>
+ <td rowspan="1" colspan="1"><img src="../images/team_nesting_hor.png" alt="Example diagram team nesting" /></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <div class="subsect depth3" id="s1.5.f">
+ <h4 class="subsect">(f) <span class="title">Qualified tsuper</span><a class="img" href="s1.html#s1.5.f"
+ title="PermaLink to (f) Qualified tsuper"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role in a nested team may qualify the keyword <code>tsuper</code> (see <a href="#s1.3.1.f" title="§1.3.1.(f) tsuper" class="sect">§1.3.1.(f)</a> above) by a type name
+ in order to select among different implicit super classes.
+ A term <code>OuterTeam.tsuper</code> evaluates to a corresponding implicit super class
+ within the context of the explicit super-class (here: <code>SuperOuter</code>) of the enclosing team "<code>OuterTeam</code>".
+ A method call <code>OuterTeam.tsuper.m()</code>
+ evaluates to the method version within <code>SuperOuter</code> that best corresponds to the current method containing the tsuper-call.
+
+ </p>
+ <div class="codecomment">
+ <ul>
+ <li>In the above example (<a href="#l1.5" class="listing">Listing 1.5</a>) line 28 selects the method version
+ within the superclass of <code>RoleAndTeamSub</code> (i.e., within <code>RoleAndTeam</code>),
+ resolving to <code>OuterTeam.RoleAndTeam.InnerRole.foo()</code>.
+ </li>
+ <li>Line 29 selects a corresponding method from the context of <code>SuperOuter</code> resolving to <code>SuperOuter.RoleAndTeamSub.InnerRole.foo()</code>
+ which has the same semantics as an unqualified <code>tsuper</code> call would have.
+
+ </li>
+ </ul>
+ </div>
+ </div>
+ </div>
+ <div class="aux" id="aux1.1">
+ <h4 class="aux">Language implementation:<span class="toplink"><a href="#s1">↑ §1</a></span></h4>
+ <p>Role acquisition and implicit inheritance can be implemented in at least two ways.
+
+ </p>
+ <p><strong>Virtual classes:</strong> Each role class is an overridable feature of
+ its enclosing team. Role classes are resolved by dynamic binding
+ with respect to the enclosing team instance. This implementation
+ requires multiple-inheritance in order to also allow regular
+ inheritance between roles of the same team. <code>super</code>
+ and <code>tsuper</code> select parent versions of a method along
+ the two dimensions of inheritance.
+
+ </p>
+ <p><strong>Copy inheritance:</strong> Role acquisition from a super-team has the effect
+ of copying a role definition <code>T.R</code> yielding a new
+ role <code>Tsub.R</code>. All role applications <code>Rx</code>
+ in the role copy refer to <code>Tsub.Rx</code>. Implicit role
+ inheritance extends a role copy in-place. Only the <code>tsuper</code>
+ construct allows to access the previous version of a method
+ (i.e. before in-place overriding).
+
+ </p>
+ </div>
+ <div class="aux" id="aux1.2">
+ <h4 class="aux">References:<span class="toplink"><a href="#s1">↑ §1</a></span></h4>
+ <p id="fn1-virtual-classes">[1] Ole Lehrmann Madsen and Birger Møller-Pedersen. <em>Virtual classes: A powerful mechanism in object-oriented programming</em>. In Proceedings OOPSLA 89, ACM SIGPLAN Notices, volume 24, 10, pages 397-406, October 1989.
+
+ </p>
+ <p id="fn2-family-polymorphism">[2] Erik Ernst. <em>Family Polymorphism.</em> In Proceedings ECOOP 2001, LNCS 2072, pages 303-326, Springer, 2001.
+
+ </p>
+ </div>
+ </div>
+ <table class="nav">
+ <tr>
+ <td class="back"><a href="s0.html" rel="prev"><< §0 About this Document</a></td>
+ <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
+ <td class="next"><a href="s2.html" rel="next">§2 Role Binding >></a></td>
+ </tr>
+ </table>
+ </div>
+ <div id="footer">
+ <hr /><a class="w3c img" href="http://jigsaw.w3.org/css-validator/check/referer"
+ shape="rect"><img src="../images/valid-css2-blue.png" alt="Valid CSS!" height="31" width="88" /></a><a class="w3c img" href="http://validator.w3.org/check?uri=referer" shape="rect"><img src="../images/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31"
+ width="88" /></a><address>© Stephan Herrmann, Christine Hundt, Marco Mosconi</address>
+ OT/J version 1.3 — last modified: 2011-05-15
+ </div>
+ </body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s2.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s2.html
new file mode 100644
index 0000000..344fc2b
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s2.html
@@ -0,0 +1,2150 @@
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+ <link rel="stylesheet" type="text/css" href="../css/ot.css" />
+ <link rel="stylesheet" type="text/css" href="../css/otjld.css" />
+ <title>OT/J Language Definition v1.3</title>
+ </head>
+ <body class="otdt">
+ <div id="content">
+ <table class="nav">
+ <tr>
+ <td class="back"><a id="top"></a><a href="s1.html" rel="prev"><< §1 Teams and Roles</a></td>
+ <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
+ <td class="next"><a href="s3.html" rel="next">§3 Callout Binding >></a></td>
+ </tr>
+ </table>
+ <div class="chapter" id="s2">
+ <div class="headl">
+ <div class="headr">
+ <h1>§2 Role Binding</h1>
+ </div>
+ </div>
+ <div id="toc-box">
+ <ul class="toc-box">
+ <li><a href="s2.html">§2 Role Binding</a></li>
+ <li><a href="#s2.1">§2.1 playedBy relation</a></li>
+ <li><a href="#s2.2">§2.2 Lowering</a></li>
+ <li><a href="#s2.3">§2.3 Lifting</a></li>
+ <li><a href="#s2.4">§2.4 Explicit role creation</a></li>
+ <li><a href="#s2.5">§2.5 Abstract Roles</a></li>
+ <li><a href="#s2.6">§2.6 Explicit base references</a></li>
+ <li><a href="#s2.7">§2.7 Advanced structures</a></li>
+ </ul>
+ </div>
+ <div class="intro">
+ <h3>Roles and base classes</h3>
+ <div class="line"></div>
+ <div class="term">playedBy relation</div>
+ <div class="termdesc">A role can be bound to a class outside the team by a <code>playedBy</code>
+ relation, which declares that each role instances is associated to a
+ base instances.
+ </div>
+ <div class="line"></div>
+ <div class="term">Base class</div>
+ <div class="termdesc">The class to which a role is bound (using <code>playedBy</code>) is called
+ its <strong>base class</strong>. Role instances may inherit and override
+ features from their base instance, which is declared using <strong>callout</strong>
+ (<a href="s3.html" title="§3 Callout Binding" class="sect">§3</a>)
+ and <strong>callin</strong> (<a href="s4.html" title="§4 Callin Binding" class="sect">§4</a>) method bindings.
+ </div>
+ <div class="line"></div>
+ <div class="term">Bound role</div>
+ <div class="termdesc">Each role class that declares a <code>playedBy</code> relation
+ is called a <strong>bound role</strong>. The term bound role may also be
+ used for the instances of such a class.
+ </div>
+ <div class="line"></div>
+ <div class="term">Lifting / lowering</div>
+ <div class="termdesc">Translations between a role and its base are called
+ <strong>lifting</strong> (base to role) (<a href="#s2.3" title="§2.3 Lifting" class="sect">§2.3</a>)
+ and <strong>lowering</strong> (role to base) (<a href="#s2.2" title="§2.2 Lowering" class="sect">§2.2</a>).
+ </div>
+ <div class="line"></div>
+ <div class="term">Translation polymorphism</div>
+ <div class="termdesc">Conformance between a role and a base is governed by <strong>translation polymorphism</strong>,
+ which refers to a substitutability that is achieved using either lifting or lowering.
+ </div>
+ <div class="line"></div>
+ <div class="term">Declared lifting</div>
+ <div class="termdesc">Generally, lifting happens implicitly at data flows between
+ a role object and its base. Team level methods provide additional
+ data flows, where lifting may be declared explicitly.
+ </div>
+ <div class="line"></div>
+ </div>
+ <div class="sect depth2" id="s2.1">
+ <h2 class="sect">§2.1 playedBy relation<a class="img" href="s2.html#s2.1"
+ title="PermaLink to §2.1 playedBy relation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §2</a></span></h2>
+ <div class="syntaxlink"><a href="sA.html#sA.1.1" title="§A.1.1 ClassDeclaration"
+ class="syntax">→ Syntax §A.1.1</a></div>
+ <div class="subsect depth3" id="s2.1.a">
+ <h4 class="subsect">(a) <span class="title">Role-base binding</span><a class="img" href="s2.html#s2.1.a"
+ title="PermaLink to (a) Role-base binding"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Roles are bound to a base class by the <code>playedBy</code> keyword.
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> MyRole <em><b>playedBy</b> MyBase</em> {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> ...</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <div class="subsect depth3" id="s2.1.b">
+ <h4 class="subsect">(b) <span class="title">Inheritance</span><a class="img" href="s2.html#s2.1.b" title="PermaLink to (b) Inheritance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The <code>playedBy</code> relation is inherited along
+ explicit and implicit (<a href="s1.html#s1.3.1.c"
+ title="§1.3.1.(c) Overriding and implicit inheritance"
+ class="sect">§1.3.1.(c)</a>)
+ role inheritance.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.1.c">
+ <h4 class="subsect">(c) <span class="title">Covariant refinement</span><a class="img" href="s2.html#s2.1.c"
+ title="PermaLink to (c) Covariant refinement"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>An <em>explicit</em> sub-role (sub-class using <code>extends</code>)
+ can refine the <code>playedBy</code> relation to a more
+ specific base class (this is the basis for
+ <a href="#s2.3.3" title="§2.3.3 Smart lifting" class="sect">smart lifting (§2.3.3)</a>).<br />
+ If a role class inherits several <code>playedBy</code> relations from
+ its super-class and its super-interfaces, there must be a most specific
+ base-class among these relations, which is conform to all other base-classes.
+ This most specific base-class is the base-class of the current role.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.1.d">
+ <h4 class="subsect">(d) <span class="title">No-variance</span><a class="img" href="s2.html#s2.1.d" title="PermaLink to (d) No-variance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>An <em>implicit</em> sub-role (according to <a href="s1.html#s1.3.1.c"
+ title="§1.3.1.(c) Overriding and implicit inheritance"
+ class="sect">§1.3.1.(c)</a>)
+ may only add a <code>playedBy</code> relation but never change an existing one.<br />
+ Note however, that implicit inheritance may implicitly specialize an existing <code>playedBy</code>
+ relation (this advanced situation is illustrated in <a href="#s2.7.d" title="§2.7.(d) Implicit playedBy specialization"
+ class="sect">§2.7.(d)</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.1.e">
+ <h4 class="subsect">(e) <span class="title">Use of playedBy bindings</span><a class="img" href="s2.html#s2.1.e"
+ title="PermaLink to (e) Use of playedBy bindings"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The <code>playedBy</code> relation by itself has no effect
+ on the behavior of role and base objects.
+ It is, however, the precondition for translation polymorphism
+ (lowering: <a href="#s2.2" title="§2.2 Lowering" class="sect">§2.2</a> and lifting: <a href="#s2.3" title="§2.3 Lifting" class="sect">§2.3</a>)
+ and for method bindings (callout: <a href="s3.html" title="§3 Callout Binding" class="sect">§3</a> and callin: <a href="s4.html" title="§4 Callin Binding" class="sect">§4</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.1.f">
+ <h4 class="subsect">(f) <span class="title">Effect on garbage collection</span><a class="img" href="s2.html#s2.1.f"
+ title="PermaLink to (f) Effect on garbage collection"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role and its base object form one conceptual entity. The garbage collector will see a role
+ and its base object as linked in a bidirectional manner. As a result, a role cannot be
+ garbage collected if its base is still reachable and vice versa.
+ <br />
+ Internally a team manages its roles and corresponding bases using weak references.
+ When using one of the <code>getAllRoles(..)</code>
+ methods (see <a href="s6.html#s6.1.a"
+ title="§6.1.(a) Interface to the role registry"
+ class="sect">§6.1.(a)</a>),
+ the result may be non-deterministic because these internal structures
+ may hold weak references to objects that will be collected by the next run of the
+ garbage collector. We advise clients of <code>getAllRoles(..)</code> to call
+ <code>System.gc()</code> prior to calling <code>getAllRoles(..)</code> in order
+ to ensure deterministic results.
+
+ </p>
+ </div>
+ <div class="sect depth3" id="s2.1.1">
+ <h3 class="sect">§2.1.1 Binding interfaces<a class="img" href="s2.html#s2.1.1"
+ title="PermaLink to §2.1.1 Binding interfaces"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.1">↑ §2.1</a></span></h3>
+ <p>Role base bindings may involve classes and/or interfaces.
+ An interface defined as a member of a team is a role interface and may therefore
+ have a <code>playedBy</code> clause. Also the type mentioned after the
+ <code>playedBy</code> keyword may be an interface.
+
+ </p>
+ <div class="note">
+ <h5>Implementation limitation:</h5>
+ The language implementation as of OTDT version 2.0
+ imposes one particular restriction when binding a role to a base interface:
+ A role binding to a base interface may not contain any callin bindings (<a href="s4.html" title="§4 Callin Binding" class="sect">§4</a>).
+
+ </div>
+ </div>
+ <div class="sect depth3" id="s2.1.2">
+ <h3 class="sect">§2.1.2 Legal base classes<a class="img" href="s2.html#s2.1.2"
+ title="PermaLink to §2.1.2 Legal base classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.1">↑ §2.1</a></span></h3>
+ <p>Generally, the base class mentioned after <code>playedBy</code> must be
+ visible in the enclosing scope (see <a href="#s2.1.2.c" title="§2.1.2.(c) Base class decapsulation"
+ class="sect">below (§2.1.2.(c))</a> for an exception).
+ Normally, this scope is defined just by the imports of the enclosing team.
+ For role files (<a href="s1.html#s1.2.5.b" title="§1.2.5.(b) Role files"
+ class="sect">§1.2.5.(b)</a>)
+ also additional imports in the role file are considered.
+ <br /><a href="#s2.1.2.d" title="§2.1.2.(d) Base imports" class="sect">§2.1.2.(d)</a> below defines how imports can be constrained so that certain types
+ can be used as base types, only.
+
+ </p>
+ <div class="subsect depth4" id="s2.1.2.a">
+ <h4 class="subsect">(a) <span class="title">No role of the same team</span><a class="img" href="s2.html#s2.1.2.a"
+ title="PermaLink to (a) No role of the same team"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The base class of any role class must not be a role of the same team.
+ <br />
+ It is also not allowed to declare a role class of the same name
+ as a base class bound to this or another role of the enclosing team,
+ if that base class is given with its simple name and resolved using a regular import.
+ Put differently, a base class mentioned after <code>playedBy</code>
+ may not be <em>shadowed</em> by any role class of the enclosing team.
+ <br /><em>Base imports</em> as defined below (<a href="#s2.1.2.d" title="§2.1.2.(d) Base imports" class="sect">§2.1.2.(d)</a>) relax this rule by
+ allowing to import a class as a base class only. In that case no shadowing occurs since the scopes for
+ base classes and roles are disjoint.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.1.2.b">
+ <h4 class="subsect">(b) <span class="title">Cycles</span><a class="img" href="s2.html#s2.1.2.b" title="PermaLink to (b) Cycles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The base class mentioned after <code>playedBy</code> should normally not be
+ an enclosing type (at any depth) of the role class being defined.
+ <br />
+ This rule discourages the creation of cycles where the base instance of
+ a given role <code>R</code> contains roles of the same type <code>R</code>.
+ <br />
+ More generally this concerns any sequence of classes <code>C<sub>1</sub>, C<sub>2</sub>, .. C<sub>n</sub></code>
+ were each <code>C<sub>i+1</sub></code> is either a member or the base class of
+ <code>C<sub>i</sub></code> and <code>C<sub>n</sub> = C<sub>1</sub></code>.
+ <br />
+ Such structures may be difficult to understand and have certain restrictions regarding
+ callout (<a href="s3.html#s3.1.a"
+ title="§3.1.(a) Prerequisite: Class binding"
+ class="sect">§3.1.(a)</a>) and base constructor calls (<a href="#s2.4.2"
+ title="§2.4.2 Role creation via a regular constructor"
+ class="sect">§2.4.2</a>).
+ It is furthermore recommended to equip all roles that are played by an enclosing class with a guard predicate (<a href="s5.html#s5.4" title="§5.4 Guard predicates" class="sect">§5.4</a>) like this:
+
+ </p>
+ <div class="listing plain"><pre><em>base</em><em> when</em> (MyTeam.this == <em>base</em>)</pre></div>
+ <p>
+ This will avoid that the role adapts other instances of the enclosing class which are not the enclosing instance.
+
+ </p>
+ <p>
+ It is prohibited to bind a role class to its own inner class.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.1.2.c">
+ <h4 class="subsect">(c) <span class="title">Base class decapsulation</span><a class="img" href="s2.html#s2.1.2.c"
+ title="PermaLink to (c) Base class decapsulation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a base class referenced after <code>playedBy</code> exists but is not visible under normal visibility rules of Java,
+ this restriction may be overridden. This concept is called <strong>decapsulation</strong>, i.e., the opposite of encapsulation
+ (see also <a href="s3.html#s3.4" title="§3.4 Overriding access restrictions"
+ class="sect">§3.4</a>). A compiler should signal any occurrence of base class decapsulation. If a compiler supports to
+ configure warnings this may be used to let the user choose to (a) ignore base class decapsulation, (b) treat it as a warning
+ or even
+ (c) treat it as an error.
+
+ </p>
+ <p>
+ Binding to a <code>final</code> base class is also considered as decapsulation, since a <code>playedBy</code> relationship has
+ powers similar to an <code>extends</code> relationship, which is prohibited by marking a class as <code>final</code>.
+
+ </p>
+ <p>
+ Decapsulation is not allowed if the base class is a confined role (see <a href="s7.html#s7.2" title="§7.2 Confined roles" class="sect">§7.2</a>).
+
+ </p>
+ <p>
+ Within the current role a decapsulated base class can be mentioned in the right-hand-side of any method binding
+ (<a href="s3.html" title="§3 Callout Binding" class="sect">callout (§3)</a> or <a href="s4.html" title="§4 Callin Binding" class="sect">callin (§4)</a>). Also arguments in these positions are allowed to mention the decapsulated base class:
+
+ </p>
+ <ul>
+ <li>the first argument of one of the role's constructors (see <a href="#s2.4.1"
+ title="§2.4.1 Role creation via a lifting constructor"
+ class="sect">lifting constructor (§2.4.1)</a>).
+ </li>
+ <li>the base side of an argument with declared lifting (see <a href="#s2.3.2" title="§2.3.2 Declared lifting" class="sect">declared lifting (§2.3.2)</a>).
+ </li>
+ </ul>
+ </div>
+ <div class="subsect depth4" id="s2.1.2.d">
+ <h4 class="subsect">(d) <span class="title">Base imports</span><a class="img" href="s2.html#s2.1.2.d"
+ title="PermaLink to (d) Base imports"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If the main type in a file denotes a team, the modifier <code>base</code> can be applied to an import in order to specify that this type
+ should be imported for application as a base type only. Example:
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><em><b>import</b> base</em> some.pack.MyBase;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeam {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <span class="comment">// simple name resolves to imported class:</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>protected</b> <b>class</b> MyRole <em><b>playedBy</b> MyBase</em> { } </pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <span class="error"><em>MyBase</em> illegalDeclaration;</span> <span class="comment">// base import does not apply for this position</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>Types imported by a base import can only be used in the same positions where also base class decapsulation (<a href="#s2.1.2.c" title="§2.1.2.(c) Base class decapsulation"
+ class="sect">§2.1.2.(c)</a>)
+ is applicable.<br />
+ It is recommended that a type mentioned after the keyword <code>playedBy</code> is always imported with the <code>base</code> modifier, otherwise the compiler
+ will give a warning.<br />
+ Base imports create a scope that is disjoint from the normal scope. Thus, names that are imported as base will never clash
+ with normally visible names
+ (in contrast to <a href="s1.html#s1.4" title="§1.4 Name clashes" class="sect">§1.4</a>). More specifically, it is not a problem to use a base class's name also for its role if a base import is used.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.1.2.e">
+ <h4 class="subsect">(e) <span class="title">No free type parameters</span><a class="img" href="s2.html#s2.1.2.e"
+ title="PermaLink to (e) No free type parameters"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>
+ Neither the role class nor the base class in a playedBy binding must have any <em>free type parameters</em>.
+ If both classes are specified with a type parameter of the same name, both parameters are identified
+ and are not considered as <em>free</em>.
+
+ </p>
+ <p>
+ From this follows that a role class cannot have more type parameters than its base.
+ Conversely, only one situation exists where a base class can have more type parameters than a role class
+ bound to it: if the role class has no type parameters a generic base class can be bound using
+ the base class's raw type, i.e., without specifying type arguments.
+
+ </p>
+ <div class="note">
+ <h5>Note:</h5>
+ The information from the <code>playedBy</code> declaration is used at run-time
+ to associate role instances to base instances.
+ Specifying a base class with free type parameters would imply that only such base instances
+ are decorated by a role whose type is conform to the specified parameterized class.
+ However, type arguments are not available at run-time, thus the run-time environment
+ is not able to decide which base instances should have a role and which should not.
+ This is due to the design of generics in Java which are realized by erasure.
+
+ </div>
+ <p>The following example shows how generics can be used in various positions. Note, that some of the concepts used in the example
+ will be explained in later sections.
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>class</b> ValueTrafo<em><T></em> {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <em>T</em> transform(<em>T</em> val) <b>throws</b> Exception { /* ... */ }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> TransformTeam {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <b>protected</b> <b>class</b> SafeTrafo<em><U></em> <b>playedBy</b> ValueTrafo<em><U></em> {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> <em>U</em> transform(<em>U</em> v) <b>-></b> <em>U</em> transform(<em>U</em> val); </pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <b>protected</b> <em>U</em> safeTransform(<em>U</em> v) {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> <b>try</b> {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre> <b>return</b> transform(v);</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre> } <b>catch</b> (Exception e) {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre> <b>return</b> v;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">12</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">13</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">14</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">15</td>
+ <td><pre> <em><V> V</em> perform(ValueTrafo<em><V></em> <b>as</b> SafeTrafo<em><V></em> trafo, <em>V</em> value) {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">16</td>
+ <td><pre> <b>return</b> trafo.safeTransform(value);</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">17</td>
+ <td><pre> } </pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">18</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">19</td>
+ <td><pre>...</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">20</td>
+ <td><pre>ValueTrafo<em><String></em> trafo = <b>new</b> ValueTrafo<em><String></em>();</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">21</td>
+ <td><pre>TransformTeam safeTrafo = <b>new</b> TransformTeam();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">22</td>
+ <td><pre>String s = safeTrafo.perform(trafo, "Testing");</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">23</td>
+ <td><pre></pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="codecomment">
+ <h5>Explanation</h5>
+ <ul>
+ <li>Line 5 shows a role with type parameter <code>U</code> where the type parameter is identified with the
+ corresponding type parameter of the role's base class (which is originally declared as <code>T</code> in line 1.
+ </li>
+ <li>Line 6 shows a callout binding (<a href="s3.html" title="§3 Callout Binding" class="sect">§3</a>) which mappes a base method to a corresponding role method
+ while maintaining the flexible typing.
+ </li>
+ <li>The regular method in lines 7-13 just passes values of type <code>U</code> around.
+ </li>
+ <li>The generic method in line 15 ff. uses declared lifting (<a href="#s2.3.2" title="§2.3.2 Declared lifting" class="sect">§2.3.2</a>) to obtain a role for a given base object.
+ The method has no knowledge about the concrete type arguments of either role nor base, but works under the guarantee
+ that both type arguments will be the same for any single invocation.
+ </li>
+ <li>Lines 20 ff. finally create instances of base and team and invoke the behavior thereby instantiating type parameters to <code>String</code>.
+ </li>
+ </ul>
+ </div>
+ </div>
+ </div>
+ </div>
+ <div class="sect depth2" id="s2.2">
+ <h2 class="sect">§2.2 Lowering<a class="img" href="s2.html#s2.2"
+ title="PermaLink to §2.2 Lowering"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §2</a></span></h2>
+ <p>Each instance of a bound role class internally stores a reference to its
+ base object. The reference is guaranteed to exist for each bound role
+ instance, and cannot be changed during its lifetime.
+
+ </p>
+ <div class="subsect depth3" id="s2.2.a">
+ <h4 class="subsect">(a) <span class="title">Definition of lowering</span><a class="img" href="s2.html#s2.2.a"
+ title="PermaLink to (a) Definition of lowering"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Retrieving the base object from a role object is called <strong>lowering</strong>.
+ No other means exists for accessing the base reference.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.2.b">
+ <h4 class="subsect">(b) <span class="title">Places of lowering</span><a class="img" href="s2.html#s2.2.b"
+ title="PermaLink to (b) Places of lowering"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The lowering translation is not meant to be invoked
+ by client code, but <strong>implicit translations</strong> are inserted by
+ the compiler at all places where a role type is provided while the
+ corresponding base type (or a super type) was expected.<br />
+ In other words: lowering translations are inserted by the compiler at
+ all places in a program which would otherwise not be type correct
+ and which using lowering are statically type correct.
+ This may concern:
+
+ </p>
+ <ul>
+ <li>the right hand side of an assignment wrt. the static type of the left hand side,</li>
+ <li>the argument values of a method or constructor call wrt. the static type of the corresponding formal parameter,</li>
+ <li>the return value of a method compared to the declared return type of the method.</li>
+ <li>a role parameter in a callout binding (<a href="s3.html#s3.3.d" title="§3.3.(d) Typing rules" class="sect">§3.3.(d)</a>)
+ </li>
+ <li>or the return value in a callin binding (<a href="s4.html#s4.5.d" title="§4.5.(d) Typing rules" class="sect">§4.5.(d)</a>)
+ </li>
+ </ul>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> <em>MyRole <b>playedBy</b> MyBase</em> { ... }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>void</b> useMyBase(<em>MyBase</em> myb) {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <em>MyRole</em> returnMyRole() {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <b>public</b> <b>void</b> doSomething() {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> <em>MyRole r</em> = <b>new</b> MyRole(<b>new</b> MyBase());</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <em>MyBase b</em> = <em>r</em>;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> useMyBase(<em>r</em>);</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre> <em>MyBase b2</em> = returnMyRole();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="codecomment">
+ <h5>Effects:</h5>
+ <p>An instance of type <code>MyRole</code> is lowered to type <code>MyBase</code> when
+ </p>
+ <ul>
+ <li>assigning it to <code>b</code> (line 7)
+ </li>
+ <li>passing it as argument to a method with formal parameter of type <code>MyBase</code> (line 8)
+ </li>
+ <li>assigning the return value to a variable of type <code>MyBase</code> (line 9)
+ </li>
+ </ul>
+ <p><em>Note</em>: The constructor call in line 6 uses the <em>lifting constructor</em> as defined in <a href="#s2.4.1"
+ title="§2.4.1 Role creation via a lifting constructor"
+ class="sect">§2.4.1</a></p>
+ </div>
+ <p>Lowering translations are <span class="underline">not</span> inserted for
+
+ </p>
+ <ul>
+ <li>reference comparison (using <code>==</code> or <code>!=</code>)
+ </li>
+ <li><code>instanceof</code> checks
+ </li>
+ <li>cast expressions</li>
+ <li>return values in callout bindings <a href="s3.html#s3.3.d" title="§3.3.(d) Typing rules" class="sect">§3.3.(d)</a>)
+ </li>
+ <li>parameters in callin bindings (<a href="s4.html#s4.5.d" title="§4.5.(d) Typing rules" class="sect">§4.5.(d)</a>)
+ </li>
+ </ul>
+ <p>For cases where lowering shall be <em>forced</em> see <a href="#s2.2.d" title="§2.2.(d) Explicit lowering" class="sect">§2.2.(d)</a> below.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.2.c">
+ <h4 class="subsect">(c) <span class="title">Typing</span><a class="img" href="s2.html#s2.2.c" title="PermaLink to (c) Typing"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The static type of an implicit lowering translation is the base class
+ declared using <code>playedBy</code> in the respective role class.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.2.d">
+ <h4 class="subsect">(d) <span class="title">Explicit lowering</span><a class="img" href="s2.html#s2.2.d"
+ title="PermaLink to (d) Explicit lowering"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a base type is also the super type of its role,
+ which frequently happens, if a base reference is known only by
+ the type <code>Object</code>, lowering cannot be deduced automatically,
+ since a type could be interpreted both as a role type and a base type.
+ These cases may need <strong>explicit lowering</strong>.
+ For this purpose the role class must declare to implement the interface
+ <strong><code>ILowerable</code></strong> (from <code>org.objectteams.ITeam</code>).
+ This will cause the compiler to generate a method
+ </p>
+ <div class="listing plain"><pre><b>public</b> Object lower()</pre></div>
+ <p>for the given role class. Client code may use this method to
+ explicitly request the base object of a given role object.
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> MyRole <em><b>implements</b> ILowerable</em> <b>playedBy</b> MyBase { ... }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>public</b> <b>void</b> doSomething() {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> MyRole r = <b>new</b> MyRole(<b>new</b> MyBase());</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> Object oMyRole = r;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> Object oMyBase = r.<em>lower()</em>;</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <div class="subsect depth3" id="s2.2.e">
+ <h4 class="subsect">(e) <span class="title">Lowering of arrays</span><a class="img" href="s2.html#s2.2.e"
+ title="PermaLink to (e) Lowering of arrays"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Lowering also works for arrays of role objects.
+ In order to lower an array of role objects,
+ a new array is created and filled with base objects, one for each
+ role object in the original array. The array may have any number
+ of dimensions at any shape. The lowered array will have exactly the
+ same shape.<br />
+ Note, that each lowering translation will create a new array.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.2.f">
+ <h4 class="subsect">(f) <span class="title">Ambiguous lowering</span><a class="img" href="s2.html#s2.2.f"
+ title="PermaLink to (f) Ambiguous lowering"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>When assigning a value of a bound role type to a variable or argument of type <code>java.lang.Object</code>
+ this situation is considered as ambiguous lowering because the assignment could apply either (a) a direct upcast to <code>Object</code>
+ or (b) lowering and then upcasting.
+ In such situations the compiler will <em>not</em> insert a lowering translation, but a configurable warning will be issued.
+
+ </p>
+ </div>
+ </div>
+ <div class="sect depth2" id="s2.3">
+ <h2 class="sect">§2.3 Lifting<a class="img" href="s2.html#s2.3" title="PermaLink to §2.3 Lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §2</a></span></h2>
+ <p>Lifting is the reverse translation of lowering. However, lifting is
+ a bit more demanding, since a given base object may have zero to
+ many role objects bound to it. Therefor, the lifting translation
+ requires more context information and may require to create role
+ objects on demand.
+
+ </p>
+ <div class="subsect depth3" id="s2.3.a">
+ <h4 class="subsect">(a) <span class="title">Definition of lifting</span><a class="img" href="s2.html#s2.3.a"
+ title="PermaLink to (a) Definition of lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Retrieving a role for a given base object is called <strong>lifting</strong>.
+ Lifting is guaranteed to yield the same role object for subsequent
+ calls regarding the same base object, the same team instance and
+ the same role class (see <a href="#s2.3.4" title="§2.3.4 Binding ambiguities" class="sect">§2.3.4</a>
+ for cases of ambiguity that are signaled by compiler warnings
+ and possibly runtime exceptions).
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.3.b">
+ <h4 class="subsect">(b) <span class="title">Places of lifting</span><a class="img" href="s2.html#s2.3.b"
+ title="PermaLink to (b) Places of lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The lifting translation is not meant to be invoked
+ by client code, but translations are inserted by the compiler
+ at the following locations:
+
+ </p>
+ <ul>
+ <li><a href="s3.html#s3.3.c" title="§3.3.(c) Result translation"
+ class="sect">Callout bindings (§3.3.(c))</a> (result)
+ </li>
+ <li><a href="s4.html#s4.5.a" title="§4.5.(a) Call target translation"
+ class="sect">Callin bindings (§4.5.(a))</a> (call target and parameters)
+ </li>
+ <li><a href="#s2.3.2" title="§2.3.2 Declared lifting" class="sect">Declared lifting (§2.3.2)</a></li>
+ </ul>
+ </div>
+ <div class="subsect depth3" id="s2.3.c">
+ <h4 class="subsect">(c) <span class="title">Typing</span><a class="img" href="s2.html#s2.3.c" title="PermaLink to (c) Typing"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A lifting translation statically expects a specific role class.
+ This expected role class must have a <code>playedBy</code> clause
+ (either directly, or inherited (explicitly or implicitly)
+ from a super role), to which the given base type is conform.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.3.d">
+ <h4 class="subsect">(d) <span class="title">Lifting of arrays</span><a class="img" href="s2.html#s2.3.d"
+ title="PermaLink to (d) Lifting of arrays"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Lifting also works for arrays of role objects.
+ For lifting an array of base objects
+ a new array is created and filled with role objects, one for each
+ base object in the original array. In contrast to the role objects
+ themselves, lifted arrays are never reused for subsequent lifting
+ invocations.
+
+ </p>
+ </div>
+ <p id="s2.3.transpol">The term <strong>translation polymorphism</strong>
+ describes the fact that at certain points values can be passed which are not
+ conform to the respective declared type considering only regular
+ inheritance (<code>extends</code>). With translation polymorphism
+ it suffices that a value can be translated using lifting or lowering.
+
+ </p>
+ <div class="sect depth3" id="s2.3.1">
+ <h3 class="sect">§2.3.1 Implicit role creation<a class="img" href="s2.html#s2.3.1"
+ title="PermaLink to §2.3.1 Implicit role creation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.3">↑ §2.3</a></span></h3>
+ <p>Lifting tries to reuse existing role objects so that role state persists across
+ lifting and lowering. If no suitable role instance is found during lifting,
+ a new role is created.
+
+ </p>
+ <div class="subsect depth4" id="s2.3.1.a">
+ <h4 class="subsect">(a) <span class="title">Reuse of existing role objects</span><a class="img" href="s2.html#s2.3.1.a"
+ title="PermaLink to (a) Reuse of existing role objects"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A role object is considered suitable for reuse during lifting, if
+ these three items are identical:
+
+ </p>
+ <ol>
+ <li>the given base object</li>
+ <li>the given team object</li>
+ <li>the statically required role type</li>
+ </ol>
+ <p>For the relation between the statically required role type and
+ the actual type of the role object see <a href="#s2.3.3" title="§2.3.3 Smart lifting" class="sect">"smart lifting" (§2.3.3)</a>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.1.b">
+ <h4 class="subsect">(b) <span class="title">Default lifting constructor</span><a class="img" href="s2.html#s2.3.1.b"
+ title="PermaLink to (b) Default lifting constructor"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Lifting uses a default constructor which takes exactly one argument of the type
+ of the declared base class (after <code>playedBy</code>).
+ By default the compiler generates such a constructor for each bound role.
+ On the other hand, default constructors that take no arguments
+ (as in <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#16823"
+ class="ext">JLS §8.8.7</a>) are never generated for bound roles.
+ <br />
+ The super-constructor to be invoked by a default lifting constructor
+ depends on whether the role's super class is a bound role or not.
+
+ </p>
+ <ul>
+ <li>If the super-class is a bound role, the default lifting constructor will invoke the default lifting constructor of the super-class.</li>
+ <li>If the super-class is not a bound role, the default lifting constructor will invoke the normal argumentless default constructor
+ of the super-class.
+ </li>
+ </ul>
+ </div>
+ <div class="subsect depth4" id="s2.3.1.c">
+ <h4 class="subsect">(c) <span class="title">Custom lifting constructor</span><a class="img" href="s2.html#s2.3.1.c"
+ title="PermaLink to (c) Custom lifting constructor"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a role class declares a custom constructor with the same signature
+ as the default lifting constructor, this constructor is used during lifting.
+ This custom constructor may pre-assume that the role has been setup
+ properly regarding its base-link and registered in the team's internal map of roles.
+ <br />
+ If a bound role has an unbound super-class without an argumentless
+ constructor, providing a custom lifting constructor is obligatory,
+ because no legal default lifting constructor can be generated.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.1.d">
+ <h4 class="subsect">(d) <span class="title">Fine-tuning role instantiation</span><a class="img" href="s2.html#s2.3.1.d"
+ title="PermaLink to (d) Fine-tuning role instantiation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If the lifting operation as defined above degrades the program performance, the lifting semantics can be modified per role
+ class
+ by adding the annotation <code>@org.objectteams.Instantiation</code> which requires an argument of type
+ <code>org.objectteams.InstantiationPolicy</code> in order to select between the following behaviors:
+
+ </p>
+ <dl>
+ <dt>ONDEMAND</dt>
+ <dd>This is the default behavior as defined above.</dd>
+ <dt>ALWAYS</dt>
+ <dd>This strategy avoids maintaining the internal role cache, but instead a fresh role instance is created for each lifting request.
+ This may increase the number of role instances but cuts the costs of accessing the cache, which could otherwise become
+
+ expensive if a cache grows large. As a result of this strategy role state can no longer be shared
+ over time, thus it is discouraged to define fields in a role with this strategy. Also, comparing roles could lead
+ to
+ unexpected results. Therefor, roles with this strategy should implement custom <code>equals</code> and <code>hashCode</code>
+ methods, which should simply delegate to the base instance (using callout <a href="s3.html" title="§3 Callout Binding" class="sect">§3</a>).
+ </dd>
+ <dt>NEVER</dt>
+ <dd>Roles with this instantiation policy are never instantiated by lifting.
+ Such roles cannot define non-static fields.
+ Otherwise this optimization is fully transparent, specifically callout bindings will refer to the correct base instance.<br />
+ As of version 2.0 the OT/J compiler does not implement this strategy.
+ </dd>
+ <dt>SINGLETON</dt>
+ <dd>Roles declaring this strategy will be instantiated at most once per team. Subsequent lifting requests in the same team
+ will always answer the same role instance. Such roles may receive triggers from callin bindings, but cannot define
+ callout bindings.<br />
+ As of version 2.0 the OT/J compiler does not implement this strategy.
+ </dd>
+ </dl>
+ </div>
+ </div>
+ <div class="sect depth3" id="s2.3.2">
+ <h3 class="sect">§2.3.2 Declared lifting<a class="img" href="s2.html#s2.3.2"
+ title="PermaLink to §2.3.2 Declared lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.3">↑ §2.3</a></span></h3>
+ <div class="syntaxlink"><a href="sA.html#sA.6.2" title="§A.6.2 LiftingType" class="syntax">→ Syntax §A.6.2</a></div>
+ <div class="subsect depth4" id="s2.3.2.a">
+ <h4 class="subsect">(a) <span class="title">Parameters with declared lifting</span><a class="img" href="s2.html#s2.3.2.a"
+ title="PermaLink to (a) Parameters with declared lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A non-static team-level method or constructor may declare a parameter with two types
+ in order to explicitly denote a place of <strong>lifting</strong>. Using the syntax
+
+ </p>
+ <div class="listing plain"><pre><b>public</b> <b>void</b> m (BaseClass <em>as</em> RoleClass param) { <i>stmts</i> }</pre></div>
+ <p>a liftable parameter can be declared, provided the second type
+ (<code>RoleClass</code>) is a role of (<code>playedBy</code>) the first type (<code>BaseClass</code>).
+ Furthermore, the role type must be a role of the enclosing team class defining the given method.
+ The role type must be given by its simple (i.e., unqualified) name.
+ <br />
+ Such a signature requires the caller to provide a base object (here <code>BaseClass</code>), but
+ the callee receives a role object (here <code>RoleClass</code>).
+ In fact, the client sees a signature in which the "<code>as RoleClass</code>" part is omitted.
+ <br />
+ Compatibility between caller and callee sides is achieved by an implicitly inserted lifting translation.
+ A signature using declared lifting is only valid, if the requested lifting is possible
+ (see <a href="#s2.3.3" title="§2.3.3 Smart lifting" class="sect">§2.3.3</a> and <a href="#s2.3.4" title="§2.3.4 Binding ambiguities" class="sect">§2.3.4</a> for details).
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.2.b">
+ <h4 class="subsect">(b) <span class="title">Super in the context of declared lifting</span><a class="img" href="s2.html#s2.3.2.b"
+ title="PermaLink to (b) Super in the context of declared lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Calling <code>super</code> or <code>tsuper</code> in a method or constructor which
+ declares lifting for one or more parameters refers to a method or constructor with role type parameters,
+ i.e., lifting takes place <em>before</em> super invocation. Nevertheless, the super method may also
+ have a declared lifting signature. It will then see the same role instance(s) as the current method.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.2.c">
+ <h4 class="subsect">(c) <span class="title">Declared lifting of arrays</span><a class="img" href="s2.html#s2.3.2.c"
+ title="PermaLink to (c) Declared lifting of arrays"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a parameter involving explicit lifting should be of an <strong>array</strong> type, the syntax is
+
+ </p>
+ <div class="listing plain"><pre><b>public</b> <b>void</b> m (BaseClass <b>as</b> RoleClass param[]) ...</pre></div>
+ <p>Here the brackets denoting the array apply to both types, <code>BaseClass</code>
+ and <code>RoleClass</code>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.2.d">
+ <h4 class="subsect">(d) <span class="title">Declared lifting for catch blocks</span><a class="img" href="s2.html#s2.3.2.d"
+ title="PermaLink to (d) Declared lifting for catch blocks"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Also the argument of a catch block may apply declared lifting like in:
+
+ </p>
+ <div class="listing plain"><pre><b>catch</b> (BaseException <b>as</b> RoleClass param) { <i>stmts</i> }</pre></div>
+ <p>This syntax is only valid in a non-static scope of a team (directly or nested).
+ In the given example, <code>RoleClass</code> must be played by <code>BaseException</code>.
+ Note, that <code>RoleClass</code> itself need not be a throwable.
+ As the effect of this declaration the catch block will catch any exception of type <code>BaseException</code>
+ and provides it wrapped with a <code>RoleClass</code> instance to the subsequent block.
+ <br />
+ Also note, that re-throwing the given instance <code>param</code> has the semantics of implicitly lowering
+ the role to its base exception before throwing, because the role conforms to the required type
+ <code>Throwable</code> only via lowering.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.2.e">
+ <h4 class="subsect">(e) <span class="title">Generic declared lifting</span><a class="img" href="s2.html#s2.3.2.e"
+ title="PermaLink to (e) Generic declared lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A method with declared lifting may introduce a type parameter that is bounded relative to a given role type.
+ Such bound is declared as:
+
+ </p>
+ <div class="listing plain"><pre><AnyBase <b>base</b> SuperRole>
+<b>void</b> teamMethod(AnyBase <b>as</b> SuperRole arg) {
+ <span class="comment">// body using arg as of type SuperRole</span>
+}</pre></div>
+ <p>This means that <code>AnyBase</code> is a type parameter whose instantiations must all be liftable to role <code>SuperRole</code>.
+
+ </p>
+ <p>
+ The given type bound requires the call site to supply an argument that is compatible to any base class
+ for which the current team contains a bound role that is a sub class of <code>SuperRole</code>, including <code>SuperRole</code> itself.
+ However, <code>SuperRole</code> itself need not be bound to any base class.
+ On the other hand, different valid substitutions for <code>AnyBase</code> need not be related by inheritance.
+
+ </p>
+ <div class="note">
+ <h5>Note:</h5>
+ This feature supports generalized treatment of otherwise unrelated base classes.
+ This is done by defining one bound role for each base under consideration and by
+ having all these roles extend a common unbound role.
+
+ </div>
+ </div>
+ <h5 class="listing">Example code (Declared Lifting):</h5>
+ <div class="listing example frame" id="l2.3.2">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>team</b> <b>class</b> Super {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> MyRole <b>playedBy</b> MyBase { ... }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>void</b> m (MyRole o) { ... };</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre><b>team</b> <b>class</b> Sub <b>extends</b> Super {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> <b>void</b> m (<em>MyBase <b>as</b> MyRole o</em>) {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <span class="comment">// inside this method o is of type MyRole</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> super.m(o);</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre>Sub s_<b>team</b> = <b>new</b> Sub();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">12</td>
+ <td><pre>MyBase b = <b>new</b> MyBase();</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">13</td>
+ <td><pre>s_team.m(b); <span class="comment">// clients see a parameter "MyBase o"</span></pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="codecomment">
+ <h5>Effects:</h5>
+ <ul>
+ <li>Clients use method <code>m</code> with a base instance (type <code>MyBase</code>) as its argument (line 13).
+ </li>
+ <li>Before executing the body of <code>m</code>, the argument is lifted such that the method body receives
+ the argument as of type <code>MyRole</code> (line 8).
+ </li>
+ </ul>
+ </div>
+ </div>
+ <div class="sect depth3" id="s2.3.3">
+ <h3 class="sect">§2.3.3 Smart lifting<a class="img" href="s2.html#s2.3.3"
+ title="PermaLink to §2.3.3 Smart lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.3">↑ §2.3</a></span></h3>
+ <p>In situations where role and base classes are part of some inheritance
+ hierarchies (<code>extends</code>), choosing the appropriate role class during
+ lifting involves the following rules:
+
+ </p>
+ <div class="subsect depth4" id="s2.3.3.a">
+ <h4 class="subsect">(a) <span class="title">Static adjustment</span><a class="img" href="s2.html#s2.3.3.a"
+ title="PermaLink to (a) Static adjustment"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a base class <code>B</code> shall be lifted to a role class
+ <code>R</code> that is not bound to (<code>playedBy</code>)
+ <code>B</code>, but if a subclass of <code>R</code>
+ — say <code>R2</code> —
+ is bound to <code>B</code>, lifting is statically setup to use
+ <code>R2</code>, the most general subclass of <code>R</code> that
+ is bound to <code>B</code> or one of its super-types.
+
+ </p>
+ <div class="note">
+ <h5>Restriction:</h5>
+ This step is not applicable for parameter mappings of <code>replace</code>
+ callin bindings (<a href="s4.html#s4.5.d" title="§4.5.(d) Typing rules" class="sect">§4.5.(d)</a>).
+
+ </div>
+ </div>
+ <div class="subsect depth4" id="s2.3.3.b">
+ <h4 class="subsect">(b) <span class="title">Dynamic selection of a role class</span><a class="img" href="s2.html#s2.3.3.b"
+ title="PermaLink to (b) Dynamic selection of a role class"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>At runtime also the dynamic type of a base object is considered:
+ Lifting always tries to use a role class that is bound to the
+ exact class of the base object. Lifting considers all role–base
+ pairs bound by <code>playedBy</code> such that the role class is a
+ sub-class of the required (statically declared) role type
+ and the base class is a super-class of the
+ dynamic type of the base object.
+ <br />
+ From those possible pairs the most specific base class is chosen.
+ If multiple role classes are bound to this base class the most
+ specific of these classes is chosen.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.3.c">
+ <h4 class="subsect">(c) <span class="title">Team as closed world</span><a class="img" href="s2.html#s2.3.3.c"
+ title="PermaLink to (c) Team as closed world"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>In the above analysis gathering all role-base pairs is performed at
+ compile-time. From this follows, that a team class can only be
+ compiled when all its contained role classes are known and a role class
+ can never be compiled without its team.
+ <br />
+ The analysis includes all roles and their bindings that are inherited
+ from the super-team.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.3.d">
+ <h4 class="subsect">(d) <span class="title">Selection regardless of abstractness</span><a class="img" href="s2.html#s2.3.3.d"
+ title="PermaLink to (d) Selection regardless of abstractness"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Smart lifting is not affected by abstractness of role classes.
+ For the effect of abstract role classes see <a href="#s2.5" title="§2.5 Abstract Roles" class="sect">§2.5</a>.
+
+ </p>
+ </div>
+ <h5>Complex Example:</h5>
+ <p><img src="../images/smart_lifting_small.png" alt="smart lifting example" /></p>
+ <table border="2" width="80%">
+ <colgroup span="1">
+ <col align="left" span="1" />
+ <col align="left" span="1" />
+ </colgroup>
+ <tr>
+ <th rowspan="1" colspan="1">role class</th>
+ <th rowspan="1" colspan="1">base class</th>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">class R1</td>
+ <td rowspan="1" colspan="1"> </td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">class R2 extends R1 playedBy B2</td>
+ <td rowspan="1" colspan="1">class B2</td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">class R3 extends R2 <em>/* inherited: playedBy B2 */ </em></td>
+ <td rowspan="1" colspan="1">class B3 extends B2</td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">class R4 extends R3 playedBy B4</td>
+ <td rowspan="1" colspan="1">class B4 extends B3</td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">class R5 extends R4 <em>/* inherited: playedBy B4 */</em></td>
+ <td rowspan="1" colspan="1"> </td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1"> </td>
+ <td rowspan="1" colspan="1">class B6 extends B4</td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">class R7 extends R5 playedBy B7</td>
+ <td rowspan="1" colspan="1">class B7 extends B6</td>
+ </tr>
+ </table>
+ <div class="codecomment">
+ <ul>
+ <li>If declarations require lifting <code>B3</code> to <code>R1</code>
+ this is statically refined to use <code>R2</code> instead, because this
+ is the most general class declaring a binding to a super–class
+ of <code>B3</code>.
+
+ </li>
+ <li>If the dynamic base type in the same situation is <code>B6</code>,
+ three steps select the appropriate role:
+
+ <ol>
+ <li>By searching all <code>playedBy</code> clauses (including those
+ that are inherited) the following role–base pairs are
+ candidates:<br /><code>(R2,B2), (R3,B2), (R4,B4)</code> and <code>(R5,B4)</code>.
+ </li>
+ <li>From these pairs the two containing the most specific base class
+ <code>B4</code> are chosen.
+ </li>
+ <li>This makes <code>R4</code> and <code>R5</code> role candidates,
+ from which the most specific <code>R5</code> is finally chosen.
+ </li>
+ </ol>
+ </li>
+ </ul>
+ </div>
+ <p>If the inheritance hierarchies of the involved base and role classes are given (like in the figure above)
+ the smart lifting algorithm can be rephrased to the following "graphical" rule:<br /></p>
+ <div class="note">
+ Starting with the dynamic base type (<code>B6</code> in the example) move upwards the the inheritance
+ relation until you reach a base class bound to a role class indicated by a «playedBy»
+ arrow pointing to the base class (<code>B4</code>). This role class must be conform to the requested role type.
+ Switch to the role side along this arrow (<code>R4</code>). Now move downwards the role inheritance hierarchy
+ as long as the subrole does not refine the playedBy relationship (indicated by another «playedBy» arrow).
+ The bottom role you reach this way (<code>R5</code>) is the role type selected by smart lifting.
+
+ </div>
+ </div>
+ <div class="sect depth3" id="s2.3.4">
+ <h3 class="sect">§2.3.4 Binding ambiguities<a class="img" href="s2.html#s2.3.4"
+ title="PermaLink to §2.3.4 Binding ambiguities"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.3">↑ §2.3</a></span></h3>
+ <p>While all examples so far have only shown 1-to-1 class bindings,
+ several cases of multiple bindings are allowable. Ambiguities may be
+ detected at compile time and/or at runtime.
+
+ </p>
+ <div class="subsect depth4" id="s2.3.4.a">
+ <h4 class="subsect">(a) <span class="title">Potential ambiguity</span><a class="img" href="s2.html#s2.3.4.a"
+ title="PermaLink to (a) Potential ambiguity"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A <strong>potential ambiguity</strong> is given,
+ if two role classes <code>R1</code> and <code>R2</code>
+ exist such that
+
+ </p>
+ <ul>
+ <li><code>R1</code> and <code>R2</code> are played by the
+ same base class <code>B</code>, and
+ </li>
+ <li><code>R1</code> and <code>R2</code> have a common
+ super role <code>R0</code>,
+ which is also bound to a base class <code>B0</code>, and
+ </li>
+ <li>neither role class <code>R1</code> nor
+ <code>R2</code> is a (indirect) sub-class of the other.
+ </li>
+ </ul>
+ <div class="note">
+ <h5>Note:</h5>
+ According to <a href="#s2.1.c" title="§2.1.(c) Covariant refinement" class="sect">§2.1.(c)</a>, if <code>B</code> is distinct from <code>B0</code>
+ it has to be a sub-class of <code>B0</code>.
+
+ </div>
+ <div class="note">
+ <h5>Effect:</h5>
+ In this case the compiler issues a warning, stating that the <code>B</code><em> may not be liftable,</em> because both role classes <code>R1</code>
+ and <code>R2</code> are candidates and there is no reason to prefer one over the other.
+ <br /><strong>If no potential ambiguity is detected, lifting will always be unambiguous.</strong></div>
+ <p>In the above situation, trying to lift an instance of type <code>B</code> to the role type
+ <code>R0</code> is an <strong>illegal lifting request</strong>. If <code>R0</code> is bound
+ to the same base class <code>B</code> as its sub-roles <code>R1</code> and <code>R2</code> are,
+ role <code>R0</code> is <strong>unliftable</strong>, meaning that no instance of <code>R0</code>
+ can ever by obtained by lifting.
+
+ </p>
+ <h5 class="listing">Example code (Potential Ambiguity):</h5>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>team</b> <b>class</b> MyTeam {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> SuperRole <b>playedBy</b> MyBase {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleA <b>extends</b> SuperRole {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleB <b>extends</b> SuperRole {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <div class="subsect depth4" id="s2.3.4.b">
+ <h4 class="subsect">(b) <span class="title">Definite ambiguity</span><a class="img" href="s2.html#s2.3.4.b"
+ title="PermaLink to (b) Definite ambiguity"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A <strong>definite ambiguity</strong> is given if
+
+ </p>
+ <ul>
+ <li>the situation of potential ambiguity according to (a)
+ above is given and
+ </li>
+ <li>lifting is requested (either by method binding or explicitly
+ (<a href="#s2.3.2" title="§2.3.2 Declared lifting" class="sect">§2.3.2</a>)) from the shared base class <code>B</code> to any role
+ class <code>R0</code> that is a common super role for <code>R1</code> and <code>R2</code>.
+ </li>
+ </ul>
+ <p>Definite binding ambiguity also occurs in cases of generic declared lifting <a href="#s2.3.2.e" title="§2.3.2.(e) Generic declared lifting"
+ class="sect">§2.3.2.(e)</a>
+ if the specified role <code>R</code> is unbound and if two independent sub-roles <code>R1</code> and <code>R2</code>
+ exist that introduce a playedBy binding to the same base class <code>BX</code>.
+ In this case no potential ambiguity is flagged because roles <code>R1</code> and <code>R2</code>
+ have no shared bound super-role.
+
+ </p>
+ <div class="note">
+ <h5>Effect:</h5>
+ Code causing definite ambiguity is required to handle <code>org.objectteams.LiftingFailedException</code>.
+
+ </div>
+ <p>
+ In cases of definite binding ambiguity lifting will indeed fail except for some corner cases.
+ Such corner cases may arise if lifting already finds an appropriate role in the cache or
+ if an (indirect) subrole of the ambiguously bound role is an unambiguous lift target for the
+ concrete type of the base object at run-time. See also <a href="#s2.3.5" title="§2.3.5 Consequences of lifting problems"
+ class="sect">§2.3.5</a>.
+
+ </p>
+ <h5 class="listing">Example code (Definite Ambiguity):</h5>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>team</b> <b>class</b> MyTeam {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> SuperRole <b>playedBy</b> MyBase {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleA <b>extends</b> SuperRole <b>playedBy</b> SubBase {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleB <b>extends</b> SuperRole <b>playedBy</b> SubBase {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> <b>public</b> <b>void</b> useSuperRole(SubBase <b>as</b> SuperRole r) {...} <span class="comment">// <span class="error">must declare LiftingFailedException</span></span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <div class="subsect depth4" id="s2.3.4.c">
+ <h4 class="subsect">(c) <span class="title">Actual ambiguity</span><a class="img" href="s2.html#s2.3.4.c"
+ title="PermaLink to (c) Actual ambiguity"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>At runtime <strong>actual ambiguity</strong> may occur if for the
+ <em>dynamic type</em> of a base to be lifted the conditions of (b)
+ above hold accordingly. Actual ambiguity is only possible in cases
+ reported by the compiler as potential or definite ambiguity.
+
+ </p>
+ <div class="note">
+ <h5>Effect:</h5>
+ An actual ambiguity is reported at runtime by throwing a
+ <code>org.objectteams.LiftingFailedException</code>.
+
+ </div>
+ <h5 class="listing">Example code (Actual Ambiguity):</h5>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>import</b> org.objectteams.LiftingFailedException;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre><b>team</b> <b>class</b> MyTeam {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>public</b> <b>class</b> SuperRole <b>playedBy</b> MyBase {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleA <b>extends</b> SuperRole <b>playedBy</b> SubBase {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleB <b>extends</b> SuperRole <b>playedBy</b> SubBase {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> </pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <b>public</b> <b>void</b> useSuperRole(MyBase <b>as</b> SuperRole r) <b>throws</b> LiftingFailedException {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre><span class="comment">// plus these calls:</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre>MyTeam mt = <b>new</b> MyTeam();</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre>mt.useSuperRole(<b>new</b> SubBase()); <span class="comment">// <span class="error">will throw a LiftingFailedException</span></span></pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <div class="subsect depth4" id="s2.3.4.d">
+ <h4 class="subsect">(d) <span class="title">Mismatching role</span><a class="img" href="s2.html#s2.3.4.d"
+ title="PermaLink to (d) Mismatching role"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>In cases of potential ambiguity another runtime error may occur:
+ a <strong>mismatching role</strong> is encountered when a role is found
+ in the cache, which is not conform to the required type.
+ This happens, if the base object has previously been lifted
+ to a type that is incompatible with the currently requested type.
+
+ </p>
+ <div class="note">
+ <h5>Effect:</h5>
+ This is reported by throwing a <code>org.objectteams.WrongRoleException</code>.
+
+ </div>
+ <h5 class="listing">Example code (Mismatching Role):</h5>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>import</b> org.objectteams.LiftingFailedException;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>team</b> <b>class</b> MyTeam {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>public</b> <b>class</b> SuperRole <b>playedBy</b> MyBase {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleA <b>extends</b> SuperRole {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <b>public</b> <b>class</b> SubRoleB <b>extends</b> SuperRole {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> </pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <b>public</b> <b>void</b> useRoleA(MyBase <b>as</b> SubRoleA r) <b>throws</b> LiftingFailedException {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> <b>public</b> <b>void</b> useRoleB(MyBase <b>as</b> SubRoleB r) <b>throws</b> LiftingFailedException {...}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre><span class="comment">// plus these calls:</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre>MyTeam mt = <b>new</b> MyTeam();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">12</td>
+ <td><pre>MyBase b = <b>new</b> MyBase();</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">13</td>
+ <td><pre>mt.useRoleA(b); <span class="comment">// creates a SubRoleA for b</span></pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">14</td>
+ <td><pre>mt.useRoleB(b); <span class="comment">// <span class="error">finds the SubRoleA which is not compatible</span></span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">15</td>
+ <td><pre> <span class="comment">// <span class="error">to the expected type SubRoleB.</span></span></pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>From the second item of <a href="#s2.3.4.a" title="§2.3.4.(a) Potential ambiguity"
+ class="sect">§2.3.4.(a)</a> follows, that for binding ambiguities different
+ role hierarchies are analyzed in isolation.
+ For this analysis only those role classes are considered that are bound to a
+ base class (directly using <code>playedBy</code> or by inheriting this relation
+ from another role class).
+ I.e., two role classes that have no common bound super role will never cause
+ any ambiguity.
+
+ </p>
+ </div>
+ </div>
+ <div class="sect depth3" id="s2.3.5">
+ <h3 class="sect">§2.3.5 Consequences of lifting problems<a class="img" href="s2.html#s2.3.5"
+ title="PermaLink to §2.3.5 Consequences of lifting problems"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.3">↑ §2.3</a></span></h3>
+ <p>The rules for lifting and role binding allow (after issuing a warning) two problematic situations:</p>
+ <ol>
+ <li>A potential binding ambiguity makes selection of the approprate role type impossible (<a href="#s2.3.4.a" title="§2.3.4.(a) Potential ambiguity"
+ class="sect">§2.3.4.(a)</a>)
+ </li>
+ <li>A role which might be relevant for lifting is abstract (<a href="#s2.5.b" title="§2.5.(b) Relevant roles" class="sect">§2.5.(b)</a>)
+ </li>
+ </ol>
+ <p>Whenever lifting fails for one of these reasons an <code>org.objectteams.LiftingFailedException</code> (<a href="s6.html#s6.2.d" title="§6.2.(d) Exceptions" class="sect">§6.2.(d)</a>)
+ is thrown.
+ Given that this is a checked exception and depending on the location requiring lifting this has the following consequences:
+
+
+ </p>
+ <div class="subsect depth4" id="s2.3.5.a">
+ <h4 class="subsect">(a) <span class="title">Problematic declared lifting</span><a class="img" href="s2.html#s2.3.5.a"
+ title="PermaLink to (a) Problematic declared lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A method with declared lifting (<a href="#s2.3.2" title="§2.3.2 Declared lifting" class="sect">§2.3.2</a>) may have to declare <code>org.objectteams.LiftingFailedException</code>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.5.b">
+ <h4 class="subsect">(b) <span class="title">Problematic callout binding</span><a class="img" href="s2.html#s2.3.5.b"
+ title="PermaLink to (b) Problematic callout binding"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The role method of a callout binding with result lifting (<a href="s3.html#s3.3.c" title="§3.3.(c) Result translation"
+ class="sect">§3.3.(c)</a>) may have to declare <code>org.objectteams.LiftingFailedException</code>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.5.c">
+ <h4 class="subsect">(c) <span class="title">Problematic callin binding</span><a class="img" href="s2.html#s2.3.5.c"
+ title="PermaLink to (c) Problematic callin binding"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A callin binding (<a href="s4.html" title="§4 Callin Binding" class="sect">§4</a>) may silently fail due to a <code>org.objectteams.LiftingFailedException</code>.
+ This exception will actually remain hidden because the callin binding is not explicitly invoked from any source code
+ but implicitly
+ by the runtime dispatch mechanism. To signal this situation the compiler raises an error against such callin binding.
+
+ </p>
+ <p>However, the compiler should allow to configure this error and understand the warning token <code>"hidden-lifting-problem"</code>
+ for suppressing this problem (<a href="s4.html#s4.1.b"
+ title="§4.1.(b) Prerequisite: Class binding"
+ class="sect">§4.1.(b)</a>).
+ If the problem is ignored/suppressed and if at runtime the lifting problem occurs,
+ triggering of the callin binding will silently fail, i.e., the program will continue in this situation as if the binding
+ hadn't existed in the first place.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.3.5.d">
+ <h4 class="subsect">(d) <span class="title">Incompatible redefinition of a role hierarchy</span><a class="img" href="s2.html#s2.3.5.d"
+ title="PermaLink to (d) Incompatible redefinition of a role hierarchy"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Consider a team <code>T1</code> with a method <code>m</code> with declared lifting regarding role <code>R</code>,
+ where no lifting problems are detected.
+ Consider next a sub-team <code>T2</code> which modifies the hierarchy of role <code>R</code> such that lifting
+ to <code>T2.R</code> is problematic due to a binding ambiguity.
+ In this case clients invoking <code>T1.m()</code> could face the situation at runtime that an instance
+ of <code>T2</code> is used that <em>unexpectedly</em> fails to lift to its role <code>R</code>.
+ Here, the compiler signals a specific error against <code>T2</code> alerting of the incompatible change.
+
+ </p>
+ </div>
+ </div>
+ </div>
+ <div class="sect depth2" id="s2.4">
+ <h2 class="sect">§2.4 Explicit role creation<a class="img" href="s2.html#s2.4"
+ title="PermaLink to §2.4 Explicit role creation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §2</a></span></h2>
+ <p>Lifting is the normal technique by which role objects are created implicitly.
+ This section defines under which conditions a role can also be created explicitly.
+
+ </p>
+ <div class="sect depth3" id="s2.4.1">
+ <h3 class="sect">§2.4.1 Role creation via a lifting constructor<a class="img" href="s2.html#s2.4.1"
+ title="PermaLink to §2.4.1 Role creation via a lifting constructor"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.4">↑ §2.4</a></span></h3>
+ <p>Lifting uses the default constructor for roles (see <a href="#s2.3.1" title="§2.3.1 Implicit role creation" class="sect">§2.3.1</a>).
+ This constructor can be invoked from client code, if the following rules are respected.
+
+ </p>
+ <div class="subsect depth4" id="s2.4.1.a">
+ <h4 class="subsect">(a) <span class="title">Team context</span><a class="img" href="s2.html#s2.4.1.a"
+ title="PermaLink to (a) Team context"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The lifting constructor can be used only within the enclosing team of
+ the role to be instantiated. Thus, qualified allocation expressions
+ (<code>someTeam.new SomeRole(..)</code>) may never use the lifting constructor.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.4.1.b">
+ <h4 class="subsect">(b) <span class="title">Fresh base object</span><a class="img" href="s2.html#s2.4.1.b"
+ title="PermaLink to (b) Fresh base object"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If the argument to a lifting constructor invocation is a <code>new</code>
+ expression, creating a fresh base object, the use of the lifting constructor
+ is safe. Otherwise the rules of (c) below apply.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.4.1.c">
+ <h4 class="subsect">(c) <span class="title">Duplicate role runtime check</span><a class="img" href="s2.html#s2.4.1.c"
+ title="PermaLink to (c) Duplicate role runtime check"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If it cannot be syntactically derived, that the argument to a lifting
+ constructor is a freshly created base object (b), a compile time warning will
+ signal that an additional runtime check is needed: It must be prevented that
+ a new role is created for a base object, which already has a role of the
+ required type in the given team. It is not possible to replace an existing
+ role by use of the lifting constructor. At runtime, any attempt to do so
+ will cause a <code>org.objectteams.DuplicateRoleException</code> to be thrown.
+ This exception can only occur in situations where the mentioned compile
+ time warning had been issued.
+ <br /><a href="s6.html#s6.1" title="§6.1 Reflection" class="sect">§6.1</a> will introduce reflective functions
+ which can be used to manually prevent errors like a duplicate role.
+
+ </p>
+ </div>
+ </div>
+ <div class="sect depth3" id="s2.4.2">
+ <h3 class="sect">§2.4.2 Role creation via a regular constructor<a class="img" href="s2.html#s2.4.2"
+ title="PermaLink to §2.4.2 Role creation via a regular constructor"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.4">↑ §2.4</a></span></h3>
+ <p>Roles may also be created explicitly using a custom constructor with arbitrary signature
+ other than the signature of the lifting constructor.<br />
+ Within role constructors, four kinds of self-calls are possible:
+
+ </p>
+ <dl>
+ <dt><code>base(..)</code></dt>
+ <dd>A constructor of the corresponding base class (<a href="sA.html#sA.5.3" title="§A.5.3 BaseCall" class="sect">§A.5.3</a>(c)),
+ <span class="underline">unless</span> the role is involved in base class circularity (<a href="#s2.1.2.b" title="§2.1.2.(b) Cycles" class="sect">§2.1.2.(b)</a>),
+ in which case a base constructor call is illegal.
+ </dd>
+ <dt><code>this(..)</code></dt>
+ <dd>Another constructor of the same class.</dd>
+ <dt><code>super(..)</code></dt>
+ <dd>A constructor of the super-class (normal <code>extends</code>), <span class="underline">unless</span> the super-class is bound to a different base class, in which case calling <code>super(..)</code> is not legal.
+ </dd>
+ <dt><code>tsuper(..)</code></dt>
+ <dd>A constructor of the corresponding role of the super-team (<a href="sA.html#sA.5.4" title="§A.5.4 TSuperCall" class="sect">§A.5.4</a>(e)). Also see the constraint in <a href="s1.html#s1.3.2.c"
+ title="§1.3.2.(c) Constructors and overridden 'extends' "
+ class="sect">§1.3.2.(c)</a>.
+ </dd>
+ </dl>
+ <div class="subsect depth4" id="s2.4.2.a">
+ <h4 class="subsect">(a) <span class="title">Unbound roles</span><a class="img" href="s2.html#s2.4.2.a"
+ title="PermaLink to (a) Unbound roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Each constructor of a role that is <strong>not bound</strong> to a base class must use
+ one of <code>this(..)</code>, <code>super(..)</code> or <code>tsuper(..)</code>.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.4.2.b">
+ <h4 class="subsect">(b) <span class="title">Bound roles</span><a class="img" href="s2.html#s2.4.2.b" title="PermaLink to (b) Bound roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Each constructor of a <strong>bound role</strong> must directly or indirectly invoke either
+ a <code>base(..)</code> constructor or a lifting constructor (see <a href="#s2.3.1" title="§2.3.1 Implicit role creation" class="sect">§2.3.1</a>).
+ Indirect calls to the base constructor or lifting constructor may use any of <code>this(..)</code>, <code>super(..)</code>
+ or <code>tsuper(..)</code>, which simply delegates the obligation to the called constructor.
+ <br />
+ If a constructor referenced by <code>base(..)</code> is not visible according to the
+ regular rules of Java, it may still be called using <b>decapsulation</b> (see
+ also <a href="s3.html#s3.4" title="§3.4 Overriding access restrictions"
+ class="sect">§3.4</a>, <a href="#s2.1.2.c" title="§2.1.2.(c) Base class decapsulation"
+ class="sect">§2.1.2.(c)</a>).
+ <br />
+ Note, that if the super or tsuper role is not bound, delegating the obligation to that unbound role will not work.
+
+ </p>
+ </div>
+ <div class="subsect depth4" id="s2.4.2.c">
+ <h4 class="subsect">(c) <span class="title">Super-call for bound roles</span><a class="img" href="s2.html#s2.4.2.c"
+ title="PermaLink to (c) Super-call for bound roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Instead of or prior to calling <code>base(..)</code> a constructor of a bound role explicitly or implicitly calls a super constructor.
+ Which constructor is applicable depends on the super role and its <code>playedBy</code> clause.
+
+ </p>
+ <ul>
+ <li>If the super role is bound to the same base class as the current role is,
+
+ <ul>
+ <li>not writing a super-call causes the lifting constructor of the super role to be invoked.</li>
+ <li>explicitly calling a super constructor requires the super constructor to <i>either</i><ol>
+ <li>create a role instance using a base constructor call (directly or indirectly), <i>or</i></li>
+ <li>be a lifting constructor receiving a base instance, which the current role must provide as the argument.</li>
+ </ol>
+ </li>
+ </ul>
+ </li>
+ <li>If the super role is bound but the current role refines the <code>playedBy</code>
+ relationship (cf. <a href="#s2.1.c" title="§2.1.(c) Covariant refinement" class="sect">§2.1.(c)</a>),
+
+ <ul>
+ <li>a lifting constructor must be called explicitly passing a base object as the argument.</li>
+ </ul>
+ </li>
+ <li>If the role has an explicit or implicit super role which is unbound the constructor may optionally
+ call a super constructor (using <code>super(..)</code> or <code>tsuper(..)</code>) prior to calling
+ <code>base(..)</code>. Otherwise the default constructor is implicitly invoked.
+
+ </li>
+ </ul>
+ <p>When invoking a lifting constructor of a super role the base object can optionally be obtained by using a base constructor
+ call as an expression:
+
+ </p>
+ <div class="listing plain"><pre>super(base(<i><args></i>));</pre></div>
+ </div>
+ <p>The language system evaluates the base constructor by creating an
+ instance of the appropriate base class using a constructor with matching
+ signature. Also the internal links are setup that are needed for accessing the
+ base object from the role and for lifting the base object to the new role
+ in the future.
+
+ </p>
+ <p>The syntax for base constructors follows the rule that role implementations
+ never directly refer to any names of base classes or their features.
+
+ </p>
+ </div>
+ <div class="sect depth3" id="s2.4.3">
+ <h3 class="sect">§2.4.3 Role creation in the presence of smart lifting<a class="img" href="s2.html#s2.4.3"
+ title="PermaLink to §2.4.3 Role creation in the presence of smart lifting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#s2.4">↑ §2.4</a></span></h3>
+ <p>Explicitly instantiating a role <code>R1</code> bound to a base <code>B</code> where smart lifting of <code>B</code> to <code>R1</code> would actually
+ provide a subrole <code>R2</code> is dangerous: Instantiation enters the <code>R1</code> into the team's internal cache. If at any time later lifting
+ this <code>B</code> to <code>R2</code> is requested, which is a legal request, the runtime system will answer by throwing a <code>org.objectteams.WrongRoleException</code>
+ because it finds the <code>R1</code> instead of the required <code>R2</code>.
+ For this reason, in this specific situation the explicit instantiation <code>new R1(..)</code> will be flagged by a warning.
+ The problem can be avoided by using <code>R2</code> in the instantiation expression.
+
+ </p>
+ <h5 class="listing">Example code (WrongRoleException):</h5>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>class</b> B { <b>void</b> bm() {} }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> T {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>protected</b> <b>class</b> R1 <b>playedBy</b> B {...}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <b>protected</b> <b>class</b> R2 <b>extends</b> R1 { <span class="comment">// inherits the binding to B</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> <b>void</b> rm() { <span class="comment">/* body omitted */</span> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">7</td>
+ <td><pre> <b>public</b> B getDecoratedB() {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">8</td>
+ <td><pre> <b>return</b> <em><b>new</b> R1</em>(<b>new</b> B()); <span class="comment">// <span class="error">compile-time warning!</span></span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">9</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">10</td>
+ <td><pre> <b>public</b> <b>void</b> requestLifting(B <b>as</b> R2 r) {}</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">11</td>
+ <td><pre>}</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">12</td>
+ <td><pre><span class="comment">// plus these calls:</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">13</td>
+ <td><pre>T t = <b>new</b> T();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">14</td>
+ <td><pre>B b = t.getDecoratedB(); <span class="comment">// creates an R1 for b</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">15</td>
+ <td><pre>t.requestLifting(b); <span class="comment">// => <span class="error"><code>org.objectteams.WrongRoleException!</code></span></span></pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="codecomment">
+ <ul>
+ <li>A note on line 8: this line passes a fresh instance of <code>B</code> to the lifting constructor of <code>R1</code>
+ (see <a href="#s2.4.1.b" title="§2.4.1.(b) Fresh base object"
+ class="sect">§2.4.1.(b)</a>). In order to return this <code>B</code> instance lowering is implicitly used for the return statement.
+ </li>
+ <li>When line 15 is executed, a lifting of <code>b</code> to <code>R2</code> is requested but due to line 8 an <code>R1</code> is found in the internal cache.
+ </li>
+ </ul>
+ </div>
+ </div>
+ </div>
+ <div class="sect depth2" id="s2.5">
+ <h2 class="sect">§2.5 Abstract Roles<a class="img" href="s2.html#s2.5"
+ title="PermaLink to §2.5 Abstract Roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §2</a></span></h2>
+ <p>Overriding of role classes and dynamic binding of role types (<a href="s1.html#s1.3.1.e"
+ title="§1.3.1.(e) Dynamic binding of types"
+ class="sect">§1.3.1.(e)</a>)
+ adds new cases to <strong>creation</strong> with respect to abstract classes.
+
+ </p>
+ <div class="subsect depth3" id="s2.5.a">
+ <h4 class="subsect">(a) <span class="title">Using abstract classes for creation</span><a class="img" href="s2.html#s2.5.a"
+ title="PermaLink to (a) Using abstract classes for creation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Abstract role classes can indeed be used for object creation.
+ The effect of such a statement is that the team must be
+ marked <code>abstract</code>. Only those sub-teams are concrete
+ that provide concrete versions for all role classes used in
+ creation expressions.<br />
+ This includes the case, where a
+ super-team has a concrete role class and creates
+ instances of this role class and only the sub-team changes
+ the status of this role class to abstract. Also here
+ the sub-team must be marked abstract, because it contains
+ an abstract role class that is used in creation expressions.
+
+ </p>
+ <div class="note">
+ <h5>Interpretation:</h5>
+ Since the type in a role creation expression is late-bound relative to the enclosing team instance, abstract role classes
+ can be seen
+ as the hook in a <strong>template&hook pattern</strong> that is raised from the method level to the class level:
+ A super-team may already refer to the constructor of an abstract role class,
+ only the sub-team will provide the concrete role class to fill the hook with the necessary implementation.
+
+ </div>
+ </div>
+ <div class="subsect depth3" id="s2.5.b">
+ <h4 class="subsect">(b) <span class="title">Relevant roles</span><a class="img" href="s2.html#s2.5.b"
+ title="PermaLink to (b) Relevant roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A team must be marked <code>abstract</code> if one of its <strong>relevant roles</strong> is abstract.
+ <br />
+ A role is relevant in this sense if
+
+ </p>
+ <ul>
+ <li>the role class is public <em>or if</em></li>
+ <li>an explicit <code>new</code> expression
+ would require to create instances of the role class, <em>or if</em></li>
+ <li>any of the lifting methods of the enclosing team
+ would require to create instances of the role class.<br />
+ A role is irrelevant with respect to lifting
+ if either of the following holds:
+
+ <ul>
+ <li>It is not bound to a base class, neither directly nor
+ by an inherited <code>playedBy</code> clause.
+ </li>
+ <li>It has a sub-role without a <code>playedBy</code> clause.
+ </li>
+ <li>It is bound to an abstract base class, and for all concrete
+ sub-classes of the base class, a binding to a more specific role class exists.
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>If neither property, relevance nor irrelevance, can be shown for an abstract role,
+ a warning is given in case the enclosing team is not abstract.
+
+ </p>
+ </div>
+ </div>
+ <div class="sect depth2" id="s2.6">
+ <h2 class="sect">§2.6 Explicit base references<a class="img" href="s2.html#s2.6"
+ title="PermaLink to §2.6 Explicit base references"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §2</a></span></h2>
+ <p>The role-base link is not meant to be accessed explicitly from programs,
+ but it is fully under the control of compiler and runtime environment.
+ Accessing features of a role's base object is done by
+ <a href="s3.html" title="§3 Callout Binding" class="sect">callout bindings (§3)</a>.
+ Yet, a keyword <code>base</code> exists, which can be used in the following
+ contexts:
+
+ </p>
+ <div class="subsect depth3" id="s2.6.a">
+ <h4 class="subsect">(a) <span class="title">Externalized roles of a base team</span><a class="img" href="s2.html#s2.6.a"
+ title="PermaLink to (a) Externalized roles of a base team"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If the base class of a role <code>T1.R1</code> is again a team
+ <code>T2</code>, roles of that team <code>T2</code> can be
+ externalized (see <a href="s1.html#s1.2.2" title="§1.2.2 Externalized roles"
+ class="sect">§1.2.2</a>)
+ using <code>base</code> as their type anchor. Given that
+ <code>R2</code> is a role of <code>T2</code>, one could write:
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>public</b> <b>team</b> <b>class</b> T1 {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>protected</b> <b>class</b> R1 <em><b>playedBy</b> T2</em> {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>protected</b> <em>R2<@base></em> aRoleOfMyBase;</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>This syntax is only legal within the body of the role <code>T1.R1</code> which is bound
+ to the team <code>T2</code> containing role <code>R2</code>.
+ A static type prefix can be used to disambiguate a base anchor, so the explicit variant
+ of the above type would be <code>R2<@<strong>R1</strong>.base></code>.
+ <br />
+ It is not legal to use a type anchor containing <code>base</code> as an element in a path
+ of references like <code><@base.<span class="error">field</span>></code>
+ or <code><@<span class="error">field</span>.base></code>.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.6.b">
+ <h4 class="subsect">(b) <span class="title">Explicit base object creation</span><a class="img" href="s2.html#s2.6.b"
+ title="PermaLink to (b) Explicit base object creation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Within a role constructor (which is not the lifting constructor)
+ the syntax <code>base(<em>arguments</em>)</code> causes an instance
+ of the bound base class to be created and linked (see <a href="#s2.4.2"
+ title="§2.4.2 Role creation via a regular constructor"
+ class="sect">§2.4.2</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.6.c">
+ <h4 class="subsect">(c) <span class="title">Base call in callin method</span><a class="img" href="s2.html#s2.6.c"
+ title="PermaLink to (c) Base call in callin method"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>Within a <a href="s4.html#s4.2.d" title="§4.2.(d) Callin methods"
+ class="sect">callin method (§4.2.(d))</a>
+ an expression <code>base.m(<em>args</em>)</code> is used to invoke the
+ originally called method (see <a href="s4.html#s4.3" title="§4.3 Base calls" class="sect">§4.3</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.6.d">
+ <h4 class="subsect">(d) <span class="title">Base guard predicates</span><a class="img" href="s2.html#s2.6.d"
+ title="PermaLink to (d) Base guard predicates"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p><a href="s5.html#s5.4" title="§5.4 Guard predicates" class="sect">Guard predicates (§5.4)</a> can
+ be specified to act on the base side using the <code><strong>base when</strong></code> keywords.
+ Within such a base guard predicate <code>base</code> is interpreted as a special identifier
+ holding a reference to the base object that is about to be lifted
+ for the sake of a callin method interception (see <a href="s5.html#s5.4.2.a" title="§5.4.2.(a) Base object reference"
+ class="sect">§5.4.2.(a)</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.6.e">
+ <h4 class="subsect">(e) <span class="title">Parameter mappings</span><a class="img" href="s2.html#s2.6.e"
+ title="PermaLink to (e) Parameter mappings"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>An expression at the right-hand side of a parameter mapping
+ (parameter in a callin binding (<a href="s4.html#s4.4" title="§4.4 Callin parameter mapping"
+ class="sect">§4.4</a>) or
+ result in a callout binding (<a href="s3.html#s3.2.c" title="§3.2.(c) Result mapping"
+ class="sect">§3.2.(c)</a>) ) may use the keyword <code>base</code>
+ to refer to the bound base instance. Such usage requires the role method bound in this method binding to be non-static.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.6.f">
+ <h4 class="subsect">(f) <span class="title">Inhibition of modification</span><a class="img" href="s2.html#s2.6.f"
+ title="PermaLink to (f) Inhibition of modification"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>In all cases, the <code>base</code> reference is immutable,
+ i.e., <code>base</code> can never appear as the left-hand-side of an assignment.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.6.g">
+ <h4 class="subsect">(g) <span class="title">Decapsulation via base reference</span><a class="img" href="s2.html#s2.6.g"
+ title="PermaLink to (g) Decapsulation via base reference"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>In cases <a href="#s2.6.d" title="§2.6.(d) Base guard predicates"
+ class="sect">§2.6.(d)</a> and <a href="#s2.6.e" title="§2.6.(e) Parameter mappings" class="sect">§2.6.(e)</a> above, members of the base
+ object may be accessed that would not be visible under Java's visibility rules.
+ Such references are treated as decapsulation in accordance with <a href="s3.html#s3.4.a"
+ title="§3.4.(a) Callout to inaccessible base method"
+ class="sect">§3.4.(a)</a> and <a href="s3.html#s3.5.e" title="§3.5.(e) Access control"
+ class="sect">§3.5.(e)</a>.<br />
+ Note that accessing a base field via <code>base</code> only gives reading access to this field.
+
+ </p>
+ </div>
+ <div class="newpage"></div>
+ </div>
+ <div class="sect depth2" id="s2.7">
+ <h2 class="sect">§2.7 Advanced structures<a class="img" href="s2.html#s2.7"
+ title="PermaLink to §2.7 Advanced structures"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §2</a></span></h2>
+ <p>This section discusses how role containment and the playedBy relationship can be combined.
+ It does not define new rules, but illustrates rules defined above. The central idea is that any class
+ can have more than one of the three flavors <em>team, role, </em>and<em> base</em>.
+
+ </p>
+ <div class="subsect depth3" id="s2.7.a">
+ <h4 class="subsect">(a) <span class="title">Nesting</span><a class="img" href="s2.html#s2.7.a" title="PermaLink to (a) Nesting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If a role (contained in a team) is also a team (marked with the <code>team</code> modifier)
+ it is a <strong>nested team</strong>. The depth of nesting is not restricted.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.7.b">
+ <h4 class="subsect">(b) <span class="title">Stacking</span><a class="img" href="s2.html#s2.7.b" title="PermaLink to (b) Stacking"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If the base class to which a role is bound using <code>playedBy</code> is a team,
+ the role is said to be <strong>stacked</strong> on the base team.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s2.7.c">
+ <h4 class="subsect">(c) <span class="title">Layering</span><a class="img" href="s2.html#s2.7.c" title="PermaLink to (c) Layering"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If roles of a team <code>Secondary</code> are played by roles of another team <code>Primary</code>
+ (i.e., base classes are roles), the team <code>Secondary</code> defines a <strong>layer</strong> over the team <code>Primary</code>.
+ Such layering requires a final reference <code>anchor</code> from <code>Secondary</code> to an instance of <code>Primary</code>.
+ All playedBy declarations within <code>Secondary</code> specify their base classes anchored to that final link <code>anchor</code>.
+
+ </p><img src="../images/Layering.png" alt="Team layering example" /><p>Due to the anchored base types, layered teams implicitly support the following guarantee:
+ all base objects of roles of <code>Secondary</code> are contained within the team instance specified by the link <code>anchor</code>.
+ If roles of <code>Secondary</code> contain any callin bindings to non-static base methods, these will be triggered only
+ when a base method is invoked on a base instance contained in the team specified by <code>anchor</code>.
+ <br />
+ In accordance with <a href="#s2.6.a" title="§2.6.(a) Externalized roles of a base team"
+ class="sect">§2.6.(a)</a> the anchor in such anchored playedBy declarations
+ could also be the pseudo identifier <code>base</code>, provided that <code>Secondary</code> is a nested team,
+ which has a playedBy binding to <code>Primary</code> as its base class.
+ This situation is part of the second example <a href="#s2.7.d" title="§2.7.(d) Implicit playedBy specialization"
+ class="sect">below (§2.7.(d))</a> (see <code>T1 playedBy TB1</code>).
+
+ </p>
+ </div>
+ <div class="newpage"></div>
+ <div class="subsect depth3" id="s2.7.d">
+ <h4 class="subsect">(d) <span class="title">Implicit playedBy specialization</span><a class="img" href="s2.html#s2.7.d"
+ title="PermaLink to (d) Implicit playedBy specialization"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>According to <a href="#s2.1.d" title="§2.1.(d) No-variance" class="sect">§2.1.(d)</a> an implicit sub-role may <em>implicitly</em> specialize an existing <code>playedBy</code> relation.
+ This requires the base class to be specified relative to some implicit (<code>OuterTeam.this</code>) or explicit (<code>OuterTeam.base</code>) team anchor.
+ Specializing that team anchor automatically specializes the playedBy declaration, too.
+ This rule never requires any action from a programmer but only explains the interpretation of a playedBy declaration in
+ complex situations.
+
+ </p>
+ <h5>Two advanced examples demonstrating the above are:</h5>
+ <table border="0">
+ <colgroup span="1">
+ <col align="left" span="1" />
+ <col align="left" span="1" />
+ </colgroup>
+ <tr>
+ <td rowspan="1" colspan="1">
+ <ul>
+ <li>If a role <code>TOuter1.T.R</code> of a <strong>nested team </strong><code>TOuter1.T</code> is played by
+ another role of the outer enclosing team <code>TOuter1.B</code>, subclassing the outer team <code>TOuter1</code> to <code>TOuter2</code>
+ will produce a new role <code>TOuter2.T.R</code> which is automatically played by <code>TOuter2.B</code>,
+ an implicit sub class of the original base class <code>TOuter1.B</code>.
+ </li>
+ </ul>
+ </td>
+ <td rowspan="1" colspan="1"><img src="../images/implicitly_overriding_playedby.png"
+ alt="Implicitly overriding playedBy" /></td>
+ </tr>
+ <tr>
+ <td rowspan="1" colspan="1">
+ <ul>
+ <li>Consider the case where a <strong>nested </strong><code>T1</code> as a role of <code>TOuter</code> is <strong>stacked</strong>
+ on a base team <code>TB1</code>. Also, <code>T1</code> is a <strong>layered team</strong> over <code>TB1</code>
+ because its role <code>R</code> adapts role <code>TB1.B</code>.
+ <br />
+ In this situation the playedBy relation of role <code>TOuter.T1.R</code> is given by a base-anchored type <code>B<@T1.base></code>.
+ If furthermore <code>TOuter.T1</code> is subclassed to <code>TOuter.T2</code> which covariantly refines the inherited
+ playedBy declaration to <code>TB2</code>, then <code>TOuter.T2.R</code> will automatically refine the inherited playedBy relation
+ to <code>TB2.B</code> to follow the new interpretation of the <code>base</code> anchor.
+ </li>
+ </ul>
+ </td>
+ <td rowspan="1" colspan="1"><img src="../images/implicitly_overriding_playedby_base.png"
+ alt="Implicitly overriding playedBy base" /></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ </div>
+ <table class="nav">
+ <tr>
+ <td class="back"><a href="s1.html" rel="prev"><< §1 Teams and Roles</a></td>
+ <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
+ <td class="next"><a href="s3.html" rel="next">§3 Callout Binding >></a></td>
+ </tr>
+ </table>
+ </div>
+ <div id="footer">
+ <hr /><a class="w3c img" href="http://jigsaw.w3.org/css-validator/check/referer"
+ shape="rect"><img src="../images/valid-css2-blue.png" alt="Valid CSS!" height="31" width="88" /></a><a class="w3c img" href="http://validator.w3.org/check?uri=referer" shape="rect"><img src="../images/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31"
+ width="88" /></a><address>© Stephan Herrmann, Christine Hundt, Marco Mosconi</address>
+ OT/J version 1.3 — last modified: 2011-05-15
+ </div>
+ </body>
+</html>
\ No newline at end of file
diff --git a/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s3.html b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s3.html
new file mode 100644
index 0000000..d3c5b6f
--- /dev/null
+++ b/plugins/org.eclipse.objectteams.otdt.ui.help/guide/otjld/def/s3.html
@@ -0,0 +1,1040 @@
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+ <link rel="stylesheet" type="text/css" href="../css/ot.css" />
+ <link rel="stylesheet" type="text/css" href="../css/otjld.css" />
+ <title>OT/J Language Definition v1.3</title>
+ </head>
+ <body class="otdt">
+ <div id="content">
+ <table class="nav">
+ <tr>
+ <td class="back"><a id="top"></a><a href="s2.html" rel="prev"><< §2 Role Binding</a></td>
+ <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td>
+ <td class="next"><a href="s4.html" rel="next">§4 Callin Binding >></a></td>
+ </tr>
+ </table>
+ <div class="chapter" id="s3">
+ <div class="headl">
+ <div class="headr">
+ <h1>§3 Callout Binding</h1>
+ </div>
+ </div>
+ <div id="toc-box">
+ <ul class="toc-box">
+ <li><a href="s3.html">§3 Callout Binding</a></li>
+ <li><a href="#s3.1">§3.1 Callout method binding</a></li>
+ <li><a href="#s3.2">§3.2 Callout parameter mapping</a></li>
+ <li><a href="#s3.3">§3.3 Lifting and lowering</a></li>
+ <li><a href="#s3.4">§3.4 Overriding access restrictions</a></li>
+ <li><a href="#s3.5">§3.5 Callout to field</a></li>
+ </ul>
+ </div>
+ <div class="intro">
+ <h3>Notion of callout binding</h3>
+ <div class="line"></div>
+ <div class="term">callout binding</div>
+ <div class="termdesc">A callout binding declares that a method call to a role
+ object may be <strong>forwarded</strong> to a base method of the associated
+ base object <em>(the role object "calls out" to the base)</em>.
+ </div>
+ <div class="line"></div>
+ <div class="term">declarative completeness</div>
+ <div class="termdesc"> Even if a role class does not implement all needed methods,
+ but forwards some to its base, also these methods must be declared
+ within the role.
+ Secondly, no forwarding occurs, unless explicitly declared by a callout binding.
+ </div>
+ <div class="line"></div>
+ <div class="term">expected/provided</div>
+ <div class="termdesc"> A callout binding binds an <strong>expected</strong> method of the role
+ class (needed but not implemented here) to a <strong>provided</strong>
+ method of the base class.
+ </div>
+ <div class="line"></div>
+ </div>
+ <div class="sect depth2" id="s3.1">
+ <h2 class="sect">§3.1 Callout method binding<a class="img" href="s3.html#s3.1"
+ title="PermaLink to §3.1 Callout method binding"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a><span class="toplink"><a href="#top">↑ §3</a></span></h2>
+ <div class="syntaxlink"><a href="sA.html#sA.3.2" title="§A.3.2 CalloutBinding"
+ class="syntax">→ Syntax §A.3.2</a></div>
+ <p>A role class may acquire the implementation for any of its
+ (expected) methods by declaring a <strong>callout</strong> binding.
+
+ </p>
+ <div class="subsect depth3" id="s3.1.a">
+ <h4 class="subsect">(a) <span class="title">Prerequisite: Class binding</span><a class="img" href="s3.html#s3.1.a"
+ title="PermaLink to (a) Prerequisite: Class binding"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A callout binding requires the enclosing class to be a role class
+ bound to a base class according to <a href="s2.html#s2.1" title="§2.1 playedBy relation" class="sect">§2.1</a>. However, callout bindings are not
+ allowed if the role is involved in base class circularity (see <a href="s2.html#s2.1.2.b" title="§2.1.2.(b) Cycles" class="sect">§2.1.2.(b)</a>).
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.b">
+ <h4 class="subsect">(b) <span class="title">Definition</span><a class="img" href="s3.html#s3.1.b" title="PermaLink to (b) Definition"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A callout binding maps an abstract role method ("expected method")
+ to a concrete base method ("provided method").
+ It may appear within the role class at any place where feature
+ declarations are allowed. It is denoted by
+
+ </p>
+ <div class="listing plain"><pre><i>expected_method_designator</i> <b>-></b> <i>provided_method_designator;</i></pre></div>
+ <p>The effect is that any call to the role method will be forwarded to the
+ associated base object using the provided base method.
+
+ </p>
+ <h5 class="listing">Example code (Callout):</h5>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><b>team</b> <b>class</b> Company {</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">2</td>
+ <td><pre> <b>public</b> <b>class</b> Employee <b>playedBy</b> Person {</pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">3</td>
+ <td><pre> <b>abstract</b> String getIdentification();</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">4</td>
+ <td><pre> <span class="comment">// callout binding see below...</span></pre></td>
+ </tr>
+ <tr class="line odd">
+ <td class="ln">5</td>
+ <td><pre> }</pre></td>
+ </tr>
+ <tr class="line even">
+ <td class="ln">6</td>
+ <td><pre>}</pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <div class="subsect depth3" id="s3.1.c">
+ <h4 class="subsect">(c) <span class="title">Kinds of method designators</span><a class="img" href="s3.html#s3.1.c"
+ title="PermaLink to (c) Kinds of method designators"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>A method designator may either be a method name
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">4</td>
+ <td><pre>getIdentification <em>-></em> getName;</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p><strong>or</strong>
+ a complete method signature including parameter declarations and
+ return type declaration, but excluding any modifiers and declared exceptions.
+
+ </p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">4</td>
+ <td><pre>String getIdentification() <em>-></em> String getName();</pre></td>
+ </tr>
+ </table>
+ </div>
+ <div class="codecomment">
+ <h5>Effects:</h5>
+ <ul>
+ <li> Line 4 declares a callout binding for the role method <code>getIdentification()</code>,
+ providing an implementation for the abstract method defined in line 3.
+ </li>
+ <li> In combination with the role binding in line 2 this has the following effect:</li>
+ <li> Any call to <code>Employee.getIdentification</code>
+ is forwarded to the method <code>Person.getName</code>.
+ </li>
+ </ul>
+ </div>
+ <p>Both sides of a callout binding must use the same kind of
+ designators, i.e., designators with and without signature may not be mixed.
+ <br />
+ Each method designator must uniquely select one method.
+ If a method designator contains a signature this signature must match exactly with the signature
+ of an existing method, i.e., no implicit conversions are applied for this matching.
+ If overloading is involved, signatures <em>must</em> be used to disambiguate.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.d">
+ <h4 class="subsect">(d) <span class="title">Inheritance of role method declarations</span><a class="img" href="s3.html#s3.1.d"
+ title="PermaLink to (d) Inheritance of role method declarations"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>The role method being bound by a callout may be declared in the same
+ class as the binding or it may be inherited from a super class or
+ super interface.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.e">
+ <h4 class="subsect">(e) <span class="title">Callout override</span><a class="img" href="s3.html#s3.1.e"
+ title="PermaLink to (e) Callout override"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>If an inherited role method is concrete, callout binding regarding this
+ method must use the token "<code>=></code>" instead of "<code>-></code>"
+ in order to declare that this binding overrides an existing implementation.
+ <br />
+
+ Using the "<code>=></code>" operator for an abstract method is an error.
+ <br />
+ It is also an error (and not useful anyway) to callout-bind a method that is
+ implemented in the same class as the binding.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.f">
+ <h4 class="subsect">(f) <span class="title">Inheritance of callout bindings</span><a class="img" href="s3.html#s3.1.f"
+ title="PermaLink to (f) Inheritance of callout bindings"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p> Callout bindings are inherited along explicit and implicit inheritance.
+ Inherited callout bindings can be overridden using "<code>=></code>".
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.g">
+ <h4 class="subsect">(g) <span class="title">Duplicate bindings</span><a class="img" href="s3.html#s3.1.g"
+ title="PermaLink to (g) Duplicate bindings"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>It is an error if a role class has multiple callout bindings for the
+ same role method.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.h">
+ <h4 class="subsect">(h) <span class="title">Declared exceptions</span><a class="img" href="s3.html#s3.1.h"
+ title="PermaLink to (h) Declared exceptions"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>It is an error if a base method to be bound by <strong>callout</strong>
+ declares in its <code>throws</code> clause any exceptions that
+ are not declared by the corresponding role method.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.i">
+ <h4 class="subsect">(i) <span class="title">Shorthand definition</span><a class="img" href="s3.html#s3.1.i"
+ title="PermaLink to (i) Shorthand definition"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p> A callout binding whose method designators specify
+ full method signatures does not require an existing role method.
+ If no role method is found matching the expected method of
+ such a callout binding, a new method is implicitly generated.
+ The new method is static iff the bound base method is static,
+ and it declares the same exceptions as the bound base method.
+
+ </p>
+ <p>
+ A shorthand callout may optionally declare a <strong>visibility modifier</strong>,
+ otherwise the generated method inherits the visibility modifier of the bound base method.
+ No further modifiers are set.
+ If a callout overrides an inherited method or callout,
+ it must not reduce the visibility of the inherited method/callout.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.j">
+ <h4 class="subsect">(j) <span class="title">Inferred callout</span><a class="img" href="s3.html#s3.1.j"
+ title="PermaLink to (j) Inferred callout"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p> If a non-abstract role class inherits an abstract method the compiler
+ tries to infer a callout binding for implementing the abstract method.
+ Similarly, if a self-call in a role class cannot be resolved, the compiler
+ tries to infer a callout to resolve the self-call.<br />
+ Inference searches for a method in the bound base class such that
+
+ </p>
+ <ol>
+ <li>both methods have the same name</li>
+ <li>both methods have the same number of arguments</li>
+ <li>each argument of the abstract role method is compatible to the
+ corresponding argument of the base method directly, or using
+ boxing/unboxing or lowering.
+ </li>
+ </ol>
+ <p>
+ Callouts inferred from an interface have <code>public</code> visibility,
+ callouts inferred from a self-call have <code>private</code> visibility.
+
+ </p>
+ <p>
+ Per default inferred callout bindings are disabled, i.e., a compiler
+ must report these as an error. However, a compiler should allow to
+ configure reporting to produce a warning only (which can be suppressed
+ using a <code>@SuppressWarnings("inferredcallout")</code> annotation),
+ or to completely ignore the diagnostic.
+
+ </p>
+ </div>
+ <div class="subsect depth3" id="s3.1.k">
+ <h4 class="subsect">(k) <span class="title">Callout to generic method</span><a class="img" href="s3.html#s3.1.k"
+ title="PermaLink to (k) Callout to generic method"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
+ alt="" /></a></h4>
+ <p>When referring to a generic base method</p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">1</td>
+ <td><pre><T> T bm(T a)</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>a callout binding may either propagate the method's genericity as in</p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">2</td>
+ <td><pre><T> T rm(T a) <b>-></b> T bm(T a);</pre></td>
+ </tr>
+ </table>
+ </div>
+ <p>or it may supply a valid substitution for the type parameter as in</p>
+ <div class="listing example frame">
+ <table class="listing">
+ <tr class="line odd">
+ <td class="ln">2</td>
+ <td><pre>String rm(String a) <b>-></b> String bm(String a);</pre></td>
+ </tr>
+ </table>
+ </div>
+ </div>
+ <p>A callout binding either attaches an implementation to a previously declared method
+ or adds (<a href="#s3.1.i" title="§3.1.(i) Shorthand definition" class="sect">§3.1.(i)</a> above) a forwarding method to a role class.
+ Apart from this implementation, callout-bound methods do not differ from regular methods.
+
+ </p>
+ <p>When we say, a callout binding defines <strong>forwarding</strong> this means that
+ control is passed to the base object. In contrast, by a <strong>delegation</strong>
+ semantics control <em>would</em> remain at the role object, such that self-calls
+ would again be dispatched starting at the role. Callout bindings on
+ their own do not support delegation. However, in conjunction with method
+ overriding by means of callin bindings (see <a href="s4.html" title="§4 Callin Binding" class="sect">§4</a>)
+ the effect of delegation can easily be achieved.
+
+ </p>
+ </div>
+ <div class="sect depth2" id="s3.2">
+ <h2 class="sect">§3.2 Callout parameter mapping<a class="img" href="s3.html#s3.2"
+ title="PermaLink to §3.2 Callout parameter mapping"><img style="vertical-align:text-top;margin-left:5px;" src="../im