Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-users] Re: when final is not

More than advice on final methods, it permits advice on private methods. For instance, in the code below non-privileged aspect Peeping can delete the behaviour of the call to private method Capsule.hidden(int) and capture its argument:
----------------------------------------------------------
public class Capsule {
 private void hidden(int dummy) {
    System.out.println("I should be safe here...");
 }
 public void test() {
    hidden(17);
 }
}
public aspect Peeping {
 pointcut privateCalls(): call(private void *(..));
pointcut call2Hidden(int arg): privateCalls() && args(arg);
 void around(int arg): call2Hidden(arg) {
    System.out.println("No, you're not safe: (" + arg + ").");
 }
}
public class TestAccess {
 public static void main(String[] args) {
    Capsule capsule = new Capsule();
    capsule.test();
 }
}
---------------------------------------------------------- However, if I try to call Capsule.hidden(int) from within the Peeping's around() advive, I get error "The method hidden(int) from the type Capsule is not visible". Someone correct me if I'm wrong, but doesn't the privilege affect only the "pure-Java" parts of aspects (i.e. code inside advice)? It doesn't seem to have any effect on the semantics of pointcuts and other aspect-specific parts.
AspectJ permits you to add members to final classes and advise
various join points whose static shadows are in final classes
without specifying that the aspect is privileged. Do folks think:
a) this is ok as-is
i) but we should implement XLint messages for this b) this should only work for privileged aspects
c) this should only work when you have the source
code for the final classes
d) only non-public members {or some other subset} is ok
because users of them know about the aspect e) this should never work Consider also:
- We permit advice on field-set join points where the
field is final, and advice on the method-execution of
final methods.
- Respecting final means that the AOP programmer who is working
on system issues can't implement a system-wide concern that
might not have been forseeable on the part of the programmer
of the final class, and in any case is not the responsibility
of the final class.
- We'd like to be able to say things like, "AspectJ respects
Java's modularity unless you explicitly declare an aspect
privileged," in order to have a clean policy that address this
concern of newcomers.
- We can write an XLint message so people can decide for
themselves whether it is ignored, a warning, or an error.
Thanks -
Wes

Miguel J. T. Pessoa Monteiro
Ph.D. student Minho University,Portugal
eMail: mmonteiro@xxxxxxxxxxxx
URL:http://gec.di.uminho.pt/mpm/


Back to the top