Views | |||||||||||||||||||||||||||||||||||||||||
Call Hiearchy Extensions
since 1.1.4 |
The Call Hierarchy now supports more control flows:
| ||||||||||||||||||||||||||||||||||||||||
Filter generated variables
since 1.2.0 |
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
| |||||||||||||||||||||||||||||||||||||||||
Team Monitor since 1.1.2 — since 1.1.6 |
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
since 1.1.7 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 | Content Assist | Selecting the binding kind When a method binding is created using completion, the different binding kinds are now offered as options. Lifting-aware completion 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): | Language |
| The reflective method Generic method bindings Method bindings now fully support the use of type parameters to reconcile
type safety with desirable flexibility. Inferred Callout 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 import base base.MyClass;
Here the first occurrence of base is recognized as a keyword, while the next word is interpreted as an identifier (the name of a package). | OT/Equinox |
| OT/Equinox integrates its byte code transformer in a much more robust way now. Forced Exports since 1.1.4 — since 1.1.5 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): Launch types A new launch type "OT/Equinox Application" has been added for running OT/Equinox bundles without an Eclipse runtime workbench. Self adaptation 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> | Supported Platforms | Virtual Machines since 1.1.4 — since 1.2.0 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: |