I'm going to check in a different
change that creates a new AjState object whenever
doing a batch build. I can be much
more confident that this will be like restarting the compiler - which is
the desired behavior for this case.
This will also address the concerns you have in your other message about
implicit initialization assumptions in this class.
The only testing that I've done for
incremental compilation is based on the command-line compiler where the only
way to do a full re-build after the first build is by ending the process and
starting the compiler again. So, I'm
not too surprised that there are issues using the compiler in this way from ajde.
Note: Incremental compilation is
hard. It took a couple of months to
implement correctly for the compiler and the weaver - and I'm still
confident that bugs remain to be found.
I wouldn't be surprised if incremental structure building turns
out to be hard as well.
There are currently 6 unit tests failing
in ajde under IBM JDK1.3.1. These are the sorts of failures that we're
supposed to be addressing between the preview build and a final release. Trying to shoe-horn in a new feature during
this time is very risky. I think you
need to be prepared to either not release incremental-ajde
for 1.1.0 or to make a case on this list that incremental support in ajde is so important we should significantly delay the
1.1.0 release in order to have time to get it right.
My two cents - Jim
-----Original Message-----
From: Andrew Clement
[mailto:CLEMAS@xxxxxxxxxx]
Sent: Tuesday, May 06, 2003 7:15
AM
To: aspectj-dev@xxxxxxxxxxx
Subject: [aspectj-dev] Problems
getting 'non-incremental' to work in AJDT
After rebuilding AJDT on last nights changes to
aspectj, I couldn't get non-incremental to work properly - it would be OK for
the first compile within eclipse, but subsequent compiles always appeared to be
non-full builds, despite the fact that I was always calling buildFresh. If
I restarted eclipse, my first compile would always be OK.
I
eventually traced it to AjState.prepareForNextBuild() - this function returns
false if a batch build must be done. Returns true if an incremental build
*could* be done. I extended the method to take an extra parameter (batch)
and put the line in that checks for the batch setting. I've attached the
changed version below.
The
problem with the original version of this method seems to be that on the second
compilation, it gets past the 'if (lastSuccessfulBuildTime==-1 || buildConfig
== null)' and starts modifying some fields of AjState - in particular it
appears the 'simpleStrings' field that it changes is used elsewhere in the
class - (see writeClassFile in AjState). With my guard for the batch
setting, we don't change these fields. I don't think this is quite the
right fix - as it forces prepareForNextBuild to return false whenever batch is
in operation - but it is sufficient to get us to progress. AJDT is
looking much more healthy.
/**
*
Returns false if a batch build is needed.
*/
boolean prepareForNextBuild(AjBuildConfig
newBuildConfig,boolean batch) {
currentBuildTime =
System.currentTimeMillis();
addedClassFiles = new
ArrayList();
// Next line added by Andy
if (batch) return
false;
if
(lastSuccessfulBuildTime == -1 || buildConfig == null) {
return
false;
}
simpleStrings = new
ArrayList();
qualifiedStrings = new
ArrayList();
Set oldFiles = new
HashSet(buildConfig.getFiles());
Set newFiles = new
HashSet(newBuildConfig.getFiles());
addedFiles = new
HashSet(newFiles);
addedFiles.removeAll(oldFiles);
deletedFiles = new
HashSet(oldFiles);
deletedFiles.removeAll(newFiles);
this.newBuildConfig =
newBuildConfig;
return true;
}
cheers,
Andy.
clemas@xxxxxxxxxxxxxxx
