I'd made the fatal mistake of running javac against my *.java sources. Ahem. (If you're wondering how this can happen, scroll to the bottom...)

AFAICS, I'm pretty sure I'm running into the age old bug in javac that it thinks it knows which classes needs recompiling, but if sometimes doesn't, and requires you to manually (and recursively, obviously, if you have packages) delete every affected class file before trying again.

(At this point, Jeff will probably tell me this is not a bug, it's a feature, and it's really good too .)

I don't mind the behaviour normally, but when it gets it wrong (which happens to me on average about once every month or two) it's a royal PITA. Obviously IDE's can automatically delete all classes for you before you start, which is one solution, but I'm hoping there's some undocumented switch on javac that turns off this behaviour?

It's not just a mild annoyance for compilation...we're also experimenting with a new SCM which doesn't accept incremental compilation, and the authors have pointed out that if we want java to work with it really nicely, we need to disable the incremental compile (for fairly obvious reasons, given it's an SCM...). They're all C++ programmers, and would like to know if we find a way of doing this...

Any suggestions?

EDIT: explanation of error: I upgraded a 3rd party library since my last compile of the sources; I think it altered a base abstract class in such a way that the subclass in my source is no longer a valid subclass. One aspect of javac's bug appears to be that it does NOT recompile sources when the JAR file that they depend on changes - it only works on raw class files.

That's why none of us actually use Javac to compile our code any more Wot you need, is a proper IDE

Cas

Actually I was testing a script (aiming for LCD - were it not for this Error I could make one file that runs on both windows and unix ) that could be bundled into a deployment package; it's easier to support something when you know you're including enough tools to guarantee anyone can get it to work. But your point still stands, of course...

However. The other problem remains - how to take full advantage of an SCM (i.e. something a lot better than CVS, VSS, etc, but in a similar vein) with javac. How to disable incremental compilation?

Do you really mean incremental compilation or do you mean dependancy compilation?

AFAIK we don't do incremental compilation. The only Java system I know that does is IBM's VisualAGE.

In terms of compiling dependancies, I've never run into a problem with it (and we compile the entire JDK on the command line) but I'll take your word for it that the problem exists. I don't know of any way to stop the compiler from trying to compile dependancies if it thinks it needs them.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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...

Quote

Do you really mean incremental compilation or do you mean dependancy compilation?

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...

Quote

In terms of compiling dependancies, I've never run into a problem with it (and we compile the entire JDK on the command line) but I'll take your word for it that the problem exists. I don't know of any way to stop the compiler from trying to compile dependancies if it thinks it needs them.

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...)

Incremental compilation has traditionally meant the compilation of aprts of the rpgoram as it was written or modified. It generally implies the abilty to do substitution of code in mid-run.

IBM's VisualAge does this. If you re-write a method in a running program that method instantly changes. SmallTalk systems traditionally did this. There was a product a while back called somethign liek InstantC which was a C environment that used threaded compilation and also did such replacement, in its case a line of code add a time resulting in a psuedo-interpreted like environment for fiddling with C code.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Ah, i follow your problem soem now. yes, if a class file of a date later then your current .java file exists and ist a dependancy for another class then its not going to get recompiled. You would have to do a clean or manually recompile it yourself. We've seen soem problems like thsi wehn usign code from multipel build environments that aren't well time-synchronized. usually doing a clean sovles the problm.

That's part of why this is such a special SCM ...in fact, you have to check-in your *compiler* too. It aims for (and, allegedly, easily achieves) 100% repeatable builds (even if you originally built it on JDK 1.0.0, and find it's now no longer available for download ). Of course, this feature was designed for C programmers, not Java, since this can be a really big problem in C dev.

We're still evaluating it, but my initial impressions are that it's a bit of a killer app in the SCM world (hint: it's free, but with several of the good features I miss from my days working at big corporates who had monstrously expensive SCM's).

Still, we're still getting to grips with it; it's not mainstream at all, and so documentation is good but very sparse. Once we've used it in anger, if it's still any good, I'll post to the tools forum with info . Right now, my experience with it is too brief to be able to say much about what it does and doesn't do.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org