Why can't we have a real 'finalise'

Question

Hi :)
As we know, all advice about the 'finalise' method is to never
use it, don't override it, pretend it doesn't exist, and if you ever
actually do write code in it, make sure it doesn't throw an exception,
and make sure (can't remember if this is just a 'myth') that it
executes in a very small time period.
Now, i don't have a problem with the requirement for this implementation,
but why can't we have a 'finalise' method that we can implement code
in.
Personally, I would love to have such a method where I can close my
resources, even do other things to conceptually 'end' my objects life.
Consider how ridiculous it would be if an OO language said: "yes,
there is a constructor, but don't write code in it ..., oh, you wan't to
'initialise' your object you say? well, create a pattern or interface or
whatever, implement an 'init' method, and always call that'. Anyone
who had a programming language tell him that would drop it for
a more sensible one.
So come on ... we have a method (even as many as we feel like, assuming
signatures) to 'establish' our object, why are we disabled and disallowed the
option of having one to finalise it (even; not sure of the appropriateness: ones
matching the constructor signatures).
who's with me? :) !

Answer 1

Where is your problem ?
Use a finally clause...Hence the fragileness. Out of the population of
developers, what percentage do you suppose remember to
do that? It would be MUCH better for the VM to take
care of it, destructing/finalizing objects either as
soon as they are no longer strongly reachable (hard to
implement), or at least at SOME point before the app
dies (the GC COULD have been designed to GUARANTEE
running before app termination)What I mean was that you can do something (clean up used connections, streams etc.) but let the GC do the rest. By the way it isn't guaranteed that the GC will run a full garbage collection before you close.