[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[aspectj-dev] AspectJ, Encapsulation and Open Modules (was [aspectj-users] Q about "adviceexecution" and "declare error)"
|
Eric,
I have moved this interesting conversation
to aspectj-dev where I think it belongs.
Your argument seems to make two assumptions:
1. There are 2 types of people: those
that write nice Java applications that they want to protect and those that
write (potentially nasty) aspects that currently can do anything but shouldn't
(I am exaggerating a little here to make my point). The reality is that
application programmers will write their own aspects, that may legitimately
be tightly coupled, and they will use library aspects either in abstract
form, in which case they have control (to use or not to use), or in concrete
form, in which case a common contract (see below) must be used.
2. Good programming practice i.e. not
writing fragile aspects can be encouraged or even determined by controls
rather than facilitated by models and use cases. The solution offered by
open modules assumes someone understands how to write a good aspect and
can express it in the form of a module definition. In which case you might
as well just write a good aspect.
Deploying a component into a system
with pre-written concrete aspects is just not going to work in practice
_unless_ the pointcuts and ITDs concerned are written to some common, public
contract. By this I mean interfaces types or annotations. Therefore by
definition these aspects are not fragile. Where problems can start to arise
with an open module approach is where this contract is implemented in an
internal class. Now unless the application author anticipates this situation
and creates the correct definition (unlikely) then a system designed to
protect against fragile aspects will cause legitimate use cases to fail.
This is because AspectJ will fail to match hidden join points.
A more likely scenario involves abstract
aspect libraries. These must also be written before the target application
and so can only be expressed in terms of common types. Also the application
programmer writes the concrete aspect.
This just leaves the rogue aspects.
If they can use the name of a friend or the open module definition can
be modified then we are back to square one.
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
26/02/2007 14:57
|
Please respond to
aspectj-users@xxxxxxxxxxx |
|
|
To
| aspectj-users@xxxxxxxxxxx
|
|
cc
|
|
|
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> 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)
On 2/22/07, Matthew Webster <
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/).
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
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
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
