Hi David,
On 10/30/2017 3:31 AM, David Holmes wrote:
Hi Andrej,
On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
Hi David,
On 30. Oct 2017, at 01:40, David Holmes <[email protected]>
wrote:
Hi Roger,
On 30/10/2017 10:24 AM, Roger Riggs wrote:
Hi,
With the deprecation of Object.finalize its time to look at its
uses too see if they can be removed or mitigated.
So the nice thing about finalize was that it followed a
nice/clean/simple OO model where a subclass could override, add
their own cleanup and then call super.finalize(). With finalize()
deprecated, and the new mechanism being Cleaners, how do Cleaners
support such usages?
Instead of ThreadPoolExecutor.finalize you can override
ThreadPoolExecutor.terminated.
True. Though overriding shutdown() would be the semantic equivalent of
overriding finalize(). :)
In the general case though finalize() might be invoking a final method.
Anyway I'm not sure we can actually do something to try to move away
from use of finalize() in TPE. finalize() is only deprecated - it is
still expected to work as it has always done. Existing subclasses that
override finalize() must continue to work until some point where we
say finalize() is not only deprecated but obsoleted (it no longer does
anything). So until then is there actually any point in doing
anything? Does having a Cleaner and a finalize() method make sense?
Does it aid in the transition?
As you observe, the alternatives directly using PhantomRefs or the
Cleanup do not provide
as nice a model. Unfortunately, that model has been recognized to have
a number of
issues [1]. Finalization is a poor substitute for explicit shutdown, it
is unpredictable and unreliable,
and not guaranteed to be executed.
ThreadPoolExecutor has a responsibility to cleanup any native resources
it has allocated (threads)
and it should be free to use whatever mechanism is appropriate.
Currently, the spec for finalize
does not give it that freedom.
The initiative is to identify and remediate existing uses of
finalization in the JDK.
The primary concern is about subclasses that reply on the current spec.
If I'm using grepcode correctly[2], it does not show any subclasses of
ThreadPoolExecutor that
override finalize; so it may be a non-issue.
Regards, Roger
[1] https://bugs.openjdk.java.net/browse/JDK-8165641
[2]
http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root@jdk%24openjdk@8u40-b25@java%24util%24concurrent@ThreadPoolExecutor@finalize%28%29&k=d
