[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Re: when final is not
|
Great.
Your and Bo Yi's comments tell the right story: AOP can't defer
entirely to the mechanisms that made it impossible to modularize
crosscutting code, but people who want to protect any of their
code, final or not, can sign and seal their jar files. It is a
relief to not have to defend private/final, etc. when we can't.
I must say it's not convincing (at least when I say it!) that aspects
don't "change" the classes (modulo implementation), and that one
has to take a system-wide perspective. One of the benefits of
OO is being able to adopt a per-client perspective -- to expressly
not have to adopt a system-wide perspective. When I code my hashtable
under the expectation that String is immutable, if a String changes
I don't particularly care if the JVM failed or some aspect joined
behavior to the class or my use of it. The semantics of String
are broken. The burden rests with whatever broke it to fix it.
So while I agree that in fact
> whether advice on a join point is
> reasonable depends critically on not just the properties of the join
point,
> but also the properties of the pointcut and the advice.
I'm not sure that means we should wait for a solution with that
kind of power. (Heck, const methods were too complex for Java.)
Without any, you have shifted the burden to AOP to be able to
analyze and show, at each join point, whether the behavior is
reasonable or not, without providing any way to do that or to
limit the possible risk.
I think that burden is too high, given the forseeable state of
language and tool support for this pervasive and detailed analysis,
to save the kinds of guarantees that people relied on with OO.
It creates an unnecessarily open question at the heart of the
benefit - modularity - that AOP offers.
Conversely, requiring that an aspect declare that it has the privilege
to advise join points in otherwise final code doesn't reduce the
power of AOP, it just increases explicitness and avoids unintended
behavior. If, or since, one should soon be able to pick out a class
based on its final attribute, one can get the current behavior by
making a declaration:
declare privileged : within(final *);
This would also give the developer of critical code a way to say that
the code should not be advised:
declare advised : !(within({tsig}) || call({msig}) || call({csig}));
Which could be overruled by an aspect with more precedence.
Both of these are a way for the aspects to expressly negotiate such
join points, to bring them to the attention of the person charged with
doing systemwide or per-join-point analysis, using whatever tools
and skills are available, as they evolve.
I'm not as worried about misuse as whether these forms would quickly
be superceded by the more powerful forms we'd all like to have, at a
cost in language churn. However, the more powerful forms will likely
be able to state this simpler thing, making possible upwards-binary
compatibility, if not also upwards-source compatibility.
Wes
Gregor Kiczales wrote:
I wish I had more time to write this now, but this will have to be short.
As such, its not as well written as it should be. Sorry!
I think there's an undercurrent of "seeing AspectJ as injecting code"
lurking in here, that's worth trying to tease out in thinking about this.
Its easy to get into this undercurrent, so its worth reminding ourselves
about it from time to time.
Here's some things I notice in your message that make think this:
As soon as you explicitly talk about shadows, you're in danger of talking
in terms of the implementation (code injection) rather than the semantics
(advising join points). It is of course possible to talk about shadows and
still be in semantic space, but it's a slippery slope.
Suggesting that the semantics should depend on whether source code is
available also sounds like it is introducing an implementation issue
into the semantics.
Also note that you're talking about advice as "affecting methods". But advice
doesn't affect methods, it advises join points. The whole game of well done AOP
is to be able to say
- these classes do what they do
- these aspects do what they do
- a SYSTEM with both the classes and aspects therefore has
this compound behavior
The aspects don't "change" the classes. They advise join points or introduce
methods, but that behavior belongs to the aspects -- even though it appears
when the classes are called (in a certain context).
Also remember, (as I've flamed before) that whether advice on a join point is
reasonable depends critically on not just the properties of the join point,
but also the properties of the pointcut and the advice. So we don't want to
get into a world where a simple final declaration walls off all advice. We're
going to have to wait for a more expressive solution to the much sought after
join point encapsulation issue.
Finally, I don't think we want to be able to say that "AspectJ respects Java's
modularity unless you explicitly declare an aspect privileged". The whole gambit
of AOP was that traditional modularity rules were too limiting. (That's what
made it hard, was to properly break existing rules.) Instead we want to say a
more complex thing, like "the code within advice and inter-class methods respects
Java's modularity unless you declare the aspect privileged". But there's no
way to say that introductions or pointcuts and advice respect Java's modularity,
because they don't.
-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx
[mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Wes Isberg
Sent: Wednesday, January 14, 2004 4:31 AM
To: aspectj-users@xxxxxxxxxxx
Subject: 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.
Wes
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() {
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/
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
