OTVersions/Migrating to Luna

The Luna development cycle introduced three changes of technology, that could potentially require actions from users:

• Migration to a new implementation of the Equinox framework underlying OT/Equinox
• Adoption of Java 8
• Optional migration to a new byte code weaver (OTDRE)

OT/Equinox

During a re-implementation of the underlying Equinox framework, the "Adaptor Hooks", previously used by OT/Equinox, have been withdrawn, requiring a re-implementation also of OT/Equinox. See bug 406518 for details.

Although efforts have been invested to make this change transparent for users a few inevitable changes occurred that may require action from users:

Package exports

All packages containing one or more team classes – bound via an aspectBinding – must be exported from their declaring plugin. This is supported by a new quick fix, that also adds a recommended property ot-aspect-host.

Background: During weaving we insert calls from a bound base class to each Team having a Role bound to the base class. This implies that the base class must be able to "see" (in the OSGi/ClassLoader sense) the Team class. Previously, this was handled on a per-class basis during custom classloading. In the new implementation we no longer change any class loading strategy (which makes us conform to plain OSGi actually), but in turn this requires a little help from users: the new package export mentioned above.

Current limitations

The following concepts are yet unimplemented in the Luna version of OT/Equinox (updated as of Luna SR2):

• Aspect permission checking bug 413859
• Forced exports bug 413862
• Lifting participants bug 437451
• Syntax for nested teams: Previously, an aspectBinding could specify a nested team using the source-level name like org.me.Outer.InnerTeam. In Luna, a '$' must be used as the separator of outer/inner classes: org.me.Outer$InnerTeam. This issue will be flagged as an error against plugin.xml and a quick fix is offered for its correction.

Positive side effects

Loading and activation of Teams happens more lazily now, i.e., only when a base class is loaded that is affected by any role bindings. Previously, loading and activation of Teams could lead to eager loading of transitively referenced bundles, thus causing longer start-up times of Eclipse. With the new scheme, Eclipse's lazy loading should be basically restored resulting in shorter start-up times.

OT/J and Java 8

The new features of Java 8 have been integrated into OT/J without imposing further restrictions on neither OT/J nor Java 8 (beyond the obvious prohibition of OT/J's unconditional keywords team and within as identifiers, see also OTJLD §A.0.1).

Object Teams Dynamic Runtime Environment

Starting with version 2.3.0, 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).

Hint on maturity
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.

Dependencies

The OTDRE is implemented using the byte code library ASM, as opposed to the BCEL-based implementation of the OTRE.

• OTDRE introduces a new dependency, it requires ASM 5.0.1

Java 8 compatibility

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.

Byte code formats

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 not possible to mix both weaving schemes in an application. Hence, it is necessary to select at compile time, which weaver should be targeted.

Initially, the weaving scheme is selected during project creation:

If needed, the weaving scheme can be changed later by editing one line in the jdt preferences (please be aware that this requires a full build of all OT/J sources in your project):

.settings/org.eclipse.jdt.core.prefs

 org.eclipse.objectteams.otdt.compiler.option.weaving_scheme=OTDRE

See also the section on target weaving schemes in the developers' guide.

Limitations

While we're working on making both weavers compatible to the degree possible, the following incompatibilities exist at the point of this writing:

No discrimination of static method invocations

The second item in http://www.objectteams.org/def/1.3/s4.html#s4.7.e doesn't play well with the OTDRE strategy, because this requires to insert a new method into the sub case class. The OTDRE strategy avoids such additions, and hence cannot implement these semantics.

Support for LiftingParticipants

The Luna version of OTDRE does not support lifting participants, this has been resolved for Mars, though.

Positive effects

OTRE has difficulties with loading order of classes, which in rare situations could cause a base class to escape the required weaving (this is not an issue in OT/Equinox environments). OTDRE in general does not have this problem, since a base class can be re-woven when a bound role is detected after the base class was already loaded.