[quote]Terms are confusing me here.
[/quote]
Sorry, that is the terminology that THEY used to describe this aspect of java, I was only parroting their term; they cited it as a common feature of sun’s javac and others like jikes. To me incremental compilation means no more than “you only compile the things that need compiling”, which fits what I’m describing, but I’ve hardly ever heard the term w.r.t java, so…
Well, if you think the terminology’s wrong, why don’t you explain what it means to you? I don’t know if I/they/we mean what you think we do :). FOLDOC and others have empty definitions for the terms :(, although I found one site that suggested incremental compilation meant “compiling individual methods” and having multiple copies of the same method inside a classfile, but changing function pointers to ensure that the “newest” versions were used.
By that definition, I certainly don’t mean incremental compilation…
In general, as I said, I’m not bothered by this class of problems; if I see weird behaviour in mine or someone else’s code I first type “java -version” and then try redirecting the build classfiles to a new, empty, directory :). I don’t really think about it, and it could be that 99% of the cases I see are user error where people are trusting javac to be sentient 
(c.f. next para).
FYI A common problem I’ve seen is when an old class file gets left around for a class that no longer exists (because of recent refactoring) where unless/until you manually (or a script of yours automatically) deletes said file, other classes dependent on that classfile won’t recompile. It makes perfect sense when you realise what’s happening, but I’ve seen it really upset more than one person (days of debugging and muttering “this can’t be possible” until they see the light).
There have always been some problems in this area (although e.g. the one I describe above is user-error and not any kind of javac bug) since I started developing in java. My understanding is that . IIRC javac uses the datestamps (amongst other data) to make decisions of what to compile, so another example is with mounted FS’s (and flakey OS’s) where these may be sufficiently inaccurate as to screw things up (again, more of a user error). The first example I recall hearing (2nd hand) was of compiling sources partly from a mounted remote FS and partly from the local one, where disparity in the clocks of the two machines caused certain files not to recompile, with no compiler warnings etc of course, producing really strange bugs (until you worked out the cause).
PS w.r.t the example I had today with the ICCError it could have been another user-error case; I didn’t check for orphaned classfiles, for instance, although I do know that I updated a jar file and javac didn’t recompile several files that were dependent on classes contained therein; if I had a definite precise test case of these build problems (and they caused more serious pain than they do :)) I’d file a bug report :). As Cas pointed out, it’s usually just a cosmetic thing.
FWIW I’m not even convinced this dependency compilation should be a problem for the SCM. However, it’s an SCM where the entire repository is transparently mapped into your FS (nb: unix only), so the problems could come from the fact that results of previous compiles are in the classpath for future compiles and there’s no way of turning this off without breaking several features of the SCM :(. (nb: we are trying to find ways around this, e.g. by de-mapping pre-existing classfiles from the FS. Dunno if this is going to work or not, though…)
