Kevin,
I agree with your sentiment and like your
ideas for static enforcement. It’s an interesting idea to allow declare
error or declare warning to use if statements based on statically resolvable
information, like thisJoinPointStaticPart. Conceptually that’s possible,
although I suspect adding that to AspectJ would be a project.
You *can*
enforce constraints on classes by using the staticinitalization pointcut, e.g.,
declare error: staticinitialization(Listener+)
&& !within(com.myco.app.listeners.*): “Listeners need to be
declared inside the listeners package”;
For “all listener methods must be
expressed in Listener interfaces”, I’m curious what qualifies as a
listener method. One missing feature from AspectJ that’s been in bugzilla
for a long time, is the ability to match whether a type is an interface (and the
like), so you can test for methods being declared on interfaces or returning
interfaces versus classes. For
- Listening to model X (also package X) may only
be coded in package Y by implementing interfaces from package Z
How about:
execution(* listen(Model m)) && within(com.pkg.Y..*)
&& !execution(com.pkg.Z..*(..)) && // see below
- unless it is coded as an
override of a method coded in a package outside my system that already
tangled its concerns
!execution(* !com.mysystem..*(..))
The only thing missing in this is the
notion of *interfaces* in package Z
– this just says it’s not a method that’s defined in package
Z. The important point that might be news is that execution(* Ifaze.foo(..)) will
match implementers of Ifaze’s foo method, and execution(* Super.bar(..)) will
match overridders of Super’s bar method.
I do think there’s room to add some
richness to AspectJ’s pointcuts that will facilitiate static enforcement and
dynamic combination. However, I also think that focusing on stability and
performance is still a higher priority than adding features. Just my $.02
(probably about 1 pence nowadays).
From:
aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Kevin F
Sent: Tuesday, February 27, 2007
5:57 AM
To: Matthew Webster;
aspectj-dev@xxxxxxxxxxx
Cc: aspectj-users@xxxxxxxxxxx
Subject: Re: AspectJ and
Encapsulation (was [aspectj-users] Q about"adviceexecution" and
"declare error")
Matthew,
I agree that Aspects do not break encapsulation which is why I’m in the
process of adopting them. Taking the larger view, encapsulation can only
happen with respect to something. In the OO paradigm, it attempts to be
absolute which causes the problem I mentioned previously: the only solution to
fixing some problems is for developers to manually break encapsulation by
modifying code throughout a system. In the AO paradigm, it recognizes this
w.r.t. nature and encourages developers to encapsulate concerns into aspects
but allows anything. It also recognizes that rarely do we get the design
right the first time so it allows privileged aspects to break the rigid OO
encapsulation model.
Since you moved this discussion to the dev thread, I would like to take the
opportunity to discuss some enforcements that I’ve been trying to
implement the last few days. The gaping weakness that I see in AJ is its
poor expressiveness w.r.t. static enforcement. While I think AOP should
allow developers to do what they want, I also think it is a terrific idea to
allow architects to design project-specific errors so that people know when
they are doing something wrong.
I’m trying to express simple statements like:
- All listener methods must be expressed in
Listener interfaces
- Listening to model X (also package X) may only
be coded in package Y by implementing interfaces from package Z
- unless it is coded as an
override of a method coded in a package outside my system that already
tangled its concerns
- Various other statements of class location
and the biggest problems I’m having are that:
- class declaration does not create a join point
- thisJoinPartStaticPart cannot be used in error
declarations (I’m just now about to check to see if it will even
tell me the information I need to know in order to convert this to a
runtime exception)
In short, the ability to violate OO encapsulation is awesome; however,
it’s like a nuclear reaction, an uncontrolled bomb or a thoroughly
regulated power plant.
Does anyone else have experience trying to enforce these kinds of constraints?
Am I just trying to push AJ beyond its intended design so I should add
CheckStyle or some other piece of technology to my projects? I also see
that the S.C.O.P.E. AJ implementation based on ajc is much smarter about making
static choices. Is it possible to replace the standard AJ compiler
included in AJDT with this one? Since I’m newly adopting AJ to my
projects (and figure I’ll get enough pushback already), I prefer to deal
with the standard limitations if adopting the better compiler means losing all
the Eclipse support of AJDT.
From: Matthew Webster
<matthew_webster@xxxxxxxxxx>
Date: Tue, 27 Feb 2007 11:15:55
+0000
To: <aspectj-dev@xxxxxxxxxxx>
Cc: <aspectj-users@xxxxxxxxxxx>,
<aj@xxxxxxxxxxxxxxxxxxxxxxx>, <eric.bodden@xxxxxxxxxxxxxx>
Subject: AspectJ and Encapsulation
(was [aspectj-users] Q about "adviceexecution" and "declare
error")
Kevin,
I think this discussion also belongs on aspectj-dev.
You make a very good point. Most aspects have a well defined purpose and those
that "break encapsulation" (I don't think they do but that is a
separate conversation about semantics) do so for a reason. If a private
field/method needs to be accessed (and there are plenty of good use cases for
this) or a private method advised a conventional approach would require the
class author to add accessor or template methods. In a large system this will
involve several authors and many classes. Besides the obvious code maintenance
issue there is one of integrity. With the traditional approach, which
supposedly doesn't break encapsulation, any Tom, Dick and Harry can call the
new methods. With the AspectJ implementation only the aspect has access.
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM United Kingdom Limited
Hursley Park,
Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Kevin F
<aj@xxxxxxxxxxxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx 26/02/2007
16:13
Please respond to
aspectj-users@xxxxxxxxxxx
To
<aspectj-users@xxxxxxxxxxx>
cc
Subject
Re: [aspectj-users] Q about
"adviceexecution" and "declare error"
Hi Eric,
I don’t mean to butt in on your conversation and may have missed some of
the leading conversation; however, I believe the point is this: is it better to
implement certain things by making changes throughout the base implementation
or to violate encapsulation so that the single concern can be addressed in one
place? I know that I’ve had my share of weeks consulting on
different projects where I joined the project and was tasked to analysis
exactly the crosscutting concerns addressed by AspectJ through the use of elaborate
scripts and manual intervention. In my consulting (usually as the guy
called in to rescue a train wreck), it has been common place to a single change
in more than 100 files.
Any technology can be misused. I can use JNI to circumvent encapsulation,
but it doesn’t mean that JNI should be removed from Java.
Kevin
From: Eric
Bodden <eric.bodden@xxxxxxxxxxxxxx>
Reply-To: <aspectj-users@xxxxxxxxxxx>
Date: Mon, 26 Feb 2007 09:57:32
-0500
To: <aspectj-users@xxxxxxxxxxx>
Subject: Re: [aspectj-users] Q
about "adviceexecution" and "declare error"
Yes, it's exactly this view you mention which I meant. A proper component can
be deployed in whatever context. As long as this context adheres to the
component's component model, this component is known to work and moreover the
outside world can see nothing more but its interface. This is not true for a
program that is deployed in the context of a general AspectJ program. The
aspects can see and modify anything they like. A class/package/component has no
means of hiding implementation details and in fact a lot of aspects rely
extracting context information from directly inside those classes, which is
IMHO sometimes quite worrisome w.r.t. independent development of both, aspects
and base code.
Eric
On 2/26/07, Matthew Webster <
matthew_webster@xxxxxxxxxx <mailto:matthew_webster@xxxxxxxxxx> <mailto:matthew_webster@xxxxxxxxxx>
> wrote:
Eric,
>If you want to give static guarantees, it's just painful and that's
>what many people are worried about.
But you _can_ make static guarantees about the AspectJ program. What you seem
to be describing is the trouble with making such guarantees about a Java
program that is later deployed and executed as an AspectJ program. My comment
about reflection related to privileged aspects but again you can make static
guarantees unlike with reflection.
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM United Kingdom Limited
Hursley Park,
Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
"Eric Bodden" <eric.bodden@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx 22/02/2007 20:29
Please respond to
aspectj-users@xxxxxxxxxxx
To
aspectj-users@xxxxxxxxxxx
cc
Subject
Re: [aspectj-users] Q about "adviceexecution" and "declare
error"
On 2/22/07, Matthew Webster < matthew_webster@xxxxxxxxxx <mailto:matthew_webster@xxxxxxxxxx> <mailto:matthew_webster@xxxxxxxxxx>
> wrote:
>
> Eric,
>
> I was aware of the work on open modules but have not read the papers you
refer to. Perhaps I should. However I do not believe any new controls are
necessary because Java in conjunction with a runtime modularity framework like
OSGi already provides sufficient mechanisms. This is why I am working on AOSGi
(http://www.eclipse.org/equinox/incubator/aspects/). <http://www.eclipse.org/equinox/incubator/aspects/).>
Oh, sounds interesting. I will have a look at it.
>
> >I know whole research communities which believe that not being able to
> >guarantee any sort of encapsulation by far the largest problem
of
> >AspectJ.
> I not believe AspectJ breaks encapsulation any more than Java reflection.
Well, that might be true but a lot of people would say that reflection
is bad style for almost everything but a few distinct use cases, too.
If you want to give static guarantees, it's just painful and that's
what many people are worried about.
Eric
--
Eric Bodden
Sable Research Group
McGill University,
Montréal, Canada
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England
and Wales
with number 741598.
Registered office: PO Box 41,
North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx <mailto:aspectj-users@xxxxxxxxxxx> <mailto:aspectj-users@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/aspectj-users
--
Eric Bodden
Sable Research Group
McGill University,
Montréal, Canada
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England
and Wales
with number 741598.
Registered office: PO Box 41,
North Harbour, Portsmouth, Hampshire PO6 3AU