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.
Difference between revisions of "OTVersions/Migrating to Luna"
(→OT/J and Java 8) |
(→Object Teams Dynamic Runtime Environment) |
||
Line 47: | Line 47: | ||
==Object Teams Dynamic Runtime Environment== | ==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). | ||
+ | |||
+ | {{Tip|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: | ||
+ | [[Image:SelectTargetWeavingScheme.png]] | ||
+ | |||
+ | The weaving scheme can be changed later by editing the following property in file <code>.settings/org.eclipse.jdt.core.prefs</code> (''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 [http://help.eclipse.org/luna/topic/org.eclipse.objectteams.otdt.doc/guide/weavingscheme.html|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. | ||
+ | ;No support for LiftingParticipants: Support for [[OTRE_Parameters|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. | ||
[[Category:Object Teams]] | [[Category:Object Teams]] |
Revision as of 11:49, 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)
Contents
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
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:
Manifest-Version: 1.0 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:
By applying the quick fix, the manifest is changed to:
If you don't want to expose the team package to other bundles, you may consider adding an x-internal
or x-friends
directive. If the package name contains a segment "internal", x-internal
will be added automatically by the quick fix.
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).
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:
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.