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

Good point...

Pointcuts are indeed not restricted by Java's access rules in what
they see.  Otherwise, pointcuts would pick out code inconsistently
(not based on their specifications) and some crosscutting behavior
which was intended to be advised would not be.  [Gregor I'm
sure has a better way of saying this.]

Java's access rules still apply to code (including code in
the if() PCD and in other code-things in the aspect, like
methods, initializers, constructors...), unless the aspect
is declared privileged.

Since advice can affect and skip private methods, which
most programmers consider as effectively final, it's not
clear that affecting final classes is any worse.
I personally found it a bit more surprising.


mmonteiro@xxxxxxxxxxxxxxxxx wrote:
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() {
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();
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 -

Miguel J. T. Pessoa Monteiro
Ph.D. student Minho University,Portugal
eMail: mmonteiro@xxxxxxxxxxxx
aspectj-users mailing list