| Re: [stellation-res] Using AspectJ? |
On Fri, 2002-09-06 at 13:08, Dave Shields wrote: > 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. On the one hand, I do sort of agree with you. The Stellation core should be compilable from the command line. And it's definitely valuable for that to be efficient. But on the other hand, I think relying too much on a command-line based work environment is going to become more and more of a problem. Because so much of the code we'll be adding is going to be in the form of Eclipse plugins, which *can't* be compiled from the command line. And thus, when you want to change code in the core, and only compile it from the command line, there's no way for you to know if your change is breaking the rest of the system. If using Eclipse is going to become something close to obligatory, and Eclipse can do an ultra-fast incremental build of the mixed Java and AspectJ code, then I'm not sure that it's such a big deal that the command-line build slows by a few seconds to run the AspectJ preprocessing phase. > 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. First, I still regret the loss of GJ. I'd still be happy to take all of the negatives associated with it, if only it worked in Eclipse. I think our code has suffered, significantly, from the loss of a reasonable type system. Second, if we use AspectJ, the vast majority of our code remains standard Java. Using GJ meant translating all code into the GJ variant of Java. In AspectJ, most of the time, you write absolutely standard Java. Aspects are distinct constructs that integrate into the existing code. The output from the AspectJ compiler is human-readable standard Java. So if we try it, and it doesn't work out, backing out isn't a big deal. We just dump the aspects, and use the result of weaving the aspects into our source. > 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. This, I think, is a bit of a non-sequiter. I've made no argument that Java is unacceptable. I have said that I'm finding some of the stuff I'm writing messy and confusing, and using AspectJ might help make it less messy and confusing. Plain Java can clearly do everything that the code I'm writing needs to do. Further, there's a pretty deep difference between using a fairly widely accepted, Eclipse integrated tool that augments Java, and a totally distinct language with no relationship with Java at all. If any of those other languages were to reach the point where they had a fully supported Eclipse plugin, and could integrate perfectly with Java tools on all platforms, and could help make it easier to get Stellation working the way we want it to, I'd argue that it would be correct to consider them. > I also worry about raising the barrier of entry for new developers. This is my biggest concern, and I still think the strongest argument against AspectJ. I really do think that AspectJ is likely to make some of the code that we need to write easier to understand. But to understand it, you'll need to understand the basic ideas of AspectJ. -Mark -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center *** The Stellation project: Advanced SCM for Collaboration *** http://www.eclipse.org/stellation *** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part