Is it correct to say you can never have a memory leak in a java application

Question

Also, what is the reasoning/advantage behind the developer not being allowed to explicitly call the garbage collector? Seems a simple thing to allow and would it not get rid of all the timing problems caused by the unpredictability of when the GC will run?

Answer 1

Not only dispose of Window but also close of Input/OutputStream,My experience is failing to close streams won't cause any leaks (for a file output stream, changes just aren't being reflected in the file).
cancel of Timer andWhich timer? AFAIK they (swing/util) both use a Thread and there's no need to let go of any native resource.
dispose of Graphics.Not always (eg if you override paintComponent you shouldn't dispose of your Graphics object)
Who says it's the responibility of the programmer to "release stuff that uses native handles" and how
do you know? I consider this a flagrant breach of the Golden Rule of GC (you let go of the object
reference and we collect the garbage). It's a mine may will step on because information about it is
hidden in the documentation.And how would that happen? The finalize method isn't guaranteed to be called (correct me if I'm wrong) in certain conditions, so there really is no place to put the cleanup code (except for a finally block or shutdown hook in the code that created the object). I don't think mentioning something in the documentation is the same thing as hiding information.
If you use like SWT then it's explicitly mentioned that you're responsible so there's no one to blame.I recently read that article. I think it's good practice to follow that rule.
When the JVM process terminates the OS can reclaim all resources it has allocated, including what the
Java program leaked.Do you have any proof of this?