finalize() is always called before an object is garbage-collected. The thing is that there is absolutely no guarantee that any particular object will ever be collected. Objects are garbage-collected only when the JVM needs to reuse their memory. This means that finalize() is not an especially good way to reclaim resources. Although the finalize() method isn't deprecated, it might as well be, because it has no truly useful purpose.
In general, if a Java object is a proxy for some native resource, then what you should do is give that class a public method named dispose(), and make it a requirement that clients of that class call dispose() when they are through with the object.
I already wrote cleanup() as a hack for the bug. but since app does not process all events in 1 thread. its a big change on the application and future developers should be forced to call it after they are done with the object. (boring)
The finilize on my java objects is called since they do not leak. I leak JVM memory.
That's an awfully complex solution for a simple problem, and worst of all, it gets one major thing wrong: the external resource may well be exhausted before the Java heap. If each 32-byte Java object has a pointer to one megabyte of native memory, then allocating a thousand objects might use only 32K of Java heap, but exhaust 1GB of native memory. GC won't be triggered, but the external resource could well be used up. You can't use finalize() to manage external resources, period.
But in any case, you seem to understand the issues. The only real answer is to have your clients use the dispose() method. A "finally" block is a handy way to make sure dispose() gets called in the face of errors.