Adopt Java 8
Syntactically, some of the new features in Java 8 look surprisingly similar to OT/J:
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.
For the most part, the new features in Java 8 can be regarded as orthogonal to features introduced by OT/J:
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
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.
Migrate to new Equinox implementation
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
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.
A few add-on features of OT/Equinox are currently unimplemented and are planned to be re-added in Luna service releases:
Previously, we had given advice that OT/Equinox can be disabled by removing a particular line
from the file
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.
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.
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:
Quick fix to add aspect export
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
Finally, the export may use one of
Once we re-implement the Forced Exports concept (see above), we may consider to remove the additional requirement to export all packages containing teams.