Comment 1 Andrew Clement 2005-04-13 03:51:44 EDT

Couldn't quite recreate it via that route... but *this* route always works:

1. Install the Telecom example
2. Make billing.ajproperties the active configuration
3. Open the billing aspect, change something simple (like adding a 'space'
somewhere) and save, it will blow up with the NPE

Comment 2 Andrew Clement 2005-04-13 07:42:53 EDT

Putting breakpoints in the addUsesPointcutRelationsForNode() we discover the
failure happens when the node in question is 'after(Connection conn):
Timing.endTiming(conn)' which is advice existing in the Billing aspect but
referring to a pointcut in the Timing aspect.

Armed with that info, here is a much smaller project to demo the failure:

X.aj contains:
public aspect X {
  before(): Y.p() {}
}

Y.aj contains:
public aspect Y {
  pointcut p(): call(* *(..));
}

Add a 'space' to X and save it, that causes an incremental build which then
causes it all to blow up in the same way.

Y can actually be a class or an aspect.

The actual bug is that if an incremental compile is performed, the
resolvedpointcutdefinition in the referenced file (which is recovered from its
.class file) will not have its sourcecontext set.  I've changed the read() logic
in resolvedpointcutdefinition to set it.

This then led to a problem with the test harness when I tried to add a test.  I
added X.aj and Y.aj then attempted to change X.aj and do a 2nd build - that is
the normal process we follow for incremental tests - AjState was thinking I had
also changed Y.aj for this 2nd build when I hadnt!

The problem is that because those files were *sooo* small, the compiler built
them super quick.  In order to determine what to build the 2nd time through, the
logic in AjState looks at the files on disk (X.aj,Y.aj) and compares their last
mod times to the last successful build time.  What we actually did in AjState,
because some systems don't have <1000ms accuracy in the timers is change this
check to 

if ((lastmodtime+1000)>= lastbuildtime) then file has changed and must be rebuilt.

In our case Y.aj got copied to the sandbox at some time n, for example:

0000000100ms

and the build completed in <1second, so the last build time was:

0000000700ms

so our check 

if ((lastmodtime+1000)>= lastbuildtime)

actually thinks that Y.aj has changed, when it hasn't!!

The solution is to pause for 1second after initially preparing the sandbox for
the first stage of an incremental compile test.  This ensures the lastBuildTime
will always be at least 1000ms beyond any last mod times on sandbox files :)


Fix checked in, waiting on build before closing bug.

Comment 3 Andrew Clement 2005-04-21 03:51:09 EDT

Fix available, see aspectj downloads page:

BUILD COMPLETE -  build.471
Date of build: 04/20/2005 20:56:23
Time to build: 147 minutes 56 seconds
Last changed: 04/20/2005 20:24:33

I believe the fix made it for AJDT1.2.0M3