[
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