🚀 go-pugleaf

I think Swing is holding the listeners in a hashtable that is referenced
through a loooong chain where at the root there is some static variable. I
am looking at it using OptimizeIt. I have bunch of panels inside each other,
and bunch of Swing and JBCL components sitting in them. I have bunch of
event listeners and son on. I try to call removeAll through my components,
and then I set my own references to null as well. Now after all this I have
no strength to remove my listeners. I am waaay past that point. The point I
decide I do not need these panels is far away from event listeners.  Those
listeners hold adaptees that are my panels etc... so that my panels do not
get collected. Ideally, setting my root reference to the mother panel should
be enough for all panel group to be GCed. But if Swing holds a static
variable refering to my listeners or whatever, how the hell if GC going to
work?

I have other parts of my code, that are non-gui they work perfectly fine.

Also a bug report - JDBC Tree control holds a cache, that refers to an
object that was in the tree. That reference remains valid even if I remove
that object from the tree. I was able to overcome that difficuly because
what I actually add to the tree was a Pair object. My real object was on the
aPair.second, so while removing my objects from the tree I also have to set
aPair.second = null. SO that Borland Tree holds a reference to the pair
object but at least my whole structure is detached from it....


I guess only choice is to make my panel classes implement "destructor
interface" that will enforce a function called destroy()  that will be
responsible for removing children and removing listeners... but then I have
to keep track of the listeners I add.... and I have hundreds of places to
keep track of these. And at any point, if I forget any reference alive,
nothing will get collected, because the structure I want to make available
for GC contains internal references. If I have to clean those internal
references to increase chance of being GC'ed for a given object, that is a
BIIIG price to pay compared to being responsible of deleting my own objects
like in C++. This GC joke in Java is the same as creating objects in C++ and
nearly never deleting them. Of course then you never get a bad pointer. The
problem with Java is that every refering object needs to clear all
references where as in C++ only the owner of an object is responsible for
deleting it...

Look at JBuilder, I have to restart it every 3 hours, because it can't GC
anything.

So any ideas? Do i have to live with a fat, bloating application that holds
on to it's goodies until it dies?

Thanks
ali



"John P. McGrath" <JPMcGrath@fast.net> wrote in message
news:MPG.142e43f969d1f40e989b46@forums.borland.com...
> On Sat, 16 Sep 2000 02:15:39 -0700, Ali Demir wrote:
>
> > The problem is that Swing is holding some references through
> > some of it's static variables.
>
> There are a few bugs where Swing holds onto object references, but are
> you sure that is what is happening?  In most cases I have seen that this
> occurs, it is possible to tell Swing to forget the reference.  Which
> Swing variable is holding references to your objects?
>
> --
> Regards,
>
> John McGrath