Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "OTVersions/Migrating to Luna"

(OT/Equinox)
(Package exports)
Line 10: Line 10:
  
 
===Package exports===
 
===Package exports===
During weaving we insert calls from a bound base class to each Team having 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.
 
  
Any bundle defining any Team classes adapting base classes of a nother bundle must now ''export'' the package containing the Team. In this export the aspect bundle should identify itself in order to prevent "split-package" issues:
+
All packages containing one or more team classes &ndash; bound via an <code>aspectBinding</code> &ndash; '''must be exported from their declaring plugin'''. This is supported by a new [http://staging.eclipse.org/objectteams/pages/new_in_2.3.html#qfAddExport quick fix], that also adds a recommended property [http://staging.eclipse.org/objectteams/pages/new_in_2.3.html#ot-aspect-host ot-aspect-host].
  
Manifest-Version: 1.0
+
'''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.
Bundle-ManifestVersion: 2
+
Bundle-Name: MyAspectBundle
+
Bundle-SymbolicName: org.me.AspectBundle;singleton:=true
+
Bundle-Version: 1.0.0
+
Require-Bundle: org.eclipse.core.runtime,
+
  org.eclipse.objectteams.otequinox,
+
  org.me.BaseBundle;bundle-version="1.0.0"
+
Bundle-ActivationPolicy: lazy
+
Bundle-RequiredExecutionEnvironment: Java2SE-1.7
+
Export-Package: org.me.teams;ot-aspect-host="org.me.AspectBundle"
+
 
+
If this export is missing for a bound Team class, an error is flagged against MANIFEST.MF, for which the following quick fix is offered:
+
 
+
[[Image:QFAddAspectExport.png|center|500px]]
+
 
+
By applying the quick fix, the manifest is changed to:
+
 
+
[[Image:QFAddAspectExport1.png|center|500px]]
+
 
+
If you don't want to expose the team package to other bundles, you may consider adding an <code>x-internal</code> or <code>x-friends</code> directive. If the package name contains a segment "internal", <code>x-internal</code> will be added automatically by the quick fix.
+
  
 
===Current limitations===
 
===Current limitations===

Revision as of 12:14, 14 June 2014

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 aspectBindingmust 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:

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).

Idea.png
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: SelectTargetWeavingScheme.png

The weaving scheme can be changed later by editing the following property in file .settings/org.eclipse.jdt.core.prefs (please be aware that this requires a full build of all OT/J sources in your project):

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

See also the section on 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.
No support for LiftingParticipants
Support for lifting participants is still unimplemented in OTDRE.

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.

Back to the top