Bug 41689

If running Ant leaks memory, that is a bug and we will fix it if we
can reproduce it. We need precise steps to reproduce the leak from
scratch, starting with a fresh build of NB, fresh user directory, Ant
script and sample files.

Created attachment 14442 [details]
A simple ant task that grabs an amount of memory and doesn't release it

Created attachment 14443 [details]
A build file that uses the leaking task

I have just attached a couple of files that illustrate the problem. As
I wrote in my initial enhancement request, the problem is caused by
bugs in the tasks, not AFAIK in NetBeans. The problem is that NetBeans
becomes very sensitive to such bugs since Ant is run inside the
NetBeans JVM.

Re. buggy tasks: sorry, but you need to get the bugs in the tasks
fixed. Leaks in tasks would also harm various other Ant containers,
and would even harm command-line Ant if you just used the task too
many times. Ant tasks are responsible for cleaning up after
themselves, and where the basic operation of the task is known to leak
memory with no apparent workaround (e.g. running Javadoc, last I
heard), the task is responsible for forking a VM to do the dirty work.

Re. this particular case: as of NB 3.6 the entire Ant installation is
supposed to held by a soft reference, and also leaks held by task
classes ought to be collected when the project goes away; so the task
and script you mention should not leak memory permanently (though it
may take a while for the VM to collect it, depending on GC policy).
When I get a chance I will take a look at your example and check it in
a profiler to see if there is any permanently unreclaimed memory.

I'm using 3.6 and every Ant run steals a few MB's of memory. I always
pump the Memory tool bar after a run. After some time I get
OutOfMemoryExceptions and often NetBeans can't even be closed because
of these exceptions. I'm pretty sure it's the XDoclet tasks that are
responsible, and there is little hope that these bugs will ever be
fixed. But that is not really the point here. There will probably
always be Ant tasks out there that has memory leak bugs, especially
since such bugs are easily overlooked when using Ant in scripts with
comparably short lived JVM's. The "problem" with NetBeans, as opposed
to e g JBuilder, is that you don't need to restart it every twenty
minutes, so the leak accumulates. When I entered this issue, I choose
type ENHANCEMENT. I still think it would be an enhancement to have the
option to run Ant in its own JVM. Ideally, the option would be
specific to the build file so that you can use it only when you need
it, since you'll probably lose some NetBeans specific features.

OK, will consider in that light, though it will be less useful in NB
4.0 since

- common IDE functionality such as debugging or browsing generated
Javadoc will require special in-VM tasks in 4.0 due to the new
Ant-based project system

- stack trace hyperlinking works more reliably in 4.0 if you are
running in-VM

- desired output formatting features (might slip till 4.1) may require
in-VM operation

- spawning a new VM to run Ant is slower and would noticeably impair
responsiveness of common lightweight operations

So I'm not sure how practical it will be in 4.0 to offer such an
option (putting aside for the moment the development time to implement
it), since normal project build scripts will not work as nicely if run
out of VM, unless a rather more complex solution is chosen using RMI
or sockets or something like this to enable rich Ant -> IDE
communication. Making it a per-build-script choice (default to run
in-VM) would be technically straightforward but the UI would be poor
and I am not sure many users would discover it.

"I'm pretty sure it's the XDoclet tasks that are responsible, and
there is little hope that these bugs will ever be fixed." - why? It's
open source. If the bugs are reported and someone has an afternoon
available to work on them, especially if they are straightforward to
reproduce, probably they could be fixed. If the entire XDoclet engine
and/or support libraries leaks memory right and left and it is
impractical to fix the whole thing, the tasks should certainly have an
option to fork a VM when they run - this is not very hard to implement
in an Ant task as a rule, and many tasks already offer such an option.

If, as you say, "making it a per-build-script choice (default to run
in-VM) would be technically straightforward", then that sound great.
You also say that "I am not sure many users would discover it", but
there are so many nice features in NetBeans that isn't always easy to
discover. When you really need them, you'll find them, with a little
help from your friends at the forum!

Concerning XDoclet; The current version is 1.2 and it seems to be
quite dead so we'll probably have to live with the bugs.

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

No immediate plans to work on this.

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

Later.