RE: [aspectj-users] Default implementations in an interface causingcreat

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Antti,

I am assuming you have an interface, an aspect that adds default behaviour
to the interface and some advice to its implementers, and a class that
implements the interface. You have non-AspectJ clients that use both the
interface and your implementation of it.
1. The use of inter-type declared methods will be transparent to clients.
2. The use of advice will also be transparent however implementers of the
interface not woven with the aspect will obviously not be advised. This may
or may not be a problem.
3. The use of inter-type declared fields will not be transparent to clients
because interfaces in Java cannot define non-public final static fields.
The generated accessor methods are necessary so that the field can be
accessed using the interface type e.g.

public interface Interface {

      public void method ();
}

public aspect Aspect {

      public int Interface.intField = 999;

      public void Interface.method () {
            System.out.println("? Aspect.method()");
      }

      before (Interface i) : execution(void method()) && this(i) {
            System.err.println("intField=" + i.intField);   // No
downcasting required here
      }

}

Artifacts are sometimes generated as a result of the weaving process but
they are normally transparent. There are exceptions one of which is public
interfaces where the client is not an AspectJ program. It is generally
assumed that your whole application is compiled with AspectJ, if not care
must be taken at the boundaries. This restriction is not uncommon when
mixing programming models: we all remember mangled method names in C++ to
support overloading!

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/

"Antti Karanta" <antti.karanta@xxxxxxx>@eclipse.org on 05/04/2005 07:50:40

Please respond to aspectj-users@xxxxxxxxxxx

Sent by:    aspectj-users-bounces@xxxxxxxxxxx


To:    <aspectj-users@xxxxxxxxxxx>
cc:
Subject:    RE: [aspectj-users] Default implementations in an interface
       causingcreation of extra methods in an interface



> Also in your case you have adding an inter-type field. Again
> interfaces
> cannot declare non-final static fields so the field will
> actually belong to
> an implementing class.

  Ok. I thought the introduced variables & advice would be woven into
the actual implementing classes without any effect on the interface
itself. This would be much less intrusive as it doesn't really matter
that the classes have extra methods / members.
  Is there some particular reason why the interface is littered w/ the
new abstract methods instead of the necessary extra methods / fields
being directly introduced into the implementing classes? I guess it may
make the compiler a bit simpler to implement, but on the other hand it
forces the implementers of the interface to use AspectJ, too. This may
be too much to ask, as the implementers may be "outsiders" e.g. if your
application supports plug-ins that just have to implement one or more
interfaces. The end-users may know Java, but they can not (yet) be
expected to be "aspectj aware".


> Inter-type fields are always access through getter/setter methods.
Bottom line users of the interface
> will need to be compiled with ajc.

  In this case this may be a problem, so I guess I'll just have to strip
out the aspect and do the same things the old fashioned way (darn).


  Thanks for the reply.



     -Antti-



_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users