Re: [stellation-res] Using AspectJ?

[Dave Shields <shields@xxxxxxxxxxxxxx>]

On Thu, Sep 05, 2002 at 03:03:23PM +0000, Mark C. Chu-Carroll wrote:
...
> A question to the group:
> So I'd like to know what people think about the idea of adding
> AspectJ to our suite of tools.
> 
> Some things to know about it:
> - The AspectJ compiler is open-source, under the Mozilla license.
> - There is an AspectJ task for ant, so command line builds
>   will continue to work.
> - There is an AspectJ plugin for Eclipse, so it will not interfere
>   with our Eclipse use.
> - There should be no execution-time performance penalty for using
>   AspectJ.
> 
> The main arguments against it:
> - People will need to learn the basics of AspectJ to understand parts
>   of our code.
> - The setup process for working on Stellation becomes even more 
>   complicated, because you'll need to install AspectJ.
> - AspectJ *can* make things significantly less complex; but it also
>   has the effect of introducing additional "scatter" to the codebase. 
>   If it's not used with great care, it can create as many problems
>   as it solves.
> 
> What do you all think?
> 
> 	-Mark

I am wary of tools that require a change to the source so that is no longer
in standard Java. For example, our earlier experiment with gj, while producing
more readable code, had the following drawbacks:

1) Since we could no longer use Jikes, compilation time went up by a factor of 3-5.
I *really* enjoy being able to compile the full system in under five seconds
real time.

2) gj came with a very out-of-date version of Javadoc.

3) We faced potential problems using *any* tool that, like Javadoc, 
operated on the source, but only for source in standard Java. 
For example, JDE in Xemacs didn't work well with gj.

The argument for AspectJ boils down to

   Standard Java is unacceptable for part of our system, so we should use AspectJ.

If we accept this, then others may make a similar argument for using Perl, Python,
OCAML, or whatever, for some other part of the system.

I also worry about raising the barrier of entry for new developers.

This is not to say that we shouldn't use AspectJ, but I suggest we take a conservative
approach in estimating the costs added by creating a system no longer written in
standard Java.

dave

-- 
Dave Shields, IBM Research, shields@xxxxxxxxxxxxxx.