[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] AspectJ Production suitability

Hi Wes

Thanks for your thorough answer, which addressed their concerns well :)


Wes wrote:
Hi -

Before they commit to using AspectJ they have some concerns that I hope 
some of you can help me address with facts.
is there an official AspectJ writing you can point me to where 
this issue is addressed?

(1) the second line of the web site, "AspectJ is ... Java platform compatible"
(2) the third faq entry, "3. Can AspectJ work with any Java program?"
(3) the "compatibility" section of the development environment guide,
    esp. the part on Java compatibility:

Java compatibility has been a requirement for AspectJ since it was 
released to the public 5+ years ago.  Further, many AspectJ users deploy
on non-Sun VM, and the team has/had ibm and bea members.

- Do you know of any large financial applications in production that 
uses AspectJ weaved code?

I understand that it is helpful for managers to know that those with similar
risk profiles have evaluated and adopted AspectJ, but neither size nor 
domain really make a difference.  The question is whether a .class is 
correct, any runtime overhead is negligible, and writing the class
is easy.  

Part of incremental adoption is understanding which risks come from which 
parts of AspectJ/AJDT are mature and which practices are well-understood,
so at the risk of boring most readers who likely know all this, I'll 
break it down a bit.

The runtime overhead is minimal in most situations, linear, detectable
and predictable.

We think the bytecode is correct for a number of reasons: 

(1) partly by construction: 
  (a) for compilation, we're building on the eclipse JDT compiler which
      is well-tested and well-regarded;
  (b) for weaving, we're building on a bytecode toolkit that does the
      right thing (and is used by other projects).  We tend to be the
      most correct users, correcting the toolkit as needed.

(2) partly by test: our suite is large and, I think, good.  But it has
evolved largely by (a) testing new features and (b) regressing bugs;
there's never been a ton of money put to making it comprehensive.

(3) partly by feedback: we have had a large number of users for years,
many working in the enterprise space at top-tier companies.

So to manage any adoption risk you should understand the differences 
between different parts of the AspectJ technologies in terms of their age, 
user community, and technical underpinnings, considering the kind of 
risks you face.

One risk is unusable software.  If the interface is bad or the compiler
has a lot of bugs that make compilation or features fail, that's bad.
That's not the case here, except for unreleased development builds or 
perhaps the first release of a new technology.  Probably any second
release will be good enough.  So you have to know what's new about a release.

The most important risk is of an error that is not detected until runtime.
That means you'll need a test to run the code to disclose the error.  Most
runtime errors fail at the class-verification stage, so any attempt to 
run the code will disclose the error.  Because those are easy to find,
I'd venture to say that we've never had one go unreported and unfixed for
more than one release (needless to say, verify errors are a top priority).
The harder and rarer case is when the class loads and seems to work, but
the code is not working according to the semantics of the AspectJ language.
The risk is that this will go untested before release, but the bug will
show up in production.  This is rare because most AspectJ features operate
in a sense on their own; once we write a point test for something and
show the implementation works, it works in combination.  However, sometimes
a feature has a comprehensive scope; for example, supporting annotations 
in pointcuts.  That's where I would anticipate this kind of bug in the 
first or even later releases.

As for maturity, basic compile/weave of Java/AspectJ code-style programs has 
been engineered over 4+ years and is based on leading technology that has 
been in use for years.  Because the binary weaver has always been a 
separate process, that means binary weaving is as strong as 
compile/weave.  This year there may be a period of transition if the next
release moves from BCEL to ASM bytecode weaver, but both are good toolkits.

@AspectJ annotation-style programming and new load-time weaving support
were introduced in the AspectJ 5 release.  This style has to be implemented
slightly differently, so the technology is newer.  We are aware of 
functionality corners with annotation style where it doesn't quite match 
up with code-style, and we are working to make load-time weaving perform
better in J2EE containers (many of the problems here stem from Java's
federated class loading, esp. as mis-used and mis-understood).  So these
don't come with the same guarantees as code-style.

While AspectJ can be used standalone and with Ant, many programmers use 
the Eclipse AJDT plugins for AspectJ language support.  It's a most 
excellent way to view the crosscutting and get immediate feedback and
support from the compiler/weaver.  But the AJDT team has to keep up with
changes in both Eclipse and AspectJ (and still they seem to produce a 
steady stream of new features).  So often users want to be on the latest
AJDT because it has great features, but they can experience the bugs
that come with newly-released code.  Here's where it helps to use
AJDT for compile/test cycles, but Ant for building: developers can be
at the leading edge without hurting the production/build cycle.

Finally, the biggest point about adoption is to do so incrementally.
Incremental adoption has been the central story, e.g., in the AspectJ 
Programming Guide since the first release of AspectJ.  Most AspectJ
experts will counsel clients to go slow, and most clients will end
up going faster than they planned.  Incremental adoption works because
developers learn about AspectJ while using it in safe ways, in pre-
production code or non-functional production code, etc., so the 
risk equation only gets better.  (The risk should be compared against
the alternative; most developers find that using architecture-enforcement
aspects and modularizing scattered concerns lead to much better code
than the Java-only solution.)  To my knowledge, the AspectJ project
is the only one with a history of avoiding hype and encouraging
deliberate rather than enthusiastic adoption, and I hope those with
clients take this approach.  

(I didn't speak to Spring since you didn't say which version (i.e., 
the new full-aspectj or the old/mature limited-aspectj) and because 
Adrian is of course the person to answer that.)

Hope this helps -

------------Original Message------------
From: "Jeppe Cramon" <jeppe@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Mon, May-15-2006 2:34 AM
Subject: [aspectj-users] AspectJ Production suitability


I have a client who's interested in using AspectJ 1.5.x in a new Spring 
based project.
Before they commit to using AspectJ they have some concerns that I hope 
some of you can help me address with facts.

- My client has heard rumors that since AspectJ is a two compile step 
the weaved code wont be able run under for instance WebSphere since it's 
doesn't use a standard SUN JVM. I've assured them that this is not a 
problem, since the weaved code is compatible with all JVM's. But to 
assure them is there an official AspectJ writing you can point me to where 
this issue is addressed?

- Do you know of any large financial applications in production that 
uses AspectJ weaved code?

Best regards

Jeppe Cramon
aspectj-users mailing list


aspectj-users mailing list