Views & Dialogs | |
Lifting in call hierarchy |
Previously, the call hierarchy for a role constructor was incomplete because roles can be constructed on-demand by lifting. To visualize this implicit behavior the call hierarchy has been extended to consider occurrences of lifting as invocations of the role's lifting constructor. Here the call hierarchy was opened for the role type |
Content assist | |
Add signatures to method binding |
The existing quick assist "Add signatures to method binding" has been improved so that it can be used on a a signature-less method binding even if it fails to resolve its base method(s). In case the base class has more than one method of the name mentioned in the method binding, all matching base methods are collected, the best match is inserted into the editor and other matches are offered as alternatives in linked mode. So, if before invoking the assist you have: you may invoke the assist as a quickfix (e.g., from the error hover), producing this change: where you may select the suitable base method from a list. Hint: If a method binding has an incorrect signature you may first remove signatures (using a quick assist) and then let this new assist insert correct signatures. |
Implement abstract methods from implicit super role |
The existing quick assist "Add unimplemented methods" has been extended to apply also to those abstract methods that are implicitly inherited from the corresponding role in the super team. The error against the role class now provides the quick fix: Invoking the quick fix (e.g., from the error hover) produces this change: |
Improved handling of base imports |
So-called "base imports" are used in OT/J to distinguish those classes that are imported only as a base class of a role in the current team, disallowing direct use within the implementation of the team and its roles (see OTJLD §2.1.2(d)). The umbrella bug 356003 lists several individual improvements to make content assist, wizards, and refactoring better aware of the semantic rules of base imports. In all these situations the correct base import or regular imported is now created, and base imports are correctly updated if mandated by a refactoring. |
Formatting | |
Basic code formatting for OT/J |
In previous versions support for code formatting for OT/J was incomplete, and the occurrence of some
constructs like |
Language | |
Java 7 support |
Starting with 2.1 M1, OT/J has been integrated with Java 7, i.e., the OT/J compiler also supports all new features introduced in Java 7. |
@Override for static role methods |
Along implicit inheritence a role can override even a static method from its implicit super role.
This overriding can now be documented using an
|
Base class as method return |
Mentioning a base imported class in the body of a team or role is not allowed. However, a team method may want to return a role which then should be lowered on the way. Previously, this lowering was not possible, because the base type could not be mentioned (by its simple name). For the specific situation of team method return types this restriction has been removed.
|
Run / Debug | |
Simplified launching with OT/Equinox |
OT/Equinox is implemented using a fragment that acts as a framework extension for Equinox.
So far this required that the OT/Equinox bundles be located in the same place were also the
This restriction has been removed, i.e., the OT/Equinox bundles may be resolved from the workspace while
|
Previously, when debugging an OT/J or OT/Equinox application, changes made to the source code of the running application could not be applied on the fly, because the JVM would detect signature mismatches. This was caused by the fact that during hot code replacement the Object Teams bytecode transformer was not used. This has been fixed by enabling the Object Teams transformer to re-weave already loaded classes. Additionally, for OT/Equinox debug launches a new Java agent has been developed to trigger weaving also for hot code replacement (which is not supported by the underlying adaptor hooks in Equinox). This agent is automatically added to the Java command line for all OT/Equinox debug launches. As the result it is now possible to directly see the effect of source code changes even in woven classes without restarting the application. Note, that hot code replacement is limited by the JVM to changes that do not affect any signatures. |
|
Compiler | |
Report multiple callins |
When two independent callin bindings affect the same base method this might give rise to unanticipated behavior. Therefor a new warning is reported to alert the user of this situation: As mentioned in the warning message, this diagnostic is recomputed only during full builds, because this computation requires a whole system analysis. Use the callin marker in the left ruler to navigate to the potentially conflicting callin bindings for inspection (sorry for the clutter between the callin marker and the warning marker): |
Object Teams Runtime Environment | |
Memory optimization |
Memory consumption of the OTRE could be reduced significantly. A given class from BCEL was retaining the full structure for loaded classes, which could be reduced to a much more compact format. Measurements showed a reduction of this data structure to approx. 1% of the original size. |
Performance optimization |
An internal data structure woven into each base class was initialized eagerly causing a performance penalty. This eager initialization could be removed completely, lazy initialization was already implemented. For situations where lots of base objects were created for which no role was ever created this results in a speedup of up-to 3.5 (from a micro benchmark). |
Release Engineering | |
Source bundles |
We now ship an additional (optional) feature, |