Skip to main content

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

>(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.)

There should be no difficulty at all in using AspectJ with a Spring application (and coincidentally Spring makes an excellent environment for using AspectJ because it is very easy to configure your aspects as beans in the Spring application context). I do know of several large financial institutions successfully using the combination of Spring and AspectJ, but am unable to give details at the present time.

As Wes alludes to, Spring 2.0 also contains many improvements to Spring AOP itself, one of these being that Spring AOP can (at runtime) use AspectJ aspects written in the @AspectJ style. The Spring reference documents for 2.0 are in the process of being completed at the moment - once Spring 2.0 RC1 is released I'll post a reference to the list as I think it may be of interest to many folks who are using AspectJ.

Regards, Adrian.

On 15/05/06, Wes <wes@xxxxxxxxxxxxxx> 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?"
   http://www.eclipse.org/aspectj/doc/released/faq.html#q:compability
(3) the "compatibility" section of the development environment guide,
    esp. the part on Java compatibility:
   http://www.eclipse.org/aspectj/doc/released/devguide/compatibility.html#javaCompatibility

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 -
Wes

> ------------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
>
> Hi
>
> 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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users



--
-- Adrian
adrian.colyer@xxxxxxxxx

Back to the top