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

Wes -

Thanks for the *awesome* response.   You guys are clearly very dedicated.  No wonder AspectJ
rocks!

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

Perhaps include your response in the FAQ?
 
> (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.

This sounds promising to me.  The reason I adopted AspectJ in the first place was to avoid
scattering component registration code (clearly a crosscutting concern) throughout the project. 
This registration is, by its nature, a passive process driven *by* the construction of the system.

I'll probably either use this approach, or simply decide to ship what comes out of ajc, turning
off the advising code in production with a config file param.  If we're confident in our tests, we
shouldn't be too afraid of the big bad ajc. 

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

I have a vested interest in testing 1.1.1 against JACKS - I'd be happy to help...

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

Hmm.  That's what I'm trying to avoid.  Using -injars to weave the javac compiled classes,
testing, and then releasing the javac jar would prevent this for me.  But... I can't imagine
something like this not being caught by running a very thorough automated, Robot-driven test
suite.  How did it manage to go unreported for 2+ months?  What are the chances of something
serious like that getting through my test suite (assuming it's thorough - e.g. thousands of
tests)?

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

That will sound good to my boss.  :)

> 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 agree.  I see my AO testing framework as an investment in the future - a short term risk that
manages long term risk.  By adopting AspectJ in a relatively uninvasive (and frankly, low-risk)
capacity, we'll be ready to start using it to address other crosscutting concerns, as you
evangelize.  Maybe I could have just peppered calls to Registry.addComponent() throughout my code
in less time than it took me to get ajdt working, but... oops, I'm preaching to the choir here.

> I hope this helps.  Let us know what happens!

It does help, and I will.  Let me know offline if I can help out with JACKS.

-Peter


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


Back to the top