Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-users] discussion on privilege (was: prob with interfaces in method's signature)

I bumped into a bug related to privileged aspects while I was trying to
extract a concern from a pure-Java framework. I would like to take the cue
from there and start a discussion on privileged aspects.

Until now, articles, books and the programming guide generally treated
privileged aspects as an necessary evil, not a desirable feature. I have
some doubts about whether that is the right way of seeing things in the long
run.

The fact that bugs related to privileged access were allowed to linger until
this stage of development leads me to guess, the same way Wes Isberg did,
that users do not make much use of privileged aspects. But that in turn also
leads me to guess that not much people is refactoring Java code into AspectJ
(or else they are keeping things to themselves).

Based on my limited experience, I feel that extracting concerns from a
non-trivial code base is a task that very soon leads to the need for access
privilege.

When we talk of access privilege the case that usually comes to mind is
access to a private member. It is important to keep in mind that access
pivilege is also needed for members with default and protected accesses that
are placed in other packages. Such "non-private, non-public" members are
meant to be seen and used by instances of others classes: it's just that
those classes are stored in the same package (tangled, that is), possibly
due to Java's limited compositional capabilities.

This way of doing things results from Java's access rules. When we start
using AspectJ those rules change in subtle ways, because we can separate
more.

Suppose a software team starts using AspectJ to refactor an existing
pure-Java framework, in order to extract tangled concerns into their own
aspects. Leaving aside some issues that could arise in mid-process, once
they are finished it would seem logical to place each concern (aspect) in
its own package (at least when the concerns are not related).

Now what would happen with the members which remain in the primary code,
have non-public access, and are needed by the aspects for their
quantifications? Just dumping them into the same package would simply result
in code tangling on a different level. If we reject such an option then
either the accesses of all relevant elements must change to public, or the
aspects would need to be privileged.

Wouldn't situations like these start to occur ever more often as the number
of AspectJ users increases? I would be very interested in feedback on this
from the AspectJ community.

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



Back to the top