Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] ajc vs. javac - commercial application - convincing the boss

More on adopting AspectJ/ajc in your organization...

Summary:

(1) you might try to ship the javac-generated binaries
    if you're only using AspectJ for testing

(2) ajc is validated, but not completely
  (a) 1.1.x is built on Eclipse's compiler, which I believe
      has passed Sun's JCK compiler tests
      (but has a different back-end!)

  (b) 1.0 tested well against Jacks
      (we should retry with 1.1)

  (c) it's in use in commercial production elsewhere
      (but we have no hard data here)

  (d) ajc has not shown too many errors,
      (particularly of the worst kind)

(3) A clear increase in quality is worth trading for the
    residual increased risk of using ajc over javac.

To me this means groups are safe in incrementally adopting
AspectJ, but we on the project could do more to reduce
uncertainty about the correctness of ajc.

Details...

Shipping javac- or ajc-generated binaries:

> I'd like to build with ajc, run the suite of AO gui
> tests, and, if all tests pass, ship *that* build.

I agree that one normally wants to ship the binaries that
are tested, but when incrementally adopting AspectJ, that
might not be the way to go.  You could instead create a
production build jar by compiling the pure-Java production
code with javac and then

(a) test it using aspects that only depend on calls into
the build.  This, like any other test code, is completely
separate from production code.

--or--

(b) weave the production build jar with non-functional
aspects for testing purposes, and test that.  Accepting
that this validates the production build involves
showing that the aspects are not invasive (e.g., they
just trace or drive the GUI).  For some aspects, this
showing is not difficult.

But when you want to use aspects in production, how do
you know ajc is as good as javac?  Not crashing is clearly
necessary but not sufficient.  AspectJ 1.1.x is built on
the Eclipse Java compiler, which I understand has passed
Sun's JCK compiler tests.  However, we have a different
back-end that generates/weaves bytecode using BCEL, and
to my knowledge this bytecode has not been tested for
compliance.  I know that we try to generate bytecode
like javac's just because most tools know how to deal
with it (i.e., where the language or vm spec is unclear,
javac is the de facto standard), but we could have gotten
it wrong in some cases.  Further, we have not recently
tested against the open-source Jikes test suite (JACKS).
In the past, we did very well (but not perfectly)
against that, and we found some bugs in JACKS.
We should start testing against JACKS again, but we
would only fix our compiler to pass a test if javac
(and the unaltered Eclipse compiler?) also passed the test.

Aside from testing, there's widespread adoption.  If we
had real numbers on the number and complexity of
production projects using AspectJ 1.1, we could show
people that the likelihood of a bytecode error is small
because it would have been detected and reported.
But we don't have those numbers.

One measure of quality and adoption is the find rate for
bugs.  If bugs once introduced are found quickly, then
the community is fairly robust.  Still, the number of bugs
introduced should be as small as possible, to show that
the developers know what they are doing.  Both, of
course, should be scaled for the severity of the bug.

Here's one scale of compiler errors, from worse to best.
You can look in the bug database to see which of these
has been reported against ajc, and compare that against
bugs reported against javac, eclipse, or jikes.

1) generated bytecode silently does the wrong thing

2) generated bytecode is invalid (typically throwing
   a VerifyError when loading a class)

3) the compiler fails to accept valid input

4) the compiler fails to reject invalid input

5) compiler messages don't clearly indicate the problems
   to solve

6) compiler messages don't point out code that is valid
   but likely to be semantically incorrect

From memory, we had two (2) in the initial 1.1.0 release,
one which shocked me because it went unreported for 2+
months.  (All are fixed in the recently-released 1.1.1.)
It made me a little more nervous about the level of usage
we were getting in the community if/since no one had found
it before.  But the code might seem arcane and low-traffic.

In any case, I believe it is true that we have had *no* bugs
of kinds 1-4 in pure-java code, which is the equivalent
with javac.


Finally, a separate argument for using ajc (i.e., AspectJ)
is an increase in code quality.  This can come from

- best-available implementation of critical features
  (e.g., consistent error handling)

- sole-available implementation of desirable feature
  (e.g., first-failure data capture)

- proveably consistent implementation of boilerplate code
  (e.g., property change support, GUI updating)

- additional quality-related features
  (e.g., tracing, state-tracking, etc.)

Put another way, you can use AspectJ to increase the quality
of production code by validating more things about the code
at compile- and run-time, to prevent more errors and reduce
the cost of errors that do occur.  These errors are typically
programmer mistakes endemic to scattered implementations
of crosscutting concerns.  So you're trading a demonstrated
increase in quality by using AspectJ against a possible risk
from using a buggy compiler.

I hope this helps.  Let us know what happens!

Wes

P.S. - I recommend reading all of our documentation.
Ram book is great because it makes it easy to get started, but
the docs have evolved over some time by user feedback to
answer most questions.

Peter Kalmus wrote:

First, thanks to all the aspectJ developers - aspectJ is, simply, thrilling. I'm having a blast.

Ramnivas Laddad claims that ajc is built on top of the Eclipse compiler (p. 440, and I think this may not be true in 1.1.1), but I don't know any details about its architecture. How much can I trust it - how do I know that the ajc compiler won't introduce bugs not present in code built with javac? I'm a developer who needs to "sell" aspectJ to my organization. I'm using it as part of a gui testing framework. The system I'm testing is currently in production, built with a SDK javac. In the future I'd like to build with ajc, run the suite of AO gui tests, and, if all tests pass, ship *that* build. I'm looking for specific arguments convincing my managers that the risk of using ajc vs. javac is tiny.
By the way, part of their anxiety comes from the fact that Eclipse (with 256M) runs out of memory and crashes after 2 compiles, since memory used compiling is never reclaimed. Memory Monitor plugin did not help.  My managers find this less than confidence inspiring. A fix for this problem would be much more valuable to me than the fancy new Outline View. :-)

Thanks!

Peter



---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software



Back to the top