[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] Default implementations in aninterface causingcreation of extra methods in an interface
|
> 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.
Yes, exactly.
> You have non-AspectJ clients that use both the interface and your
implementation of it.
Well, not exactly. The clients just have to implement two interfaces
and make a couple of xml config files to make a plugin. A couple of
these plugins are built in, and I use the aspect to provide the above
mentioned things to their implementations.
The clients know only one helper class in addition to the two
interfaces needed to implement a plugin.
> 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.
Not a problem as I know that the veawing happens at compile time and
have taken this into account.
> 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.
I am aware of what Java interfaces are capable of. I just could not
understand why the compiler could not insert the field into the
implementing classes. Now I see the reason as it is apparent from the
example you provided - if the fields are declared w/ other visibility
than private, they are referrable from outside the aspect by all who use
the interface type. So, the general case has to be done the way it is
done now.
However, I'd argue that "private" is the most common visibility used
for fields in Java. With a private field, I do not see a reason why the
compiler could not insert the field into each of the implementing
classes and take this into account when veawing the advice / inserting
the default method implementations, as no-one outside the aspect
declaring the field can reference the field anyway. I know this would
make the compiler a bit more complex as we would have two ways that
fields declared in interfaces are handled (one for private fields, one
for fields w/ other visibility), but it would also make most interfaces
w/ field introductions non-aspectj client friendly.
Then again, I guess my reasoning above falls apart in the case where
another aspect that is privileged accesses the declared private field...
and as that aspect can be in another project, we can not ascertain at
compile time of the declaring aspect that no such references exist. So,
even private fields have to be considered visible outside the declaring
aspect. = /
> 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.
What are the other exceptions? Are these exceptions documented in a
single place in the documentation?
-Antti-
