Call Hiearchy Extensions
The Call Hierarchy now supports more control flows:
During debugging it now possible to switch the filtering of variables that have been generated by the OT/J compiler or the Object Teams Runtime Environment.
The debug view has been improved for presenting call stacks with aspect dispatch code in a more useful way
The Team Monitor, which was missing from the 1.1.0 release has been resurrected and enhanced. Using the Team Monitor you can easily check the activation state of all team instances of an OT/J program running in the debugger.
Filter applicable types
The Extension Editor of the PDE has a Browse button for each field representing a class. The selection dialog opened by this button now filters available types using the information from the extension point schema. If, e.g., the extension being created is an
Selecting the binding kind
When a method binding is created using completion, the different binding kinds are now offered as options.
When creating a method binding ( callin or callout) via completion (Ctrl-space), the role method signature can be adjusted to replace base types by corresponding role types. If the role type is chosen, compatibility will still be guaranteed due to translation polymorphism (lifting/lowering), since only compatible roles are offered by the completion:
More locations support completion
Completion is now also available within
Various new Quickfixes
The OTDT offers various new quickfixes (Ctrl-1):
The reflective method
When a role tries to directly access a base feature (method or field) for which no callout binding has been defined, the missing callout binding can be inferred by the compiler. Similarly an attempted field access can internally be re-mapped to a call to the corresponding (inferred) callout.
The compiler can be configured to treat inferred callouts as an error, or to issue a warning or to silently accept (ignore).
Quickfixes exist to materialize the callouts, i.e. for migrating from inference to explicit declarations.
Improved keyword scoping
The control over when
Here the first occurrence of
OT/Equinox integrates its byte code transformer in a much more robust way now.
Despite decapsulation, even an aspect plug-in can normally access only those classes of its base plug-in, that are exported from that plug-in. If access to a non-exported class is indeed needed, the required export can be forced upon the base plug-in. The steps required for accessing a class using forced export are (see also this detailed description):
A new launch type "OT/Equinox Application" has been added for running OT/Equinox bundles without an Eclipse runtime workbench.
OT/Equinox also supports teams adapting classes from their own enclosing plug-in (bundle). This is achieved by declaring an aspect binding in the
<aspectBinding> <basePlugin id="SELF" /> <team class="my.pack.age.MyTeam" activation="ALL_THREADS" /> </aspectBinding>
OT/J programs can now be executed on more virtual machines. While conceptually any virtual machine should be able to execute OT/J programs, experimenting with other VMs revealed a few situations where the Sun's JVM accepts byte code that other VMs consider illegal.
Currently, the following virtual machines have been tested: