Views & Dialogs | |
Traditional Hierarchy View |
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.
A new adaptation of the internal E.g., consider the following code:
which yields the following rendering: |
Content assist | |
Adjust callin return |
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. In order to avoid confusing the user, method binding completion now works with the following changes:
|
Refactoring | |
Change Signature Refacoring |
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.
Here is a preview of a refactoring, where the signature of |
Run / Debug | |
Stack frame beautifying |
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. The shaded stackframes in the above screenshot signify (from top to bottom):
|
API | |
isActive() is now final |
Previously, methods In order to avoid this risk of deadlocks, both methods have been changed to |
Language | |
Internal State Pattern |
Previously, OTJLD (v1.2) §2.1.2(b) 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:
MyTeam - thus providing a very well
localized implementation for different states/modes of the team.
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 See also the Internal State Pattern in the wiki. |
Compiler | |
playedBy Interface |
The OTJLD never said that the type after |
Object Teams Runtime Environment | |
Packaged as a bundle |
Packaging and deployment of the OTRE has changed from a plain Jar to a regular OSGi bundle called |