| Re: [stellation-res] Using AspectJ? |
On Fri, Sep 06, 2002 at 03:22:22PM +0000, Mark C. Chu-Carroll wrote:
> 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:
> > > So I'd like to know what people think about the idea of adding
> > > AspectJ to our suite of tools.
> > 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.
If that "should" is not a "must", I change my vote to -1.
The core stellation (the server + command line tool) must be compilable
from the command line. For the eclipse plugins, I don't have a strong
opinion as they requre eclipse by definition.
> 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.
Nope. Relying on buttons to do the work is a problem. A command line
tool you can invoke from cron to compile, run the tests over a server
farm and mail the results so you can digest them in the morning. Try doing
that with a GUI.
> 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.
I surely hope that does not include the fine-grained artifact
manipulation. If you rely on a running eclipse to do the parsing then
stellation is much less usefull.
> 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,
Eclipse has a long way to go to become something close to obligatory:
faster startup, vi keybindings, ability to have projects separated from
source and from binary, ability to just edit a file without engulfing it
in a project, ...
> and Eclipse can do an ultra-fast incremental build of the mixed Java
> and AspectJ code,
eating battery at 5 times the normal rate,
> 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.
[snip]
florin
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Attachment:
pgpxTIQWNvMwR.pgp
Description: PGP signature