OTDT 2.3 - New and Noteworthy

Language

Adopt Java 8

384991

OT/J has been fully integrated with Java™ 8.
This means that lambda expressions, method references, default methods, type annotations etc. can all be used in OT/J programs. Additionally, roles in OT/J can bind to Java 8 classes containing any of these new features.

Grammar challenge

Syntactically, some of the new features in Java 8 look surprisingly similar to OT/J:

The arrow "->" used for lambda expressions is the same token that OT/J uses for callout bindings and role-to-base parameter mappings (see also 4.4).
The "@" token used for type annotations (JSR 308) is the same that OT/J uses to denote a team anchor

Clean integration

Despite these syntactic similarities, it was not necessary to change OT/J in order to harmonize with the syntax of Java 8. So with the minimal, inevitable restrictions ("team" and "within" are unconditional keywords in OT/J) every legal Java 8 program is also a legal OT/J program. Conversely, every legal OT/J program from earlier versions, is still a legal OT/J program.

Feature interaction

For the most part, the new features in Java 8 can be regarded as orthogonal to features introduced by OT/J:

Lambda expressions in Java 8 are about the details of implementing algorithms
Type annotations in Java 8 are about improving the type system
Roles and Teams in OT/J are about composing individual objects into a system

With respect to type checking the following features required significant work behind the scenes to reconcile the various type rules: generics with enhanced type inference, type annotations and finally: role types, all contribute to a very rich notion of types. Given that type inference in the Eclipse Compiler for Java was completely re-written, adopting that re-write for OT/J required intimate knowledge about that implementation.

Inheritance now has more options due to the introduction of default methods. This poses a new challenge in combination with OT/J's implicit inheritance, some details of which may still require more work after the 2.3 release. Technically, OT/J now supports two different styles of multiple inheritance, but from the details it is clear that both concepts pursue entirely different goals. It is not expected that these concepts compete for solving any real world design task.

Object Teams Runtime Environment

New byte code weaver

398232

Starting with 2.3, OTDT ships with a new byte code weaver as an alternative to the traditional OTRE.

This weaver, called "Object Teams Dynamic Runtime Environment (OTDRE)" has been developed with the goal to support runtime weaving, i.e., to support the integration of roles and teams that are not known during application launch. This capability has been fully implemented, but infrastructure to fully leverage the new flexibility still needs to be developed (think, i.e., of a monitoring console that allows runtime deployment of new monitoring team classes).

The OTDRE is implemented using the byte code library ASM, as opposed to the BCEL-based implementation of the OTRE. ASM follows a more modern approach, which results in better weaving performance. ASM is also actively maintained, which, unfortunately, is no longer true of BCEL.

By using the latest version of ASM, the OTDRE is capable of processing class files even of Java 8, which is not possible using BCEL. Therefore, the OTDRE is shipped with the specific goal to support Java 8, although it has not yet reached exactly the maturity, which the OTRE has obtained over the years.

Both weavers are supported by the compiler, by generating specific infrastructure to be invoked from woven code. Due to the fundamental difference in weaving schemes, it is necessary to selected at compile time, which weaver should be targeted. Please see the section on target weaving schemes in the developers' guide.

OT/Equinox

Migrate to new Equinox implementation
since 2.3M2
406518

A mostly compatible re-implementation

The implementation of OT/Equinox has been re-written, which became necessary when Equinox withdrew an "inofficial API" called "Adapter Hooks", on which OT/Equinox had relied for many years.

At the surface this should hardly be visible to regular clients of the OT/Equinox technology; the existing extension point aspectBindings is supported unchanged.

The single surface change regards the way how visibility between a base class and an adapting team is established: In the new implementation each aspect bundle must export all packages containing one or more team classes. This is a hard requirement and missing exports will be flagged as an error. A new quick fix is provided to support this task.

Current limitations

A few add-on features of OT/Equinox are currently unimplemented and are planned to be re-added in Luna service releases:

Details

Previously, we had given advice that OT/Equinox can be disabled by removing a particular line from the file configuration/config.ini. This line no longer exists. Instead, OT/Equinox can now be disabled using the following Java property:

    -Dot.equinox=false

The new implementation also plays better with Equinox' lazy loading: previously, loading and activation of teams was triggered whenever the affected base bundle was activated. Given that team loading/activation could in turn trigger other bundles to be loaded/activated, a lot of loading activity could be observed right during system launch, which was not strictly necessary. The new implementation waits until actually an affected base class is accessed, which is the latest possible point for activating corresponding teams. As a result the impact on the loading sequence could be significantly reduced.

Portability

The new implementation no longer depends on "inofficial API", but relies on the OSGi standard WeavingHook. This way, the basic functionality of OT/Equinox should in fact work on other OSGi containers, as well. Of course, using extension points for declaring teams to be activated still depends on Equinox, but this is a well isolated concern and porting this to any other means for configuration should be straight-forward.

Visualization unchanged

As a (partial) proof of compatibility, the existing OT/Equinox Monitor view works on top of the new implementation without a single line of code changed.

In fact this view can be used to observe the non-impact of OT/Equinox in two regards:

Teams whose base classes have not yet been loaded will not be known / shown. To see the highlighted BrandingAdaptor, it is necessary to open an about dialog like Help > Installation Details > Plug-ins
Role instances adapting a base instance that has been garbage-collected are also removed from memory and hence no longer show in the monitor view (cf. the many zeros in the "# roles" column).

Quick fix to add aspect export
since 2.3M2
406518#c37

The new implementation of OT/Equinox requires to export all packages containing teams (see above). When this export is missing, an error is flagged against the plugin's manifest and a quick fix is offered for adding the required export in the recommended format.

Applying the quick fix produces this result:

The screenshot shows a package export with a recommended property ot-aspect-host, which marks the export as intended for the sole purpose of letting woven code call into the team. Additionally, the value of this property identifies the declaring aspect bundle, which is internally used to uniquely identify this package even in situations of split packages.

Finally, the export may use one of x-internal or x-friends for preventing unintended use of this package.

Once we re-implement the Forced Exports concept (see above), we may consider to remove the additional requirement to export all packages containing teams.