Eclipse Community Forums: Objectteams » OT/Equinox changes for Eclipse Luna

Help

Home

Home » Language IDEs » Objectteams » OT/Equinox changes for Eclipse Luna

Show: Today's Messages :: Show Polls :: Message Navigator

OT/Equinox changes for Eclipse Luna [message #1074706]

Sat, 27 July 2013 14:22

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Hi folks,

this is a first heads-up about ongoing changes in OT/Equinox for the next annual release aka Eclipse Luna:

In my first build against a current integration build of the Eclipse SDK I noticed that our existing implementation of OT/Equinox is dead because of some recent changes in Equinox.

The good old "Adaptor Hooks" [1] are no longer supported in their existing shape. For OT/Equinox this is a breaking API change, although Tom rightly responds that the corresponding packages were marked as "x-internal".

For Object Teams this means we couldn't even build against the new osgi framework, unless we rewrite OT/Equinox against the new API org.osgi.framework.hooks.weaving.WeavingHook.

The move to the new hook - which is part of the OSGi standard - is of course a good thing that should eventually help also for compatibility with other weavers like AspectJ. So, I bit the bullet and took my draft implementation from earlier this year and right now I'm in the process of fleshing out a brand-new implementation of OT/Equinox. See the bug [2] for details and progress.

Ideally, this rewrite would be a purely internal change, but unfortunately, I won't be able to make these changes ina 100% backward compatible way.

Right now the following two changes seem necessary:

(1) all packages containing one or more teams to be woven into another bundle must be exported from their bundle

(2) binding a nested team will require using the binary name (using '$' as a separator for Outer$Inner), rather than the source name ('.'-separated).

For (2) the IDE should hopefully flag an error and maybe even provide a quick fix [3].

For (1) I'm in the process of investigating alternatives. I don't like the fact that we'd need to require redundant specification: for each team declared in an aspectBinding (via the extension point), we'd redundantly need an export of the team's package in the bundle manifest.

In a first experiment I'm using the following specification in the manifest:

Export-Package: org.eclipse.objectteams.otequinox.internal.branding;ot-aspect-host="org.eclipse.objectteams.otequinox.branding"

This declaration would say that the package o.e.o.o.i.branding is exported only as an aspect package, visible only for base-to-aspect calls from woven code, and the bundle-name in the ot-aspect-host attribute would disambiguate in case of split packages. Don't worry about the details at this point. One goal of these experiments is to find out whether we can fully migrate the declaration via the extension point "aspectBindings" towards declarations in the manifest, which would hopefully avoid the mentioned redundancy. But these are preliminary ponderings.

If this migration works out well, we'll have the benefit that OT/Equinox should have much lower coupling to Equinox, so one day it should actually run on other OSGi containers as well.

It seems that a few features will, however, never fully make this move. My idea is to provide these features with a "discouraged" warning, saying that these are again based on non-official "API" of Equinox, which is not portable and may break in the future. In this category I currently see these features:
- forced exports (no way to implement this in a 100% standards conform way)
- aspect bindings without package exports (I may actually be able to hack around the restriction mentioned above)

I can't yet say anything about migration from extension point to manifest headers,
so please stay tuned for updates.

best,
Stephan

[1] http://wiki.eclipse.org/Adaptor_Hooks
[2] https://bugs.eclipse.org/413856
[3] https://bugs.eclipse.org/406518

Report message to a moderator

Re: OT/Equinox changes for Eclipse Luna [message #1076183 is a reply to message #1074706]

Tue, 30 July 2013 22:25

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Update:

The first milestone has been reached:

Object Teams has been successfully built against the latest Luna I-build, which means: OT/Equinox is basically resurrected, i.e., alive and kicking. I'm already using the new implementation for my development environment.

Only one blocking bug in p2 [1] is holding me back from closing the main bug [2].

There's a bunch of details to be settled after M1, managed via [3].

[1] https://bugs.eclipse.org/253244
[2] https://bugs.eclipse.org/406518
[3] https://bugs.eclipse.org/414054

best,
Stephan

Report message to a moderator

Re: OT/Equinox changes for Eclipse Luna [message #1165074 is a reply to message #1076183]

Fri, 01 November 2013 03:43

Steve Mayer

Messages: 22
Registered: December 2012

Junior Member

Hello Stephan,

today I wanted to check the latest unstable version of Object Teams.

I tested the following example with the version:
/home/stephan/Downloads/eclipse4.4/eclipse/plugins/org.eclipse.objectteams.runtime_2.3.0.201309221451.jar

Is this the latest version of Object Teams running at the moment?

The below example is to check the constructor linarization or constructor call hirarchy in Object Teams.

The error is:
"No enclosing instance of the type TOuter.T1 is accessible in scope TOuter.java /object-teams-proj1/src/to line 19 Java Problem"

Or, perhaps is my code wrong?

package tb;
public team class TB1 {
	public class B { 
		
		public B() {
			System.out.println("TB1::B::B()");
		}
		
		
	}	
}

package tb;
public team class TB2 extends TB1 {
	@Override
	public class B { 
		
		public B() {
			System.out.println("TB2::B::B()");
		}
		
	}
}

package to;

import base tb.TB1;
import base tb.TB2;

public team class TOuter {
	public team class T1 playedBy TB1 {
		protected class R playedBy B<@base> { 
			
			public R() {
				base();
				System.out.println("TOuter::T1::R::R()");
			}
		}
	}
	public team class T2 extends T1  playedBy TB2 {
		protected class R playedBy B<@base> { 

                        //
                        //  this constructor causes the ERROR:
                        //
			public R() {
				base();
				System.out.println("TOuter::T2::R::R()");
			}
			
		}
	}
}

Stephan Herrmann wrote on Tue, 30 July 2013 18:25

Update:

The first milestone has been reached:

Object Teams has been successfully built against the latest Luna I-build, which means: OT/Equinox is basically resurrected, i.e., alive and kicking. I'm already using the new implementation for my development environment.

Only one blocking bug in p2 [1] is holding me back from closing the main bug [2].

There's a bunch of details to be settled after M1, managed via [3].

[1] https://bugs.eclipse.org/253244
[2] https://bugs.eclipse.org/406518
[3] https://bugs.eclipse.org/414054

best,
Stephan

[Updated on: Fri, 01 November 2013 03:44]

Report message to a moderator

Re: OT/Equinox changes for Eclipse Luna [message #1174302 is a reply to message #1165074]

Thu, 07 November 2013 03:01

Steve Mayer

Messages: 22
Registered: December 2012

Junior Member

It was just a typo! I faild to include the "tsuper()" call in "T2.R.R()". Now it works fine.

Stephan

package to;

import base tb.TB1;
import base tb.TB2;

public team class TOuter {
	public team class T1 playedBy TB1 {
		
		public T1() {
			base();
		}
		protected class R playedBy B<@base> { 
			
			public R() {
				base();
			}
			
		}
	}
	public team class T2 extends T1 playedBy TB2 {
		
		public T2() {
			base();
			
		}
		
		@Override
		protected class R  { 
			
			// tsuper() call in T2.R.R() was missing before
			public R() {
				tsuper();
			
			}
			

		}
		
		public R newR() { return new R(); }
	}
	
	public T2 newT2() { return new T2(); }
	
	
	public static void main(String[] args) {
		
		new TOuter().newT2().newR();
	}
}

Report message to a moderator