I have not observed any such problem. Do you have steps to reproduce from
scratch that I can follow to debug it? Is your computer's clock accurate?

I investigated this problem a little more and this is what I found:

The nbproject/build-impl.xml will execute the 'optional' task 'depend' just 
before the task 'javac' is called.

This depend-task removes class files which it thinks are out of date.
So I compiled ant and added my own debug information and got the following:
(I will only show it for 1 file because the problem will be clear then)

   [depend] Class org.jmeld.ui.text.AbstractBufferDocument$Line is out of date
with respect to
/usr/local/kees/projecten/jmeld/trunk/build/classes/org/jmeld/util/StringUtil.class(1170586695000
> 1170586694000)

I added the dates (in milliseconds) to the debug-info.
So the depend task deletes AbstractBufferDocument$Line.class because 
it depends on StringUtil.class and that class is 1000 milliseconds
newer!

This shows basically that the depend-task is fatally flawed. 

I have a feeling that the depend-task was NOT called in netbeans 5.5 and
before. And I think it will take a LOT of time just to examine the
dependencies between classfiles. Do we really need this?

Kees Kuip

Still awaiting steps to reproduce. I am unaware of any logic flaw in <depend>.
Of course if there is one it should be filed on ant.apache.org, not here (CCing
jglick@netbeans.org).

<depend> was indeed not used in NB 5.5. The dependency-tracking feature was
implemented recently. See issue #36033 for background.

Did you read my findings? Sorry, I can't make it any clearer than that. 

The workaround that works for me is to to delete the call to the depend-task in
nbproject/build-impl.xml.

I need a way to reproduce the problem, from scratch, on my own machine.

"the depend task deletes AbstractBufferDocument$Line.class because it depends on
StringUtil.class and that class is 1000 milliseconds newer" - which is the
correct behavior if in fact StringUtil.java was more recently compiled, since
the changes to StringUtil.java might have broken AbstractBufferDocument.java.

If, as you say, repeated runs of the task are (pseudo-)randomly deleting .class
files, thus forcing recompilation, even when no source files have been touched,
then that is a bug somewhere - perhaps in the task itself, perhaps in the
project's build script, perhaps in the JRE, perhaps in your computer's
filesystem implementation (e.g. clock skew over NFS). I have never seen such a
problem occur with <depend> and I can't diagnose it without a way to reproduce.

I guess you can take any project. Do a 'ant clean' and 'ant compile'.

The key of the problem is that AbstractBufferDocument$Line.class and
StringUtil.class where compiled (and written) during the SAME javac session. But
since it takes time to write a file they have slightly different modification
times. 

I cannot reproduce using a NB 6 dev build. I create a new empty j2seproject. I
then cd to src in a shell and populate it with this Ruby script:

max='Z'; ('A'..max).each {|x| ('A'..max).each {|y| c="#{x}#{y}"; t="class #{c}
{\n"; ('A'..x).each {|xx| ('A'..y).each {|yy| t << "    static {new
#{xx}#{yy}();}\n"}}; t << "}\n"; open("#{c}.java", 'w') {|f| f << t}}}

This creates a bunch of classes such as

class BC {
    static {new AA();}
    static {new AB();}
    static {new AC();}
    static {new BA();}
    static {new BB();}
    static {new BC();}
}

Now 'ant compile' from the command line (Ant 1.7.0, JDK 6) initially compiles
676 sources, as expected, which takes several seconds. Subsequent calls to the
same target do not compile anything. If I touch e.g. WW.java, then the next
compile deletes and recompiles 16 sources, as expected; running the target again
compiles nothing, as expected.

I cannot give you a precise recipe for reproducing this isue. But the issue is
there!. 

To see the problem you have to accomplish this:
- 'ant clean' and 'ant compile' a large enough project so that some class files
have a different 'lastModified' date. (Note: You should take care that javac is
compiling longer than 1 second!)
- 'ant compile' again and see that some files are deleted by the <depend> task.

Note: Maybe it is a problem with javac and Linux. Classfiles on Linux that are
compiled in one go with javac CAN have different 'lastModified' dates. Maybe on
Windows this is not the case.

My previous workaround (deleting the <depend>) doesn't work. Sometimes netbeans
will recreate the build-impl.xml. So I've decided to build my own build.xml and
strip the netbeans 'nbproject' from my project. So it is not a netbeans project
anymore. Besides that I created an empty netbeans-project which will 'import'
the sources/libs from my other tree.

*** Issue 94851 has been marked as a duplicate of this issue. ***

I *do* use Linux. mclaassen reports similar-sounding issues on XP.

Removing all NB project metadata is certainly unnecessary, and you should not
modify build-impl.xml. (Though the IDE should never overwrite build-impl.xml
with a new version if you have modified it, provided you do not touch
genfiles.properties). Simply pick any targets you don't like, copy into
build.xml, and edit to your taste; the importer overrides the imported.

New test case is around 5000 classes:

max='Q'; ('A'..max).each {|x| ('A'..max).each {|y| ('A'..max).each {|z|
c="#{x}#{y}#{z}"; t="class #{c} {\n"; ('A'..y).each {|yy| ('A'..z).each {|zz| t
<< "    static {new #{x}#{yy}#{zz}();}\n"}}; t << "}\n"; open("#{c}.java", 'w')
{|f| f << t}}}}

ANT_OPTS=-Xmx600m ant -f ../build.xml clean compile

takes about 29 seconds; timestamps of *.class (ll --full-time) differ by up to
13 seconds.

touch ANN.java; ANT_OPTS=-Xmx600m ant -f ../build.xml compile

recompiles 16 files, as expected. I cannot reproduce any randomness in the
behavior when trying various commands.

Again I have to ask reporters for some hints on how to reproduce from scratch.
Do you perhaps keep sources on a network drive with a poorly synchronized clock?
Can you reproduce this issue on anyone else's computer? On several unrelated
projects? Are you using a recent 6.0 development build with Ant 1.7.0 bundled?

I haven't tried to find a more trivial test case.  I will try with some of my
smaller projects to see if I can reproduce it in simple environment.

I can tell you that I do not have any files remote to my PC.  

I will attach a project that gives me this issue.  My test case is to go a the
PrinterSettings.java and add a space after:
     private final float left;
and then delete it.  I do this and then press F9
---
Deleted 2 out of date files in 0 seconds
Compiling 1 source file to C:\dsi\Netbeans\GeneralProjects\Java6Print\build\classes
---
Deleted 1 out of date files in 0 seconds
Compiling 1 source file to C:\dsi\Netbeans\GeneralProjects\Java6Print\build\classes
---
Go to the java6print package node (in the project window and press F9)
Compiling 2 source files to
C:\dsi\Netbeans\GeneralProjects\Java6Print\build\classes\
(No files now show as needing to be built)
---
Back to original test
Deleted 3 out of date files in 0 seconds
Compiling 1 source file to C:\dsi\Netbeans\GeneralProjects\Java6Print\build\classes
(Main and PrintMe now show as needing to be built)
---
Deleted 2 out of date files in 0 seconds
Compiling 1 source file to C:\dsi\Netbeans\GeneralProjects\Java6Print\build\classes
---
Deleted 1 out of date files in 0 seconds
Compiling 1 source file to C:\dsi\Netbeans\GeneralProjects\Java6Print\build\classes

I forgot my system config
Somewhat older Sony VIAO laptop running Windows XP with most of the latest patches.

The build I am currently using is 200702081900

Created attachment 38447 [details]
Sample project that produces the error

I think I have a recipe now. Maybe you can try that.
But you have to check out my project. Do a:

 svn co -r 284 https://jmeld.svn.sourceforge.net/svnroot/jmeld jmeld

You have to change the './nbproject/project.properties' and fix the path of 
all the libraries. To keep the test clean you can also delete all my 
targets in './build.xml'

Now do a :

rm -r build
ant compile
ant compile   <-- Problem should be seen here
ant compile   <-- and here...

If this doesn't work right away then try again (starting with removing ./build)

> Do you perhaps keep sources on a network drive with a poorly synchronized clock?
No, The sources are on the computer's own harddisk.

> Are you using a recent 6.0 development build with Ant 1.7.0 bundled?
I'm compiling on the commandline.
[kees]# ant -version
Apache Ant version 1.6.5 compiled on February 4 2007
[kees]# java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

Cannot reproduce any problem using keeskuip's instructions. Initially compiles
144 sources. Subsequent runs do not recompile anything.

With mclaassen's project, we have the deps

Main$1 -> {Main}
Main -> {PrinterSettings, PrintMe, Main$1}
PrintMe -> {PrinterSettings}
PrinterSettings -> {}

On Linux, JDK 7 (but JDK 6 for the project), NB 070212, I do a clean build
(clean, jar). I touch PrinterSettings.java and F9 it. Deletes 3 out of date (PS,
PM, Main) and compiles one, leaving PS.class and Main$1.class. (See issue #85707
which requests that compile-single not use <depend>.) I F9 again, which also
deletes Main$1.class. (Not sure offhand why <depend> will delete Main$1.class
only when Main.class is already gone, but seems pretty harmless, and behavior is
predictable for me).

I then F9 on the package node. Two sources compiled, all 4 .class present. F9 on
it again does nothing.

I again touch PS.java and F9 it. Behaves as before.

So I still am unable to reproduce. Can anyone from QA reproduce? If not, I would
ask reporters to try to find out what is going on at a low level, e.g. in a
debugger, if you have any time to spare. (Especially if you can reproduce in a
command-line build.)

> Cannot reproduce any problem using keeskuip's instructions

Hmm, I tried it this evening (after a fresh reboot) and I couldn't 
reproduce the problem.

Then I added a Test.java to './src/', compiled it and there the problem
is again. Then I deleted Test.java, deleted './build' and the problem is 
there. grrrr... (maybe you can try this, I know it sounds rediculous)

Please let me know what I should debug?

Well, everything is happening in the
org.apache.tools.ant.taskdefs.optional.depend package, so if you can (at least
sometimes) reproduce random behavior from the command line, then you should be
able to debug or instrument these classes to find out what is going wrong. I
can't say I'm intimately familiar with the internals of this task, but it should
be relatively straightforward; at least, you can examine its dependency cache
clearly since it is a plain text file.

I don't know if this is a clue or not, but I can get NB5.5 to misbehave as well.
To me this seems weird and I had to do this a few times before I could really
believe it.
To reproduce:

Start NB 5.5
[default project is the one I am working on]
Start NB 6 M7 (click OK on that cannot find file dialog)
[default project is the same as the one in NB 5.5]
In NB 5.5, add a space to a file and then delete it.  Press F9
Deleted 17 out of date files in 8 seconds
In NB 5.5, add a space to a file and then delete it.  Press F9
Deleted 9 out of date files in 7 seconds

Close NB 6.0
In NB 5.5 (the only NB open now), add a space to a file and then delete it. 
Press F9
Deleted 13 out of date files in 7 seconds
Right click on project node, clean
[Verified that build directory is gone]
From the toolbar, build the project
In NB 5.5 (the only NB open now), add a space to a file and then delete it. 
Press F9
Deleted 3 out of date files in 13 seconds
In NB 5.5 (the only NB open now), add a space to a file and then delete it. 
Press F9
Deleted 17 out of date files in 8 seconds

Close NB 5.5
Restart NB 5.5
In NB 5.5 (the only NB open now), add a space to a file and then delete it. 
Press F9
Compiling 1 source file to ... 
[The problem no longer occurs]

NB 5.5 is running on JRE 1.6.0-b105
WinXP 5.1

Here's another side-effect of the <depend> task.

Today, at work, I tried netbeans milestone 7. (Until now I only tried netbeans
6.0 on my own projects at home)

Netbeans 6.0 will convert the build-impl.xml and it inserts the <depend> task.
If I start (or debug) my application in netbeans it spends 20 seconds in the
<depend> task. In netbeans 5.5 the start was immediate. After the build-impl.xml
change also netbeans 5.5 took 20 seconds to start. I then removed the <depend>
task ant it started immediate.

That last comment would seem to explain my issue.  NB6 must have rewritten my
build-impl.xml file when it opened, and NB 5.5 must also rewrite it on open.

I guess the <depend> task is available in NB 5.5, but just is not used.

<depend> is just part of Ant. Whatever IDE you open the project in generates
your build-impl.xml.

I know that <depend> is an ant task, but it is the question whether netbeans
should use that task.

Is there any chance that the call to <depend> will be removed? or can I override
it somehow?

As with any target in build-impl.xml, you can easily override the default
implementation just by copying it to build.xml and editing it there.

Has there been any movement on this?  

Was jglick able to reproduce this?  It is reproducible always on my machine. 
With all the activity before M7 I thought this would be solved quickly.

If more research is necessary, is there anything a layman can do to help with
this?  To do so would I *just* need to download ANT from source, build it, get
it working and then run through a compile while stepping though the ANT source?

No, I have not yet been able to reproduce. Any research would be welcome. If you
can consistently reproduce on your machine, especially using command-line Ant,
then (unless it is timing-related) you ought to be able to pinpoint the problem
in a debugger.

mclaassen,

Before I submitted this bug I did exactly what you propose!
I downloaded ant and debugged it (with log-statements). You can see
the result in the third comment. I even showed the output of ant including
the logstatements! 

My conclusions were:
- The depend task does it task perfectly because it works as advertised.
- The depend task is still fatally flawed because files that are 
  compiled with javac in one session (this is important!) are written to 
  the filesystem at different times! This is the problem. The next time
  the depend task is called it sees the different times and it deletes the
  appropiate files.

So what i'm saying is DONT USE THE DEPEND task because it is fatally flawed.
But I guess this is not possible because it solves another problem (at high cost
if I may say so because the dependency check takes forever).

Kees.

Kees.

Kees - do you have a self-contained test case I can use? I specifically tried to
compile such a large number of files in one go that they would have different
timestamps, and verified that they did have different timestamps. But this did
not cause any problem I could see.

I'm using netbeans 6.0 milestone 8 now.

The previous workaround doesn't work anymore! It seems that "depend" is now
a macrodef and I cannot find a way to NOT call it anymore. (The generated
ant file gets more and more complicated)

Is there a workaround possible? 

Kees. 

Yes, build-impl.xml changed, to fix issue #85707.

As usual, just override -do-compile (and if needed, -do-compile-test) to not
call the macro if you do not want it.

Ok, thanks, but it is not a very nice solution.

It would help a lot if the 'depend' task was a target in itself.
So :
<target name="depend">
  <.. call the macro ..>
</target>

The generated build file changes a lot between versions and I got bitten
by that already. I have to change my build.xml every time I use a different
Netbeans version. 

Could this be implemented?

It can't just be a target since it called (currently) from two places with
different parameters; that is why it is a macro. The macrodef could probably be
moved into a separate target so that it could be overridden to have an empty
body, but I think that would be uglier and less intuitive than simply overriding
the appropriate compilation targets to not call the depend macro.

how can you say that it's simpler?
Am I missing something?

I have already tried this path but the generated build.xml is changing a lot
between different versions of netbeans. I CANNOT go from netbeans 6 to netbeans
5 without changing my own build.xml.

But i give up. I think I have to live with the depend-task or else go elsewhere. 

If you like a particular version of build-impl.xml and want to stick with it,
simply delete genfiles.properties and the IDE will never regenerate it. We do
have an open issue to prevent automatic regeneration from going backwards in
time which would also help I guess.

No reproducible test case has been provided. Reopen if you find one.