Community
Participate
Working Groups
After compiling a .java file, the incremental java builder checks if the new bytecodes are identical to those in the corresponding .class file (it actually does a byte-by-byte comparison), and if they are identical, it does not update the class file. This leaves the .class file with a time-stamp that is older than the corresponding .java file, which can confuse external tools like RMIC that rely on comparing time-stamps to detect if a file is out-of-date. The builder should at least update the timestamp on the .class file in this case.
However I suspect this would be detected as a resource change for dependents, which is exactly what we are trying to avoid.
Actually, usually this would only be an issue for user edited files, when the edit did not modify anything in the binaries (like a minor comment modification). Dependent files which are recompiled did not get edited.
In case the original source got modified in the build iteration, and we could not attempt to reuse the bytes (or still touch the file). Need to investigate. John - how critical is this ?
Since fix is quite trivial, we will try to sneak it in for RC2.
Released a fix for consideration.
Integrated for RC2. John - do you need it backported in 2.0.x stream ?
No, at this time it does not need to be backported.
Verified.
