Community
Participate
Working Groups
In AjState.classFileChangedInDirSinceLastBuildRequiringFullBuild(), the assumption is made that if a class file in a dependent project was touched less than 1 second before the last successful build of the current project, then the class file is considered to have "changed" since the last build. If this class file contains an aspect, then the current project will do a full build. So, if a class in a dependent project changes, causing an immediate build in the current project (and the current project takes < 1 second to build), then the timestamp of the class file may still be too "new". Then the next time the current project goes to build, it will consider this class file as being dirty (if the class file contained an aspect, then it will be a full build). Granted, if the current project takes < 1 second to do a full build, then it is not such a big deal to do one by accident, but still is not great to do. See also Bug 99133 for this bug's manifestation in AJDT. See also Bug 129163 for a slightly different incarnation of this bug.
The +1000 exists for reasons on other (not uncommon) file systems where the timestamp is only accurate to the nearest second. On these systems, suppose the time is 10000 and a build happens at time 10100, subsequently a file changes on disk, say at 10300, and the project is asked to build. Because the timestamp of the file on disk is rounded down to 10000, it looks like it was saved in the past (compared to the build time). And however many times you ask the project to build it will not see it is a change because 10000<10100. So the trade off here is doing multiple builds too often when called multiple times within one second to build the same project, compared to not actually noticing a change and never building... the latter of which I'm seeing as a bit more of an issue right now. I am undecided on what to do. If the file were an aspect - how likely is it that the full build will complete in < 1 second? If the file were a regular class - are multiple incremental builds a problem? Should we write a helper to determine the timestamp resolution we are running with? I don't want an option in the UI for the user to choose it. Should the build timer lose its last 3 digits? Right now we always build when there is a change, but it isn't as optimal as it could be on some environments.
Makes sense. Do we know which environments these are? Or at least can we determine if we are in an environment that has millisecond-accurate timestamps (at least can we do this conservatively)? I would imagine that more modern OSs do have this granularity. If so, perhaps a flag can be set that determines whether or not we need this 1000 ms timestamp difference. Although, I do agree that in practice this may not be a big deal when it occurs. If the class file in question is java only, then it is not a big deal to add it to the list of changed classes. IF the class file in question contains an aspect, then this implies that a full build of the current project takes less than 1 second. Maybe not a big deal.
from what I recall it was on FAT32 filesystems - Alex Vasseur hit it first when he happened to be using a FAT32 partition for his OS and the default temp location where tests run is c:\temp . So it is a feature of that old filesystem rather than a particular OS. We could optimize for, say, Mac - but running a different calculation there depending on OS just might get us into some wierd bugs that can only be recreated on the right OS - but maybe i am worrying too much about that.
